I recently moderated a discussion with UX designers and developers that focused on “adaptive” vs “responsive” websites and how to talk to clients about these terms. We started out by establishing common definitions for each term:
- An adaptive web site is one that has set break points and “snaps” when transitioning from one break point to the next.
- A responsive web site is more fluid. It does not have set break points, so it flows as the screen size changes.
The remainder of the discussion went something like this:
How should we define these terms in a statement of work?
Yeah… um. Don’t.
But... but...
No really. Don’t.
The issue is that everyone has different definitions of “adaptive” and “responsive”. These words have become buzz words that clients have heard and want to address, but most have different impressions of what they actually mean.
Some agree with the definitions above. Some don’t. Some think that the two are terms for the same exact thing. Most seem to think that they are just code for “My site needs to be mobile because mobile is a thing now and everyone is mobile. Mobile!!”
As a result, these terms are often misused and thrown around without any understanding of the work involved. When a client says they want an adaptive site or a responsive site, they probably do not mean exactly that. It is our job as UX professionals to figure how what the client actually wants – minus the buzz words. This should be a discussion, not a line item in an SOW.
So, what should we do?
The bottom line is that we should assume that every project will have a mobile component. To define what this mobile component will actually be, we need more information from the client:
- What does adaptive or responsive mean to you?
- What are the business objectives for your new site?
- What are the usage patterns of your current site per device?
- How do you want to manage your new site? (i.e. marketing blocks, copy, etc.)
Ok, chat with client… check! Now what?
Design and architect! This involves designers and developers working together to meet a client’s needs. Rapid prototyping can definitely help with this process, but first we need to define a UX architecture that takes many things into consideration.
Screen size is, of course, important, but so is device interaction. We also need to think about:
- image performance
- interactions on touch enabled devices vs. mice
- resolution
- general performance: what is the device speed? connection speed?
Each of these problems needs to be tackled separately, some very likely with the help of the tech dev side.
That was a lot. We’re done now, right?
Cute. Not even close. Mobile is an iceberg. This is just the tip. I definitely do not have all of the answers. But this discussion was absolutely a good start.