RWD Weekly #406 Interview Series Stephanie Walter

Interview with Stephanie Walter

How do you find working with clients these days? Is responsive something that you have to sell in any more or does everyone get it now?

I’m currently working for the European Investment Bank on the redesign of an internal tool. It’s kind of a “special” situation since we (well IT and infrastructure) have 100% control over the devices. Everyone has the same computer, screen. Responsive is not a priority on this project because no mobile phone can actually access this internal app (proxies and everything). That being said, there’s more and more people with tablets like surface pro in the higher levels or hierarchy in the bank. My main concern at the moment is not that much responsive in the sense of “making it work at many screen size” but more about making sure our interface will work on touch screens. It’s a big challenge since it’s mostly super big tables with a lot of columns (welcome to investment sector) and graphs with figures that usually appear on hover. The current challenge is quite interesting. The client knows that we should make it “more responsive” and I still work with responsive in mind, but for this specific project, it’s not a priority.

For my previous client (airline company), the target was more B2C (and a little bit B2B). As designers, responsive was our top priority. We made sure to always design both mobile and desktop version of the page. So responsive became “part of the process” for us. It was a little bit less true for developers for example. We still have some sliders that don’t work on touch because they were built 4 years ago when none cared.

What is it now that you find the hardest when speaking with clients from a website build point of view, and how do you go about explaining why it is important?

At the moment everyone wants a “design system”. But most clients don’t understand the amount of work that is hidden behind those 2 words. A lot of people are convinced that a design system is a miracle “thing” that will solve all their problems. I say “thing” because most of the clients don’t know what it is. They heard the word (like they heard responsive 8 years ago). When you start explaining that it will take time, budget, even if you start small, all of a sudden there’s none there anymore. It takes a lot of time to explain to them why this will take time and a specific budget. You usually start small, but they imagine that it will be quick and not cost anything. There’s a lot of managing people’s expectations and explaining to do. Just like when we had to explain to them responsive a few years ago 😀

So much has changed since Ethan’s eureka moment, what are your go to implementation methods for responsive sites? How do you handle layout, typography, images, video etc?

I don’t write code for a living. I concentrate on user experience and a little bit of UI design. So, as a designer, my job actually changed a lot. We used to deliver pages, a lot of them. Now we deliver components. And those components exist at different size. That’s the complex part to explain (even my students struggle with that). But it’s also the super interesting part. Ethan concentrated at the beginning on global layout and images.

Today, when I design a component at different sizes, I know that this component might be used at different sizes on different devices. But I also know that those different sizes can be used for different containers.

Let’s take the example of a cooking site with a “recipe thumbnail” element. I design this element in 3 sizes for the search results or recipe category page (on the left). But if I think beyond screen size and more into modular design and re-usable component, I could re-use the small version of this component in different contexts of the desktop site. For example, if I want a category page with more of a card layout, in a sidebar and even in a slider of “related recipes”.

Responsive design methods open a big area of “ reusable modular component design” for us, far beyond screen sizes. That’s why everyone is super excited about container queries (https://css-tricks.com/lets-not-forget-about-container-queries/). Having the ability to change the layout no only based on the viewport size but also on the size of the parent container will be a game changer!

What are the top three issues you’re still facing when building a responsive site?

Let’s call those “challenges” instead of issues shall we 😀

Challenge number one: touch screeeeeeeens. Let’s face it: we have solutions to adapt the layout to screen (and even container with JS) size. But optimizing a touch is a whole other level of headache. When there were only a few small phones it was easy: you could almost rely on screen size. But today, a lot of tablets have super huge resolution. We have computers with touch screens. Apple wants to launch this summer an iPad with a trackpad on the keyboard. It’s a whole level of uncertainty and there’s also no way to detect what input type your users are currently using. Even if they have a mouse, if the device also has touch capabilities, they might switch between both. There a nice article about that: Touch Devices Should Not Be Judged By Their Size. This is a huge challenge. My advice for designers: treats “mouse hover” capabilities as a bonus, not a feature. Make sure your interfaces work without hover capabilities.

Challenge number two: communicating with developers about breakpoints. Even if we designers design 2, 3, 4 versions of the same component, we can’t really decide about the exact breakpoints to change this component in our design tools. We will almost always end up fine tuning this with developers in the browser. The idea is “design in tools, decide in the browser”. And this is no always easy to make developer understand. I end up in a lot of situations where I’m asked to either decide about breakpoints upfront, or to follow the “framework’s main breakpoints”. The problem with that is that it might or might not work for specific components. For me responsive design is a big collaboration between designers and developers with a lot of fine tuning in the browser.

Challenge number three: optimizing for touch capabilities. There’s a lot of cool things mobile browsers are capable of today (shameless plug. I have a talk about that if you are interested: Super Secret Powers of Mobile Browsers – Talk slides). But not all are supported on all devices and browsers. Some APIs are still glitchy. So, there’s a lot of nice things to do, but we need to find fallbacks for those.

We started off with lots of m.dot.sites when mobile arrived. Google was a huge part of changing that approach by saying that all content should be found on a single URL. One true source. In recent years Google have incentivised the AMP Framework as a way to provide a new/better experience to mobile users. What are your thoughts?

I am not a big fan of the AMP format from a user experience perspective. It strips most of the brand identity of the site. Users might get confused and wonder if they arrived on the right site. It’s also annoying when users share the URL from their mobile since it keeps (last time I checked) the AMP URL.

I still think the performance boost is interesting. AMP mobile sites (for newspapers for example or cooking sites) are super performant because they don’t load all of the 100000Mega of crappy analytics and trackers desktop sites load. You can get the same performance boost without AMP. But those industries love to scrap data and push adds (most of the time because it’s their main source of revenues)

As a business/product owner, what is the most frustrating thing you find trying to take a product out across today’s diverse device landscape?

For me the biggest challenge is the consistency of the experience. I get the feeling that a lot of companies who had a m.dot site built a special team for it. It’s easy to spot: the icons on mobile vs desktop sites are not the same, some features are missing, etc. Many of those companies are building a responsive site now instead. But there’s still some consistency issues sometimes. The bigger the product, the bigger the teams, the bigger the issues. So, it’s hard to keep consistency.

It’s even worse when those companies subcontract part of it to external agencies. I worked for clients who didn’t have any designers in house until a few months before my arrival. They worked with many different agencies: one built the responsive site, one built the mobile app, another does the print campaigns, etc. And they lost a lot of consistency because everyone was doing what they wanted.

Even when you have designers internally, if they work in different teams, offices and don’t talk to each other, you end up with the same problems.

To build a great product across today’s diverse device landscape, you need some designers that will see the “global” picture. As UX designer, that’s why I like tools like customer/user journey maps. For those not familiar, it’s a chronological visualization of the experience of the user across their whole journey. This helps think about different touch points (mobile, desktop, tablet, even big tablets in stores, etc.) and avoid the frustration of inconsistent experiences.

Prediction time. What are we going to see towards the end of 2020 and into 2021?

Hhaha I’m super bad at predictions. Wild guess for me would be:

  • More machine learning and AI to personalize the experience
  • More multi input devices that can have both touch and mouse/capabilities
  • I hope container queries because those would solve a LOT of technical problems, we have

Thank you so much for your time, if our readers want to learn more where can they track you down?

Subscribe to our Newsletter

Add your email address and receive an email every Friday covering off everything worth knowing about building your websites responsively.