Don’t Debate Responsive VS Adaptive Design.
Treat this like product development: identify your MVP and test it.
There are hundreds of articles & posts across the internet on the topics of Responsive and Adaptive Web Design —here are just some of them. The gist seems to be, “there are pros and cons to each!” and while some folks might go so far as to advocate one approach (usually Responsive), most will abstain, opting to simply stress that it’s a very important decision.
I’m throwing one more point of view onto the pile, that stems from the following observation:
Increasingly, Web Design/Development looks like Product Design/Development— which makes sense, as apps and sites are products in their own right. But why, then, are there topics — like this “Responsive VS Adaptive” one — that we don’t seem to discuss with the same vocabulary Product Designers bring to every other problem space?
The “Responsive vs Adaptive design” debate is often framed as a choice between…
Development simplicity that may have some unintended consequences for users… so be careful!
Or…
Development complexity that might serve users better more often, but has its own drawbacks…so be careful!
But product development constantly navigates the space between simplicity & complexity. While the vocabulary we use in that realm — defining an MVP, iterating over time through testing, etc — sort of assumes you have the ability to move between both ends of the spectrum over time, no one seems to discuss web layout this way. Instead, you’ll find plenty of posts (including some of the examples above) that talk about choosing between Responsive & Adaptive as a philosophical decision. Some say that one approach (Responsive) is more future proof than the other. I don’t know about you, but I have a hard time imagining anything as “future proof.” That kind of talk tends to lead to wonky ‘conventional wisdom’ and blind spots. So let’s talk about Web Design as if it was Product Design because, surprise, it is.
Do you A/B test your work? Let’s talk about THAT instead!
Sigh. I wish “A/B testing” was as popular a topic as “Responsive Web Design,” but at least we’re trending in the right direction.
Let’s bridge this gap together! For the sake of not bloating this post with an A/B testing explainer, check this article out if you’re not already familiar with the topic. With that said, I do want to briefly emphasize one aspect of testing & leveraging data in design…
What are your goals? How do you measure progress?
Before you design anything at all, you should have a firm understanding of your goal — which should ultimately be about helping your users accomplish their goal. And you should know what achieving that goal looks like in terms of measurable actions they can take on your site. Those are your “key performance indicators.”
For example: one goal for an ecommerce site is to ensure that, for users who are navigating to products, we’re making it easy for them to evaluate the product, and if it’s right for them, we make it easy to add the product to their cart. As a result, we often talk about the “add-to-cart rate” — of those customers who have an opportunity to add a product to their cart, what % actually do? — as a primary KPI.
It’s not enough to rely on your cross-functional partners to tell you that an A/B test “won” or “lost.” You should understand how success was defined for the test. Knowing your KPIs, how they relate to user needs, and how performance differs across various screen sizes and user segments, is ultimately more valuable to your business, and to you as a designer, than knowing whether to choose “responsive” or “adaptive” when kicking off a project. To that end, I’m going to advocate for a specific answer to that question…
Your MVP should be Responsive
Cutting to the chase: you should design, develop, and test across all device types — phone, tablet, & desktop — in tandem, with an emphasis on providing a responsive solution whenever possible. What I mean when I say “responsive” is: as often as possible, plan on letting your elements grow or shrink to fill the space as needed, and avoid decisions that rely on the site needing to react to information about the user’s environment in order to provide optimized content.
“Responsive” should not mean providing a lowest-common denominator solution. Avoid making something that sorta works everywhere, but isn’t great anywhere. It can be completely appropriate to designate a certain device & browser where your design works exceedingly well and plan for the design to ‘degrade gracefully’ on other devices, browsers, and screen sizes.
Determine what your product’s red routes are, what platform your users will predominantly be using, and focus on this for your MVP. You need to get something out in the world so you can learn through testing and establish a baseline for all platforms.
While HTML/CSS specifications are constantly getting better and the possibilities for “Responsive” get more robust, there are plenty of scenarios where you’ll find that it only gets you so far. There will almost certainly be opportunities to create even better experiences for certain devices or screen sizes, even if that means more complex product development.
But these more complex experiences should, whenever possible, be the result of a responsive-first design approach paired with a multi-platform A/B testing strategy, and not just the result of you, dear designer, thinking that mobile and desktop inherently require divergent solutions.
Maybe you think that a slavish devotion to responsive design “leaves money on the table” — I don’t necessarily disagree, I’m just asking you to show me how much, because it also costs money when you add development complexity.
Then test the “adaptive” stuff.
From a development perspective, this can mean some of the more straightforward stuff like media queries to redefine some CSS values to better suit your content at particular screen sizes, or it could mean using some javascript in order to learn more about the user and serve a more dramatically modified experience. This whole suite of solutions is broadly defined as “adaptive web design,” though many posts will get even more specific, citing six breakpoints you should be designing for.
Rachel Andrew advises, in this Smashing Magazine article, “don’t target devices, add breakpoints when the design breaks” — I like this! The perceived complexity of an “adaptive design” comes from that “six distinct breakpoints” approach. Let’s ditch that. Instead, start with responsive and only go about building in adaptive fixes when the design “breaks.” I would add that you should really try to rely on both qualitative & quantitative data to define what “broken” means. “Not delightful” ≠ “broken.” Are there red flags from usability testing? When looking at your KPIs, are there meaningful differences across breakpoints and devices? If so, these are a pretty defensible reasons to start exploring adaptive designs.
“Progressive Enhancement”
Progressive Enhancement is where you start to push into the kind of functionality that is specifically enabled by technological differences across devices & browsers. Stuff gets complicated to build, QA, & maintain, so everything I’ve emphasized up to this point regarding A/B testing goes double, but the upside can be transformational for your business. Just have a very clear understanding of how you define success before you go adding an “Apple Pay” button to your site.
Why design, develop & test this way?
Like they say, non-responsive design can be expensive:
- There’s an opportunity cost to just assuming the necessity of non-responsive, platform-specific differentiation in a design: what work needs to wait while you spend time developing multiple solutions in order to test one hypothesis?
- There’s recurring design, engineering and QA cost to maintaining these differentiations over the long-term.
- There’s an SEO cost, though I think this is more specific to those sites that have separate “mobile” and “full site” implementations with separate site indexes.
Choosing to go “responsive” at the outset should never be used as a reason to avoid exploring adaptive optimizations & progressive enhancements in the future, but if your design includes those optimizations from the get-go, you are incurring the above costs without having demonstrated the business value of doing so.
On the other hand, if you test a responsive solution first, you may find…
- The test “loses” on ALL platforms: I’m sorry to hear that. But no worries, you’ve simply accelerated your learnings by cutting down on the time spent getting that version out — less hours on design, engineering, QA, data analysis, etc. If you end up back at the drawing board entirely, you’ll appreciate that you didn’t spend time making six super-special breakpoint-targeting versions of your design.
- The test “wins” on all platforms: Congrats, you’ve got a responsive solution that adds value to the business! If you still think there’s non-responsive optimization to be done to maximize value, you can prioritize this appropriately knowing you’ve set yourself up for a better follow-up test that will more accurately reflect that specific hypothesis.
- The test “wins” on some platforms & “loses” on others: You’ve got some options! Leveraging learnings from the first test, and with some measure of validation that you’re on the right track, you can try again for a responsive solution. Or maybe what you’ve learned in the initial test has you thinking you’ll need to produce a non-responsive solution in order to “win” on both platforms. At any rate, you may have the option (and incentive, based on test results) of launching a platform-specific solution to the “winning” platform in the meantime!
Choosing between web design approaches is NOT a philosophical decision.
There are decisions you make that provide value to your users and decisions that don’t. There are costs that are incurred and/or benefits to be gained with each of those decisions. Make use of Design Thinking and Business Intelligence to aid in this decision. Trust the process, and take those “VS” articles with a grain of salt, because only through conducting your own exploration and experimentation will you figure out what’s best for your users and your business.
