Demo your responsive site well
How to prevent the face palm by managing expectations
Published on
Seven years ago, I started writing a thesis on responsive design. A lot has changed in our methodologies, for the better. But the way we talk about, show and present responsiveness has not changed. We’re demonstrating our products like it’s a 90s website. We should fix that.
How we work nowadays
Our way of working has matured in the past years. We work content-first with a mobile-first approach. Design and development are done in a device agnostic way and we utilise progressive enhancement. Tweakpoints are used rather than breakpoints.
Some of these terms might be unknown to you, but that’s okay. There’s a lot of theory we use nowadays when designing and developing a responsive website. We think, sketch and prototype often. Usually, this gets lost while presenting.
A few months back I was at a sprint demo. Or the sprint review, according to the Scrum Framework. One developer presented what we worked on during the past sprint. After getting a question about text on mobile from one of the stakeholders, the developer resized the window.
I knew the browser window couldn’t be slimmer than 400 pixels. The text was neatly positioned on the screen, so the stakeholder was happy. However, on a regular mobile phone, the headline had three lines of text and the button was stretched. Afterwards, the stakeholder returned and said something was wrong with the interface.
The issues
A design is almost always presented inside a graphics editor, a browser or in a slide deck. Presenting a mobile website inside a browser doesn’t cut it. You don’t get the feeling of a mobile device. I’ve compiled a list of things that are usually off when presenting:
- Not the right viewport size; not only in width but also in height. Remember that a browser interface reduces the viewport height.
- Scrollbars; they can be present on desktop but not on mobile.
- Form elements; they differ on desktop and mobile platforms.
- Font size and other sizing that’s either too small or too large.
- Fast processing power; remember, a phone isn’t as powerful as a desktop.
- Fast internet connection; perfect wifi is different compared to a 3G connection in a busy city.
I can even think of a few more.
Why are these issues relevant?
A client can look at your design and approve your product. But you can’t judge a mobile interface when it’s not in your hands. While using the product on a device, you can ‘feel’ how it works. Then you’ll find that the 18 pixels font-size for body text might be too big on your mobile phone. Or that call to action button, maybe it should be promoted to the top.
Next to design decisions, there can be issues with the expectations of the end result. It happens often: clients file bug reports first, ask questions later. They’re confronted with some quirks in the product.
When you need to explain afterwards why the product looks and acts differently on certain devices, you’re actually too late. It’s easier to get in a defensive mode when talking to your client, which can damage your credibility and relationship with the client.
Manage expectations
Your best move is to inform people up front. Be clear on what you’re making and how it will look and work on different devices.
Responsive design is traditionally presented in a linear way: mobile, tablet, desktop. But different contexts also come into play:
- Low contrast (when you use your phone in the sun)
- Slow connection speed
- Low battery
- Touch capabilities
- Differences in length of content
Instead of just showing the result on a certain resolution, draw focus to how the interfaces changes in different contexts. Prepare to show or emulate those contexts.
As an experienced designer or developer, you might make design decisions based on these contexts. Like adding a little tweakpoint here and there to make sure the in-between state behaves as expected. Share it with your colleagues and client. And explain why they’re necessary.
Show it well
In the early days of responsive web design, we didn’t have access to good developer tools or devices. A lot of different bookmarklets and other tools were developed to show the design at certain breakpoints. In 2018, development and testing responsive websites have matured. Right now you don’t have an excuse to half-ass your demo. But how?
Ideally we use real test devices for our job. Use them to demo your product. Or use your own device. It’s possible for some Android and iOS devices to present directly to equipped TVs and beamers. See if you can use that feature. Otherwise, there are services like Browserstack that let you access real devices or emulators digitally.
Of course, it depends on what you need to show and tell your colleagues and client. In some cases, it’s best to present your website with a prerecorded video. That way you can control several issues:
- Length of your presentation
- Distraction caused by personal notifications
- Loading speed on a regular phone connection
Inform your team
If you want to be proud of your work and need to make sure your hard work will get noticed, then do something about it!
To achieve change, it might be necessary to create some leverage. Tell your (scrum) team it’s important to show a real-life demo. Don’t get stuck in a certain way of presenting. And make something of your work.