4. Think offline first and think about the real-life context of use

4. Think offline first and think about the real-life context of use

A trap that me and many makers usually fall into is to start thinking immediately about the product details when we build something new. How the navigation will work like, what framework are we going to use, how our landing page will look like, and so on.

Instead of this, before you start building something start by asking yourself the following question:

"How would this work if it was in the offline world?"

An example from iOS

image

Apple used skeuomorphism and revolutionised the world of digital product design.

Scrolling in iOS was a big thing because it had physics (friction and acceleration) integrated into it and it felt real.

An example from Matt's product

Matt is a fellow indie maker I help with UX design. He is currently building a web app for US citizens, where they can connect their bank accounts and generate a report for their annual tax income statement.

During our session we were working on the loading states of his app. He couldn't understand what's the best approach when it comes to loading and how to approach it.

So I asked him. "How would your app work if it was in the offline world?" In the real world you would have to go to your bank and talk with one of their employees to generate this report for you. They would ask you several questions and after a few minutes you would get your report.

This analogy solved most of the problems that Matt had with designing his app. Suddenly he had something to compare his app with, and he could understand what people would expect.

So when you design and build something new, ask yourself how would this be, if it was in the offline world.

As humans the offline world is what we are used to and what what are designed for. So start with that.

Here is the video of the full-session we had with Matt.

"What are the exact conditions and context that users will use what I am building?"

An example from Uber

Uber is an app that most of us have used at some point in our lives. We may used it to go from home to a restaurant, to go quickly to an appointment that we are almost late or to go back home from the airport.

Even if we do the same task every time (order an Uber rider), we do it under a different context. Sometimes we are relaxed, sometimes we are in hurry and sometimes we may even be drunk because we were at a night club 😅

An example from TicketSwap

Back when I was working at TicketSwap we were building a feature called "Share your tickets with friends". TicketSwap is a marketplace of second-hand tickets where people can buy and sell tickets for festivals in a safe and transparent way.

The feature scenario was simple. "You as the user has bought 3 tickets for you and your friends. You want to share 2 of your tickets with your friends so that they can pass the entrance control and get into the festival."

I started immediately designing a prototype. You will open the tickets, you will click on the share button and then there will be a link you can use to share them with your friends. Once they open it they will have to sing up to TicketSwap and get access to their tickets.

Even if it felt simple and right I found out that my approach was wrong. Once I did the first user test I received the following feedback. "I feel that the way I have to share my tickets is too time consuming. Whenever I go to festivals, I share my tickets a little before we get to the entrance and I usually take a screenshot of them and send them as a message. I don't have the time to create links and ask them to sign up".

That's what I missed from my design process. I forgot to think the context under which people would use this feature in our app. I thought only of the scenario of being at home and using the app in a relaxed way. But in reality the most common scenario is to share the tickets at the last minute before you show up at the entrance.

Therefore, this feedback point changed everything and I realized that the UX should be focused on speed and simplicity.