Responsive Design Process that Works

Written by Jason Grigsby on

A few years ago we faced a conundrum. We want to design responsive experiences, but our old way wasn’t scaling. We were producing too many artifacts, and what we produced didn’t represent the end product well. We had to find a better way.

It took some time and some experimentation, but we eventually settled on a new process that has worked incredibly well. We’ve used this process to solve a wide range of design problems ranging from marketing websites to complex web applications.

Responsive Design Sprints

The specific parts of our process vary depending on the project, but the core engine remains the same: a responsive design sprint.

Illustration showing the responsive design sprint process circle of discovery, sketching, and prototyping. A line goes from the sprint circle to components that are extracted and to the design system where they are documented. The arrows go both directions because components feed the sprint process for future prototypes.

We start with discovery for the patterns we’re designing during the sprint. We then sketch small screens. Small screens are a useful constraint. If you’ve made your life fit in a tiny home, you won’t have any trouble fitting it into a house in the suburbs, but going the other direction is a challenge.

After sketching we move directly into code. You can call this step prototyping, in-browser mockups, or web-based mockups. We’ve used all of those terms at one point or another. What matters is that we’re designing responsive from the beginning because we’re designing in the medium of the web.

Once an in-browser mockup is approved, we determine what portions of that design should be made into components. When we create components, we consider accessibility, performance, browser support, maintainability, reuse, best practices—all the things we can ignore in the quick prototypes.

We codify those components and document them in a design system. Every component that we create speeds up the design process because it can be used as a building block for subsequent prototypes.

A Better Process

I’m not here to say that we’ve found the one true web design process. Every organization is different. But I can confidently say this process is demonstrably better than the traditional web design process. Here are three examples of how the process results in better designs.

Designs have greater integrity

I often encounter responsive designs that break at various screen sizes. The content will break out of its container because it is fixed width in a responsive layout. Or the content will stretch in ways that is no longer readable. There are sites that I visit frequently that I now know I have to flip my device or change my browser window if I want a good experience.

This is what I mean by integrity. The design may look good in general, but as you resize the browser, you start to see the design break apart.

For Champion Power Equipment (CPE), product tiles were designed as in browser prototypes.

In a responsive design sprint process each smaller components has been thoughtfully designed and is fully responsive.

Champion’s navigation was also created as an in-browser mockup and then converted into smaller, responsive components. The navigation component made subsequent prototypes easier to create.

Because these smaller pieces are fully responsive, when you start building full pages, you find that the pages don’t break down. The page is fluid because every piece of the page is fluid as well.

When the various components are combined into a full page, the resulting responsive design has integrity. All of the pieces combine into one fluid prototype.

Solve problems you can’t see in static mockups

When we were working with Walmart to make their grocery site responsive, one of the most important and difficult screens to make responsive was the book time slot interface. This interface presented customers with a table of delivery times to chose from.

Walmart Grocery’s original, fixed-width book slot interface featured a large table with seven days worth of options.

Fitting all of this content onto a small screen while increasing the size of most of the elements to make them touch friendly was a challenge. It required reconsidering the information priority and density to make it all fit.

Our small screen prototype displayed a single day of touch-friendly options.

Everything looks great as a static image. Fortunately, we had an in-browser mockup to play with. Once we created a link to go to the next day’s time slots, we discovered a problem.

This video illustrates how jarring it was to switch days on small screens. The length of the page changes along with scroll position. New time slots just appear in the place of the previous day’s times.

The experience of moving from one day to the next was jarring—particularly in cases where one day had a lot of time slots and the subsequent day had few. There was little feedback provided to help users orient themselves.

Sometimes it was clear something had changed, but because the page length was different, you were suddenly teleported to a different area of the page not knowing what happened. Other times, you’d catch prices and time slots changing, but they would change so quickly that you weren’t certain what had happened.

The interface looked good on paper, but the actual experience didn’t work. We needed to provide a way to orient users to what was happening. We used animation to make it clear. It took quite a bit of experimentation, but we finally found something that worked.

The book slot animation makes it clear what is changing and where.

What I love most about this animation is how it just feels right—like it should always have worked this way—and yet I know how many iterations it took to get it to feel natural. In fact, it isn’t one animation. It is several. I’ve slowed it down in the video below so you can see the multiple transitions at work.

This 10x slow video shows the multiple animations used to provide context to users.

If we had only be designing static mockups, not only would we have had trouble figuring out the best combination of animations, but we wouldn’t have even known we had a problem to solve to begin with. Instead, we ended up with an in-browser mockup that showed the full responsive experience including these critical animations.

Video Walmart Grocery book slot interface prototype shown in the browser responding to the viewport and illustrating how the interface should not only look, but also feel.

Handoff with Responsive Problems Solved

Even in this process, we still have handoffs. Sometimes we’re handing the prototypes off to developers who are codifying the components in a design systems. Sometimes it is developers on our team or the client’s who will implement the design in the end environment.

Handoffs can still have complications. But they are much fewer than when we’re working with static mockups because developers can see exactly how something is supposed to work.

The prototype of Wolfson Children’s Hospital demonstrates how the design should behave at every breakpoint. More on this project in our recently published Baptist Health case study.

With this process, the majority of the responsive design problems have been solved in the in-browser mockups we hand off. This happens because we’ve been designing responsively, in the medium of the web, from the beginning.

The Secret Sauce

We believe so much in this process that we evangelize it to others in presentations and workshops. We’ve been fortunate to have clients who wanted to learn the process and who work alongside us or embed in our team.

And we’ve been successful doing this even when some of the client designers cannot create in-browser mockups themselves. They take screenshots of the prototypes and then modify them in their design tool of choice. The key is collaboration and refining ideas quickly.

Unfortunately, our process isn’t always a good fit for other organizations. We have a bit of an advantage when it comes to operating in this way:

Our designers code and our developers went to art school.1

I realize the subject of designers coding is a bit of a heated topic. I don’t hold a dogmatic perspective on this issue, but in my ideal world, yes, designers would be able to code. And developers would be able to design. In fact, in my ideal world, everyone knows how to code and design.

But I’m also realistic. There are amazing designers we’ve worked with who cannot code. There are phenomenal developers who don’t have an eye for design. My ideal world doesn’t exist.

The responsive design sprint process

What we need are design tools that can get us closer to the responsive design sprint process so that every designer—whether than can code or not—can participate in it.

What would a design tool look like that did that? More on that next time.

This article is part 4 of a series on design tools in a design system world:

  1. Traditional Web Design Process is Fundamentally Broken
  2. Design Happens Between Breakpoints
  3. Faulty Assumptions and Unwanted Features of Most Web Design Tools
  4. Currently Viewing:Responsive Design Process that Works
  5. Web Design Tool Wish List
  6. [Coming soon]

  1. It is no longer strictly true that 100% of our developers went to art school, but they all have design sensibilities. 
Jason Grigsby

Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He is the author of Progressive Web Apps from A Book Apart. Follow him at @grigs.

Never miss an article!

Get Weekly Digests


Leave a Comment

Please be kind, courteous and constructive. You may use simple HTML or Markdown in your comments. All fields are required.


Let’s discuss your project! Email Us