• Josh Riggs = UX & visual designer @lullabot • On the interwebs at @joshriggs O Hai! Hi everyone! Welcome to DrupalCon! So, as this big fancy screen says, my name is Josh Riggs, and I am a User Experience and Visual Designer at Lullabot. I’ve worked at Lullabot for about 2 years now, and I specialize in designing extremely large-scale Drupal sites, mostly for media and entertainment companies like The Grammys & NBC Universal.

Greetings From Portland BLAKE HALL SAYS I’M A HIPSTER Just a little about me: I was born and raised in Florida, but I’m now a proud resident of Portland, OR. Last year, my wife and I decided we’d had enough heat and humidity to last a lifetime, so we sold everything that wouldn’t fit in a 5x8 POD and drove across the country with our mutt named Frank to Portland, Ore. Besides design, I love photography, cooking, photography of cooking, and generally being outdoors. Just a warning to anyone who follows me on Twitter or Instagram, I post a lot of photos of my dinner.

HTML Prototyping LAST YEAR: DRUPALCON 2013 Last year at Drupalcon, I gave a presentation on HTML Wireframing and Prototyping. I thought it was a pretty good and informative talk even though I now disagree with many of the things I covered! Things just change so much over a course of a year! To me, the most important piece of information came at the end of that talk, during Q&A session. A woman asked me for advice on getting her company to adopt some of the techniques I talked about for their responsive redesign. She said that in her company, they were having problems with designers who designed things that couldn’t be implemented. They didn’t get it. As soon as she described her situation - that design and development were 2 separate departments that didn’t regularly talk to eachother, I had an “A-HA” moment. I realized her company’s problem wouldn’t be solved simply by having designers learn HTML or design in the browser. Instead, they needed to have the between design and development torn down with a sledgehammer. It wasn’t a problem of technology, but one of process. Which brings me to…

Building a Self-Aware Drupal Front-end with SkyNet.js JUST KIDDING

Responding To Responsive A DESIGNER’S GUIDE TO ADAPTING Responding to Responsive: A Designer’s Guide to Adapting. We are all experiencing the growing pains of building the responsive web. There’s been a lot of talk of killing Photoshop, or that designing in the browser will save humanity. I have my opinions, which I’ll get to later, but I don’t think we can solve fundamental process problems by changing what app we use to build our design mocks. Instead of giving you a super technical presentation about new method or technique, I wanted to have a conversation about design thinking.

Responsive Design Is Fucking Hard Responsive design is fucking hard. Let’s just get that out there and admit it. Sometimes it feels like and uphill battle. If it wasn’t hard, you wouldn’t be here now. There are something like 11 Drupalcon sessions this year about or mentioning Responsive Design. You’re all here because you want to learn something from me that hopefully makes responsive design easier for you. Right now our entire industry is trying to figure out how to build better responsive websites without going insane. So, If anyone tells you they have it all figured out, they’re lying.

Why Is It Hard? So why is it hard? In case you haven’t noticed :) It was already hard enough to build a single-width content-managed website and test it on 3-4 browsers, but now we have infinite widths, thousands of screen sizes, hundreds of devices, and dozens of browsers & operating systems to worry about. Not only is it a technical challenge to create one system that works across all of these variables, but it’s also an organizational nightmare. Clients still cling to old advertising project management styles. Oh, and raise your hand if you’ve worked on a responsive project that was grossly underestimated. Or the budget was completely blown. Yeah, me too.

• Understanding our craft • Evolving our process • Making it happen How Do We Make It Easier? So, how do we make it easier? Well, as any zen master will tell you, the journey to improvement starts within. We have to first embrace that responsive design is a huge challenge, but a challenge we can overcome. For the rest of our time together, I want to discuss all about all the things that have made my life easier for the last 3 years of building responsive Drupal sites, as well as some things that didn’t work so well. The first topic I want to discuss is the Craft of web design: what it means, and how we can become better designers by refining our craft. Secondly, I want to talk about how we need to evolve our process in order to create better responsive designs, starting by tearing down the traditional wall between design and development. And finally, I want to talk about how you can take all of this information and actually make it happen for yourselves.

The Elephant In The Room Alright. Let’s just start by addressing the elephant in the room. Lately there’s been a lot of talk about designers learning to code, and designing in the browser. All designers should code! Photoshop is dead! Designers should design in the browser! MOAR CODE! I’ve even read a thoughtful rebuttal article that said developers should learn to design. ! I have a lot of opinions on the subject, but first let me state that I am a designer who can “code.” And by “code,” I mean I know enough HTML, CSS & Sass, and Javascript to build static versions of things I design. I’ve also toyed with Less, tinkered a lot with Foundation, learned a fair bit of Jekyll, and have been working with Drupal Developers long enough to know what will be a huge pain in the ass to do with Drupal. Some might call me a “Coding Designer,” and others might call me… ! ! ! !

A Unicorn? A unicorn! So what do I think?

When you're in Hollywood and you're a comedian, everybody wants you to do other things. All right, you're a stand-up comedian, can you write us a script? That's not fair. That's like if I worked hard to become a cook, and I'm a really good cook, they'd say, "OK, you're a cook. Can you farm?" The late comedian Mitch Hedberg had a great bit about how comedians in Hollywood are expected to be all things to everyone. He said: ! “When you're in Hollywood and you're a comedian, everybody wants you to do other things. All right, you're a stand-up comedian, can you write us a script? That's not fair. That's like if I worked hard to become a cook, and I'm a really good cook, they'd say, "OK, you're a cook. Can you farm?" !

Mitch Was Right Mitch was right. For us to expect designers to also learn to code, or for that matter, for developers to learn to design is belittling to the craft of design AND development. As designers, we have skills for creating and thinking visually. That’s why we’re designers. We think in hierarchy, colors, typography and textures, and not in algorithms and arrays. We can certainly be taught to think technically, but our brains are only so big and can hold so much information. If designers are also expected to become front end developers, does that mean front end developers have to learn Sysadmin? Or worse, SEO?

Beware Of “Shoulds” What if we said “All musicians must compose their music on a piano with written notation?” Doesn’t that sound limiting? If that was the case, most of the great rock music wouldn’t exist. The Beatles? The Who? Slayer? Nope. These musicians used whatever instruments and methods they were comfortable with to create. Or, what if we said “You’re not a real photographer unless you shoot digital, have expensive lenses, and process with lightroom?” Tell that to Vivian Maier. Yet we’re so quick to tell other designers how exactly they should create.

We Are Digital Craftsmen Building the web is a craft, and designers and developers are digital craftsmen. I don’t mean, like, crocheting, although I have mad respect to people who can crochet. When I say “Craft,”, I’m referring to trade that requires skill AND artistry. Photography is a craft. Woodworking is a craft. Architecture and masonry is a craft. Think about it. We, the builders of the internet, are a lot like Freemasons, but without all the secrets and shit. We’re highly-skilled, highly creative people who build complex things for a living. There is an art AND a science to what we do, with some of us being better at the art, and others being better at the science. With that in mind, let’s take a look at what exactly the craft of web design is…

• Web Design Technique: CSS, Sass, HTML5, Javascript, 
 grid systems • Photography Technique: F-stops, focal lengths, shutter speeds, sensor sizes, cameras & lenses, filters • Web Design Vision: typography, color, lines, texture, 
 look & feel, motion, emotion • Photography Vision: light, shadows, color, lines, texture, motion, emotion Web Design & Photography So, as I said just a few minutes ago, I’m also a photographer. In many ways, web design and photography are very similar. Both photography and web design have highly technical aspects. This is what I refer to as “technique.” With web design, it’s CSS, Sass, HTML5, Javascript, PHP, grid systems, etc. With photography, it’s f-stops, focal lengths, sensor sizes, filters, etc. Also, both photography and web design have highly conceptual and creative aspects. This is what I refer to as “Vision.” Web design has UX, typography, colors, textures, lines, planes, motion and emotion. Photography also has colors, lines, textures, and emotion as well.

• Technique is the “Science” • Vision is the “Art” • Have we lost track of our vision? Craft = Art + Science + Experience To me, “technique” refers to the science, where “vision” refers to the art. I’ll be blunt here and say this: I think we’ve become too concerned with our technique and tools for designing responsive products that we’ve lost track of vision, style and substance. In order to design the best responsive experiences and master our craft, we need a clear design vision as well as well as solid foundation in technical skills.

“Gear Is Good, Vision Is Better” - DAVID DUCHEMIN I picked up photography about 7 years ago, but it wasn’t until I read a book by Canadian Photographer David DuChemin called “Within The Frame,” that I really started to grow as a photographer. The subtitle of the book is “The Journey of Photographic Vision, ” and the mantra of the book which gets repeated over and over again, is “Gear is Good, Vision is Better.” I’ll repeat. “Gear is Good, Vision is Better.” What David DuChemin is saying is that technical things like camera gear, lenses, hardware, software - don’t matter as much as having a solid photographic vision. A photographer can know every technical detail about her camera, and have the best lenses in the world, but if she doesn’t have a solid photographic vision, her photos won’t be interesting. For photographers to master their craft, not only do they need to understand the technical aspects, but they need to work hard on defining and refining their photographic vision. Reading this book and applying this philosophy to my photography not only made me a better photographer, but it also made me realize how much this philosophy applies to responsive web design. Yes, we need to understand the box model. Yes, we need to know about how CSS pseudo elements behave. But more importantly, we need to be the visionaries of the user experience.

Just for fun, I asked David DuChemin to define “Vision” in his own words under 140 characters, and this is his response: ! “Vision: The larger story, goal, or message to which we align our work. It’s the Why that informs the What and the How of our work. ! Wow. Can you see how that statement applies to responsive design? Does it seem to you like all of our recent dialogue has been about the “What and How?” of responsive design, and not the “Why?”

Design Vision = Why That Informs What & How So, just to clarify, our design vision is the “why.” that informs the “What and How” What problems are we solving for and Why? What are our business goals and Why? What will our design principles be? Why are we using the UI patterns that we’re using? Why do we need a fucking carousel? I’m mostly kidding there. !

Vision Is Abstract, Technique Is Concrete Vision is a very abstract concept. It’s different for every designer. Hell, it took me several hours just to organize my thoughts on the subject for this talk. So, what are some ways we can bring vision to the forefront of our responsive design process and not get completely bogged down by technique? I’ll get into specific process deliverables later on, but I want to start with some more general thoughts.

Design Systems, Not Pages. This is the concept at the core of “component based design.” Most of the articles I’ve read on the subject tend to focus on front-end development techniques - i.e., how to use Sass extends or mixins, BEM syntax, etc. Having a solid design vision, however, means being able to design a system of bits and pieces - components - that can be rearranged if needed and still work together. Especially with Drupal and content managed websites, we know that our content can be extremely variable. One of the best ways we can account for that variance is by creating a well thought-out system of UI patterns.

We Need More Visionaries & Less Coders I realize this is a bold statement. I’m not saying that designers shouldn’t learn any code. I AM saying that designers should embrace their unique ability to be visionaries. Designers have the ability to reach out and grab abstract things like business goals, organizational challenges, and user needs from the ether and create something visible and tangible. This is what we get paid for, and it’s a great skill that requires a lot of practice. Let’s not limit define ourselves by what Sass mixins we know. We need to know the rules of the DOM, yes, but as we start to obsess more and more about code, we begin to box ourselves in and limit ourselves to solutions we know how to personally build.

The Tools You Use To Create Should Never Get In Your Way. Design is about creating ideas in the quickest and most natural way, with the least amount of resistance. For some people, that’s Photoshop. For others, it’s Sass and HTML. For most of us, it’s probably a combination of sketching, Hi-Fidelity mocks, and in-browser design, and that’s OK. I’ll get to my preferred methods in a bit, the important thing to remember is that the tools should never get in the way of your ideas. Tools should help you create and be an extension of your vision. Tools should not limit you, define you, or make key design decisions for you.

Don’t Trade Style For Tools I recently read an article by Dan Mall on Web Standards Sherpa. In it, Dan was asked this question: “Now that I’m no longer using photoshop for prototyping, I wonder if it still has a place in my workflow besides just image processing…” ! His response was quite long, but for me one of his best points was this:

“When I’m writing code, my brain isn’t in creation-mode; it’s in debug-mode. All sense of expressiveness is usually stifled in place of ‘correctness.’” When I’m writing code, my brain isn’t in creation-mode; it’s in debug-mode. All sense of expressiveness is usually stifled in place of “correctness.”

“And, no offense, but most sites I come across that were ‘designed in the browser’ look ‘designed in the browser,’ if you know what I mean.” -Dan Mall And, no offense, but most sites I come across that were “designed in the browser” look “designed in the browser,” if you know what I mean. ! I think we can all agree that things are starting to look pretty ubiquitous in responsive design, and I believe it’s because we’re all using the exact same tools. Instead, let’s embrace a process that allows us to think and express as freely as possible.

We Are All Different And Special Flowers As I said earlier, designers and developers are different. We think differently. We solve problems differently. Because we’re working towards a common goal of creating a great product, there is a lot of overlap in our skill sets. But we’re also human, which means we’re all different. Some designers are very technical, whereas others are extremely artistic. Some of us are might be complete unicorns, but most of us in this room are probably somewhere in the middle of that sliding scale. But just because someone isn’t proficient in Sass doesn’t mean they can’t solve complex UI problems. And just because someone isn’t a visual designer doesn’t mean they can’t have a great conceptual idea. Let’s not so rigidly define ourselves by saying we must always use our tools in a certain way. ! In fact, I’m going to make a bold statement…

Success or failure of a responsive design has never depended on whether or not the designer used Photoshop. Success or failure of a responsive design has never depended on whether or not the designer used photoshop. We’d like to think our tools are so important and life-altering, but they aren’t. The truth is, if a responsive projects fails, it’s not because of a lack of in-browser design or a designer who doesn’t code. It’s because of a lack of communication. Often, there is virtual or even a physical wall between designers and developers, and this wall needs to be knocked down. Which brings us to…

Evolving Our Process WHY WE CAN’T SOLVE A PROCESS PROBLEM WITH TECHNIQUE Evolving our process. So, yes. Responsive Design is fucking hard. In the next bit, I want to talk about building a better process to help us make it easier. I have a quick project case study I’d like to share with you, followed by an overview of what I consider to be an ideal responsive design process. But first, I want to talk about the wall that sometimes between design & development, and how we can knock it down.

Bring Down The Wall BETWEEN DESIGN & DEVELOPMENT As any of us who have worked on a large responsive design project know, the biggest challenge is designing for all of the complexity. This challenge is much more difficult when we have a project plan that separates Design and Development into 2 different phases. On top of that, design and development might be done by different teams in other buildings, or maybe even in another state. And god help you if design and development are done by two different agencies or vendors at two totally different times. Situations like these tend to create virtual or physical walls between designers and developers.

A typical enterprise responsive design project usually looks a bit like this: Strategy, UX & Visual Design, & Development all happen in large blocks of time, one after another. And in between these phases exist massive walls over which deliverables are thrown to the next person or group with nary an attempt at collaboration. “Hey Josh. Here is the content strategy doc and some wireframes I made in MS Paint. Let me know if you have any questions” So, of course things are getting lost, like context and purpose. You don’t know why there’s an executive order to put a carousel on the home page, and you were never given a chance to suggest anything else. You do know that the person paying you wants a fucking carousel, so you get to work.

If we remove the walls from our process, it starts to look a little more like this: Maybe the core team can’t be in the same building together, but if we can get strategists, designers and developers working together from the beginning, then there will be a lot less confusion. The goal is to create an iterative process where strategy, design & development are happening at least somewhat in parallel to eachother. There will always be last minute requests and fire drills, but when you know why you’re being asked to design or build something, it’s a lot easier to deal with.

• Don’t try to be a hero if it’s a high pressure project. • Find out who will be developing your work. Get in contact with them. • Be very thorough. • Explain why you’ve created every element in your designs. • Give context. • Present people with problems instead of solutions. What If I’m Stuck Behind A Wall? • Don’t try to be a hero if it’s a high pressure project. Maybe it’s not the best time for a first try at browser design. There’s always another project. • Become a stalker and find out who will be developing your work. Get in contact with them. • Be very thorough. If you’re sticking with PSD comps, annotate everything, and create as many designs as you can. • Explain why you’ve created every element in your designs. Give context. When developers just get designs thrown to them over the wall, they usually don’t get any explanation of why. Instead, they’re just told to shut up and build it. In my experience, telling a developer why you made your design decisions goes a long way in making sure those decisions get properly implemented, rather than getting hurled back at you from over the wall.

NAMM Foundation A CASE STUDY IN IDEATION & PRODUCTION Earlier this year, I finished up design work for the National Association of Music Merchants, a trade organization for musical instrument manufacturers and retailers. They run the largest yearly tradeshow in the US, the NAMM show, in Anaheim California. The NAMM Foundation is their non-profit foundation for music advocacy, with a focus on music education for kids.

NAMM hired Lullabot initially for for design and content strategy only, with the intent to develop the new responsive site in-house. So, right here we have a unique scenario. While I would be communicating with their developers from the beginning of the project, I had a limited time to produce my work, which would then be passed on. Lullabot knew that we needed to provide their developers with the most information we could and be very thorough, so we decided to make our final deliverables be working, fully designed static HTML instead of just PSD’s. This way, their developers could see exactly how everything was supposed work and behave responsively. And due to resource availability and scheduling, I was to be the designer and front-end developer, and our goal was to give them production-ready code. Because of our quick timeline, I wouldn’t be able to mock everything up in Photoshop first, which meant I’d be doing a fair amount of browser design. I was up for the challenge!

Ideation Vs. Production IDEATE IN PHOTOSHOP. PRODUCE IN CODE. The NAMM project, for me, is a perfect example of splitting the design process into ideation and production, and using the right design tool for each. If we think of building a responsive website like building a puzzle, we can’t put the pieces together until we’ve painted the picture. Ideation is painting the picture, and production is putting the puzzle pieces together.

Ideation ART 
 DIRECTION UI CONCEPTS VISUAL PROBLEM SOLVING EXPLORATION & SKETCHING Ideation is about starting from a blank canvas and creating conceptual ideas. This is an extremely important and vital part of the design process This includes important design decisions like Art Direction, UI Concepts, Visual problem solving, and Exploration & Sketching.

“…No need to care at this stage whether what you’re designing is a good idea or even possible; the main goal here is expressiveness. I’m looking to establish art direction, the touchy feely stuff.” -Dan Mall Going back to that article by Dan Mall on Web Standards Sherpa, he says… “[There is] No need to care at this stage whether what you’re designing is a good idea or even possible; the main goal here is expressiveness. I’m looking to establish art direction, the touchy feely stuff.”

• Needs a canvas • Needs iteration • Needs to be quick and messy • Is about the bigger picture • Can’t be inhibited by merge conflicts or Ruby dependencies Ideation: • Ideation needs a canvas where you can easily move things around, and play with position, hierarchy, colors, typography and textures. • Ideation needs iteration. The ability to experiment with multiple solutions • Ideation needs to be quick and messy. It’s the equivalent to sketching your idea on a napkin at the bar. • Ideation is about the bigger picture, and creating an overall design language • And lastly, Ideation can’t be inhibited by merge conflicts or ruby dependencies. Seriously, nothing, I mean NOTHING kills my creativity like spending 2 hours fixing a merge conflict.

In Other Words… Photoshop Is Perfect For Ideation! in other words… Photoshop is perfect for ideation! Photoshop gives us all these abilities. Photoshop doesn’t get merge conflicts. Photoshop doesn’t require a plugin to a plugin to a plugin to work, and its output looks the same in all browsers.

Production APPLYING DESIGN LANGUAGE BREAKING DOWN COMPONENTS TESTING & VALIDATION “FILLING IN THE GAPS” Production, on the other hand, is about completing the conceptual ideas and making them concrete. This is an equally important part of the design process that includes the application of the design language across the entire user experience; breaking down the design system into reusable components, testing and validating the design system in a browser, and filling in any gaps.

• Needs to be highly organized • Needs to be precise • Needs to be repeatable • Provides detail and clarity for big ideas • Is where we test and validate Production: • Production needs to be organized and efficient • Needs to be precise • Needs to be easily repeatable • Provides detail and clarity for big ideas • Is where we test and validate

Production Is Where I Switch To Code. Once I’ve created a general design direction, then I can switch my brain over to be more analytical and computational and build additional designs and interactions with code. I just can’t do it before that. I can’t start with a blank browser window and start designing with code, and that’s OK.

(Actually seen by the client) • Working responsive HTML wireframes - 15 displays • Style Tiles • 5 Hi-Fi PSD mocks • Style & design system applied to HTML wireframes • HTML Interface Style Guide NAMM Design Deliverables: So, let’s quickly look at some of the design deliverables we created for NAMM, and then break them down into examples of ideation and production. • We started UX before visual design by creating the wireframes first. By looking at various various business goals and user needs, we decided that we needed about 15 unique “displays” to design. • Once our wireframes were approved, I switched gears and focused solely on visual design and exploration and created 2 unique and different style tiles. For anyone not familiar with Style Tiles, they’re meant to be quick and lightweight deliverables to help the client decide on a visual design direction. They are NOT meant to be a development aid or style guide. • 5 Hi-Fi PSD mocks. I created PSD mocks for 2 reasons - 1. I needed to personally get my bearings and make sure the art direction I established in the style tiles actually worked across a larger system. It did. :) 2. The clients were pretty traditional, and they needed help visualizing the design system in context. Presenting them with a style guide and asking for sign off just wouldn’t have worked. • Style & Design systems applied to HTML Wireframes. This was the largest part of the process. Basically, I took the art direction provided in the style tile and the 5 PSD mocks and applied it to all the wireframes. I started by styling the 5 displays I had already designed in Photoshop, and then built the rest of the 10 displays by designing in the browser. • And, finally, an HTML Interface Style Guide containing text and content styles that they could easily reference. • By delivering all of these things to the NAMM team, they’d have everything they’d need to not only build the site in Drupal, but also maintain and add to it in the future.

IDEATION: • Paper sketches • Quick illustrator mocks • Not seen by NAMM team Wireframes: PRODUCTION: • HTML Wireframes based on sketches • Used Jekyll for tempting • Created HTML and Sass partials to mimic Drupal structure • Code to be refactored later With the wireframes, I broke the process down into Ideation and Production like this: Ideation: • Paper sketches • Quick illustrator mocks • Not seen by NAMM team ! Production: • HTML Wireframes based on sketches • Presentation-ready and demoed to NAMM team • Code to be refactored later

And just for reference, here’s an Screenshot of our responsive, working HTML Wireframes for NAMM. Just pretty enough

IDEATION: • Style Tiles • Hi-Fi PSD mocks (5 displays) • Icon Design Visual Design: PRODUCTION: • Styling of HTML Wireframes in browser • HTML Interface Style Guide • Refactor HTML / Sass as needed With the Visual design, I broke down the process into Ideation and Iteration like this: Ideation: • Style Tiles • Hi-Fi Mocks • Icon Design ! Production: • Styling of HTML Wireframes in Browser • HTML Interface Style Guide • Refactored initial code

Here are examples of the 2 style tiles. They chose the one on the left

And the 5 PSD Mocks

And a detail shot

And because this is DrupalCon and we need to show code porn… This is a screenshot of the fully styled HTML design mocks.

And, lastly, this is a screenshot of the HTML Interface Style Guide. I realize that I’ve just briefly showed these deliverables. If you’re curious about more of the technical bits like using Jekyll and Sass for the wireframes, I’ll be happy to talk your ear off after the session.

Choose Your Design Plan Based On Your Unique Situation WHY WE DID WHAT WE DID WITH NAMM So, why did we choose the process we used with NAMM? Is it the ideal process? No. NAMM was a very specific scenario. Because of scheduling, I was the lead designer AND front end developer. Lullabot acted as a consultant to NAMM. We were working directly with their development team. All of these factors helped us to choose a design plan that worked for them and us. For example, if we had a dedicated front-end developer on the project, I probably would have done far less front-end code.

The Ideal Process? DOES IT EXIST? So, what is an Ideal responsive design process? The truth is, there isn’t one. Every responsive design project has a very specific scenario with unique people and teams. The important thing to remember is that you have to pick a process and a way of working that works for you. There are a ton of methods and opinions out there, like Brad Frost’s Pattern Lab & Component based design. But, Brad Frost’s style and methods work for Brad Frost. They may or may not work for you in your situation. I personally disagree with some of the things he says, and you can pry Photoshop out of my cold, dead hands. But that’s OK. We need to use the methods and processes that best suit our needs, and constantly try to improve them. It’s these differences that actually make our work unique and interesting.

• UI Sketches (internal) • Responsive HTML Wireframes, NOT PRODUCTION CODE!!! • Style Exploration (internal) • Style Tiles or Element Collages • 2-4 Hi-Fi Mocks • Fully Styled Wireframes, styled in browser • Interface Style Guide (HTML or PSD, depending on situation) But If I Have To Choose… But, Since this is a presentation on Process and I have to choose… • Start with sketching interface ideas. As many as you want. These need to be quick and ugly, and you don’t need to show your clients if you don’t want to • From there, build your working wireframes. The key here is to communicate ideas to clients and developers, not to create amazing, production ready code. • Next, start style exploration. Again, the key is to get your creative brain working. There’s no right or wrong at this stage. The point is to play and experiment • Now it’s time to get more specific. Style tiles will help you make sure your visual design is headed in the right direction. • Again, I need to see everything in context, so I prefer to make at least a couple hi-fi mocks. I use photoshop, but you can use whatever you’re comfortable with. This is where we can make sure our design system is working before we get too far down the rabbit hole. I typically only do PSD mocks of desktop widths, because they’re typically the most complex. • Once I’ve created Hi Fi mocks, I’ll switch to code and finish styling the wireframes in the browser. • Finally, I’ll create an interface style guide or collage that contains every possible styled component. This is more for developers than clients.

…But This Will Probably Change Next Time But this will probably change next time. Ever since I’ve started designing responsive websites, I’ve not used the same process or deliverables exactly the same way twice. Partly because things change so fast and partly because every project needs its own custom process. For example, I’ve decided to stop aiming to create production-ready code in my HTML Wireframes because it proves too limiting for the front-end developers. It’s like, hey, here’s your front-end code, all ready to go! You didn’t want to do it your own way, did you?

Make Shit Happen! YOU’RE THE CAPTAIN OF YOUR OWN PIRATE SHIP Most of us here are part of a team of some sort. Maybe a small internal team, a large enterprise team, or, like me, on a consultancy team. We usually can’t just come in guns-a-blazin’ with an all new process and expect everyone else to follow suit. Especially if we’re working on projects that are already in progress. So, let’s talk about some ways you can make your responsive design process better no matter what your situation is.

Embrace New Techniques YOUR JOB AS A DESIGNER IS TO BE A PROFESSIONAL LEARNER Embrace new techniques. Your job as a designer is to be a professional learner. Nearly every project I’ve worked on has required me to learn at least one new thing. This time a year ago, I knew 0 Sass. Now, after working with it daily, I’m getting pretty handy with it. This time 2 years ago, I had never built HTML wireframes.

Sit Next To A Developer For 6 Months THEN ASK THEM TONS AND TONS OF QUESTIONS Find a nice developer in your company and sit next to them for 6 months (or more). Even if you know nothing about code now, you will by the time the 6 months are up if you ask them questions. If you’re a developer, sit next to a designer. I learned the fundamentals of HTML and CSS because I sat next to a Dot Net developer at my first job and asked him how to do things I didn’t know how to do. Not only did I learn a ton about coding, but I gained respect and understanding for what developers do.

Commit To Something You Don’t Know How To Do NOTHING MOTIVATES LIKE A DEADLINE Commit to something you don’t fully know how to do. Obviously, you should pick something that isn’t a high-pressure project. Start small. If you haven’t yet built responsive HTML wireframes, commit to doing them on your next project. Just make sure you allow yourself time for a learning curve.

• No budget constraints • No catastrophic consequences • Work whatever way you want • End up with cool work Do Personal Work Do Personal Work. Create something for yourself, by yourself. Now, I’m not talking about freelance work, but work that is solely for the purpose of learning and trying something new. Maybe a personal photo blog, or a website for your upcoming wedding. Doing personal work allows you to: • Try new things with no budget constraints • Get better at something that needs improvement • There are no catastrophic consequences if something doesn’t go according to plan • Work in whatever way you want. Try out the new version of Sketch, try using BEM Syntax for the first time • End up with a cool piece of work.

• Project for a couple in San Francisco • They saw the site I did for my wedding • They had no money • I agreed to do it if they gave me creative freedom and let me try some new things, like making the site responsive, and using Bootstrap • I treated this like a client project and even built it on Wordpress • Allowed me to experiment with Bootstrap, responsive design, creative branding, and wordpress. • Had an awesome portfolio piece at the end

• Zurb Foundation • Sass • Jekyll • Sketch 3 Get Your Hands Dirty With Some New Tools Finally, for those designers that are looking to use code as a design tool, you should definitely check these out. • Zurb Foundation. It’s a complete responsive framework, and a great way to get started with creating responsive Wireframes and prototypes. • Sass. I really can’t imagine building any kind of responsive design without it. • Jekyll. Jekyll is a static site generator. It does a lot of shit that’s way over my head. In a nutshell, it allows you to create templates and reusable components with HTML, which is really useful. • Sketch 3. It’s a new image editing and creation app. It’s great for responsive design because it allows you to have multiple flexible canvases and output layers to css.

“If there is no struggle, there is no progress.” - FREDERICK DOUGLASS If there is no struggle, there is no progress. TL;DR, Responsive Design is hard, but we’ll only get more awesome if we keep working at it.

Ta-Da! @JOSHRIGGS EVERYWHERE / LETS GET A BEER.