Jason Grigsby is the co-founder of web design and development agency Cloud Four, author of Progressive Web Apps and co-author of Head First Mobile Web. He joined Pragmatic Institute’s Design Chats to tell host Rebecca Kalogeris how designers and developers can collaborate to deliver optimal experiences for mobile and web users, his company’s unique responsive design sprint and more. Below, read highlights from the conversation, and listen to the podcast.
(Note: This interview has been edited for clarity and length.)
Why is responsive design often so complicated?
Think about it: You’re designing for a canvas for which you do not know the width or the height. You’re designing for input that is transient and unknowable. Just because you know someone used a mouse one moment doesn’t mean they have access to it the next moment. You’re designing for everything from touch-friendly targets to supporting the pixel precision of a mouse. And you’re trying to do that for devices that range from low-end Android devices with slow CPUs and limited network capabilities to high-end desktop machines with gigabit connections.
It is a wide range that we’re trying to design for; consequently, it’s hard to do. And a lot of what I’ve been researching is how difficult that process is if you’re not actually designing in the medium—so you’re designing in static design tools like Illustrator or Sketch.
There’s also the importance of making sure that what you’re designing is accessible. To build a professional website that meets what I consider the standards as a profession takes a decent amount of work.
How does Cloud Four navigate the partnership of designers and developers?
We’re pretty fortunate at Cloud Four because our designers code. It used to be that 100% of our developers had gone to art school. It’s no longer 100%, but they all have some design sense. So, as they’re doing the more complex implementations, which is where our developers usually end up, if they see something that feels like bad UX, our developers are likely to identify that.
We’ve worked with phenomenal designers who don’t code and that’s totally fine—their designs are exceptional. But when they design in three static sizes—mobile, tablet and desktop, which is common practice—there’s a lot left unsaid about that design. What happens in between those sizes?
When that design gets handed off to developers who, through no fault of their own, haven’t had any design training, it’s much more likely that the end result is a lesser version of that static design versus what I think actually should be true, which is it actually should feel more alive. It should feel better on the web than it did on that static version.
Describe how responsive design sprints work at your organization.
I don’t know that our process is tremendously different from most design processes. Depending on the project, we might use personas. We are obviously doing some sort of discovery early on. We might have wireframes. It just depends on what’s necessary. But as soon as we can, we get into what we call a responsive design sprint.
If you have lived in a New York apartment and then moved to the suburbs, it’s much easier than moving from the suburbs to a New York apartment. Design is the same way. If we can make it work on a small screen, it’s going to be easier to expand than it is to go the other way.
Basically, we do some discovery about the particular problem that we’re trying to solve. That could be a shopping cart on a site or a particular feature in a more complex software product. We’re going to try to find out everything we can about how that’s being used, all the features of it, all the edge cases, any existing information we have about that particular feature.
Then we’re going to do small-screen sketching. I know “mobile-first” has become a bit of a buzzword, but I prefer to look at it the way that Luke Wroblewski originally was talking about it, which is that it is a design constraint. And it’s a very helpful design constraint.
If you have lived in a New York apartment and then moved to the suburbs, it’s much easier than moving from the suburbs to a New York apartment. Design is the same way. If we can make it work on a small screen, it’s going to be easier to expand than it is to go the other way.
After small-screen sketches, we usually will immediately go into prototyping in the browser—building designs in the browser. We will share those designs as we’re working on them, usually in Slack.
Once we have it baked enough, then that cycle repeats. Next, at some point, we’ll have something—maybe it’s a full screen, maybe it’s just a portion of the interface—that the client feels is ready to go. But the code under that is not production-ready because we’ve been moving so quickly.
That’s where oftentimes developers come in. They’ll be taking portions of that design and attempting to codify it. They might be taking extra smaller components from the design and codifying how it gets used, all the variants of it, making sure it’s accessible, that it works across browsers, etc. Those all get documented in the design system, and they also feed into new designs, and then that process repeats.
For each design, you can do more and more complex things because you’ve got this richer and richer library of building blocks.
* * *
For more of Jason’s insights on building a better web, read his articles on Cloud Four’s blog.
