Blog

Reversibility of an interface element

Reversibility is a property of an interface input control, where the user can return the control to its initial state at any time. Or, more generally, where the user can freely switch between all available states. Irreversibility, consequently, is when the element has states to which it cannot be returned after some actions. Well-designed controls are reversible.

An example of an irreversible control is a group of radio buttons of which none are initially selected. Once one option is selected, there is no way to return the group to the initial blank state. This creates discomfort and frustration. In a proper radio group exactly one element is always selected, including in the initial state, so the group is reversible.

But what if picking an option is required to proceed to the next step? There is no point in unselecting all options! Why would the user want that? Well, the reversibility requirement stands even if the initial state is not “valid”. This has to do only with the mechanics of the interface control, not with its role in the interface external to it. It affects the sense of control. Consider this: a text input field does not resist having all characters erased from it, even if it is required. Any other element, if it has a blank state at all, should let you return to it. In the case of a radio group, remove the blank state altogether by providing a default option.

Here’s another example of irreversibility. Suppose you have a required text field, initially blank. The user clicks the field, then clicks another element, leaving the field blank (or fills it in, but then erases everything). The system now draws a red border around the field, hinting that the field cannot be left blank. Now it is impossible to return the field to its initial “clean” blank state. A solution would be to fade out the red border so that the field returns to the initial state after a second.

ATP: how kids become programmers

John Siracusa in the 446th episode of ATP talks about how kids become programmers and how it didn’t work with his kids, starting at 40:36:

With my kids, I had no success getting them to want to learn to program at any age. I didn’t really push it that hard, but I was putting it in front of them, see if they are into it, see if it would grab them. And it never got hooked. And we all — all three of us — know what it means to get hooked on programming. It’s one of those things that just happens, right? You can see when programming gets its claws into somebody. And you know, it’s not subtle. You’ll find yourself just sucked in and just constantly working on this program — we all experienced it. That’s how we became who we are. But when that doesn’t happen, it doesn’t happen.

How I stopped using Duolingo

Duolingo used to be a great app. I opened in to practice almost every day. But then they changed the design:

The redesign rolled out gradually — apparently they were testing it. There was a period when the iPhone was already broken, but it was still possible to use it with an iPad or on the web. I chased the old design for a while, but soon after the final switch to the new one I lost interest in studying.

There was a lot of outrage online about the change, including in the comments under this video. But the design has not been rolled back, which means Duolingo’s numbers are good.

Before and after:

In the old design, as you went through the lessons, the next ones opened in bundles. In the example on the left, you could choose from: basics, phrases, animals, food, family. Sometimes I was in the mood to learn something new, so I tapped an untouched topic. Sometimes, on the contrary, I wanted additional practice in something I already had an idea of, so I went there. When I made a choice to learn something, as the owner of my choice, I was motivated to learn it. The interface was informative and engaging with a variety of topics. Sometimes it was fun to scroll up and be pleased with how much I already learned. Sometimes it was interesting to scroll down, to the lessons locked so far, to be inspired by what awaits next. Maybe the remaining required lesson isn’t very appealing, but look at what’s there to learn afterwards!

The new design has none of that. The endless wave of identical coins means nothing, you just have to tap the green one: you have already completed the previous ones, while the next ones are not available yet. If you scroll up or down, the endless wave of already completed or not yet available unsigned coins continues, and there will even be a button to scroll back to the green coin. The informativeness of this screen is literally zero, it gives you no choice, it exists only for you to tap the one single button! Even the iPad cat games are more interesting.

In the video, they tell us that was the intent:

We’ve redesigned the home screen to better guide you through lessons.

Translated from marketing speak, “now we decide what you learn”.

Follow a path crafted by our learning experts to help you better reach your goals.

It’s different for everyone, but for me, “reach your goals” is the weakest motivator in life. I want to effortlessly enjoy the process and then suddenly be thrilled to discover my own accomplishments. Duolingo doesn’t give me that anymore.

And don’t worry, we’ve kept all the progress you’ve made so far

What are you talking about? I no longer see the huge list of topics I’ve completed. From my point of view, all the progress I had, I’ve lost.

Anyway, it was a great app.

Onboarding

Often when we open an application, we see a screen that tells us about it or about some recently added features. The screen may consist of several pages that you have to flip through one by one. There may be a button to skip it all and go to the main interface of the application. This is commonly referred to as an onboarding screen.

It is bad practice to do so.

The statement may seem ridiculous to you as so many products have onboarding screens. Unfortunately, most of their creators don’t even ask themselves the question “what if we are wrong?” In some occasions I asked them why they do it, and I heard: “well, it’s onboarding”. People don’t even realize that this doesn’t answer my question — the belief that this is the right thing to do is so strong.

Let’s examine what’s wrong with this kind of onboarding, what task it’s designed to accomplish, and how to accomplish that task well.

Summary: The onboarding screen appears at the wrong time, prevents you from using the application, and when you really need the information from it, you can’t find it anymore. This causes frustration and reinforces the habit of skipping messages without reading them. It is better to make tutorial elements an integral part of the interface and allocate a permanent place for information about new features and changes.

Why not introduce the application at first launch

First, consider an onboarding screen that introduces you to the application as a whole.

In the dumbest case, it’s advertising: onboarding pages praise the app and its features. However it is nonsense to advertise an app that the user has just installed and opened: we have already received the desired attention; it is now time to stop seeking it and start converting it into value. The user also has their expectations of the application and wants to start using it. They now have to overcome our annoying obstacle. So advertising should just be removed.

In a slightly less dumb case, onboarding tries to teach you how to use the application: this is how you order a pizza, this is how you make a money transfer. If the user already knows this, it’s again just an annoying obstacle to their goal. If the user doesn’t know this, however, we present them with an uncomfortable choice. They need to read our onboarding screen carefully and memorize it so that they can later apply what they’ve learned to the real interface, which they haven’t even seen yet. But as a user, it’s impossible to estimate how mindful I have to be and how thoroughly I have to memorize. Maybe I will be able to figure it out on my own in the real interface?

Just think how crazy this is. You buy a new washing machine, and they forcibly hand you the owner’s manual and say: “You can throw it away, but if you can’t understand something later, no one will help you”. Uh.. Can one not figure it out without the manual? We don’t know. Well, can’t I just leave the manual in the box and take it later if I need it? No, you can’t: you either have to read it now or throw it away.

It is worth analyzing the main interface carefully. How to make it clear without the initial tutorial? If you can’t do without hints, how can you provide them so that they don’t interfere with the usage of the application? Maybe you need to add explanatory text somewhere. Maybe in the tricky places you need “?” buttons that open the detailed explanation. Or maybe you need your own educational YouTube channel that is easily accessible from the interface.

Why not talk about new features after an update

Now consider an onboarding screen that highlights new features and changes.

The same problems are even more acute here. When somebody opens your application for the very first time, they probably have little expectations. However, when the user is familiar with the application, when they’ve been using for some time already, they launch it with a specific purpose, for example, to check delivery tracking or to pay the household bills. Most likely, they have a “plan”: they remember what corner they are going to tap first, what will appear next, where they are going after that. But suddenly, instead of an interface they expected, they get a presentation of new features they don’t need right now!

In this situation, the urge to skip the onboarding screen is even stronger, and so many users simply won’t learn about your innovations. Again, not because they don’t need them at all, but because they don’t need them at that moment. If your application is being actively developed and updated, the constant talk about changes will be annoying, and the habit of skipping them will become more entrenched each time.

To keep users aware of what’s new, it’s a good idea to provide a permanent place in the application for this purpose. My favorite example is the messenger Telegram:

The designers took advantage of the nature of the application: the information about new features comes as chat messages from a special “Telegram” account. When you open the application, you see these messages on an equal footing with others. You can chat with your friends or respond to important work messages first, then learn about Telegram itself. Each feature is revealed in a separate message with a nice video. The message can be forwarded to someone who, you believe, will benefit from the feature — the advertising effect is amplified for free. And, of course, no one prevents you from returning to these messages at any time later. That’s exactly what I did to take the screenshots.

Even if your product is not a messenger, you can find some permanent place to talk about new stuff. And for people to remember to go there, you can put a red badge when unread items appear. What’s important is that the rest of the application’s features are available even before the user has read everything.

Good user interface and good business

I start my course User Interface Fundamentals with the subject of humaneness: the interface should be for the human, not the other way around. When an interface stands in the way and pisses you off, it’s a bad interface. In the lecture on habit, I talk about the problems with confirmation windows and blocking messages, and onboarding screens are examples of that. They reinforce the habit of reading nothing and agreeing with everything.

Onboarding screens have problems similar to those of confirmation windows, yet both things are very common. The reason is that in product development, the goal is rarely “to make the user happy”. Typically, those in charge of a product look at other metrics. Let’s say the onboarding screen is watched by 10% of users and as a result sales grow by 1%. Who cares then if it disturbs the rest of us? The gain is greater than the loss, so fine.

Reader Egor, who works as an analyst in a large product, once wrote to me:

Do you believe an a/b test would help to settle this debate? Say, we’ll show the onboarding screen to half of new users and skip it for the other half, then look at two metrics: the conversion rate from first session to a completed order and the time from application launch to completed order. If the conversion rate with the onboarding screen is higher while the time to order does not increase (i.e. the time a user spends in onboarding is won back later), would you agree that onboarding screens are justified? And how do you generally feel about validating product hypotheses with a/b tests?

I would agree even without the test. But what this test would prove, at best, is that it is better to tell about the application by onboarding than not at all. And what I’m saying is that there’s a better way than onboarding.

As for validating product hypotheses, it has little to do with a good user interface. Sometimes you can boost the metrics by degrading the interface: by reducing the clarity of options, by nudging the user towards a disadvantageous purchase; by making it harder to unsubscribe. A good interface is only sometimes important to product success, but sometimes it is not. Just look at Facebook or Booking.com. I wouldn’t want to have anything to do with making these very successful products.

In a large product with pragmatic management, adding an onboarding screen may indeed be the most feasible solution. It doesn’t interact with the rest of the application in any way, it doesn’t add any new logical connections, a separate team can even be responsible for it. It is much easier, faster, and cheaper than thinking about how to improve the educational properties of the product itself.

But not all businesses operate on squeezing metrics at all costs. Some have a different set of values, where product quality and user delight matter. Sometimes there’s an opportunity to think carefully about these things, rather than just do what everyone else does.

I find that onboarding is often done because the creators genuinely think it’s a good idea, rather than for the pragmatic reasons mentioned above. They don’t even look at the metrics, don’t compare user annoyance with the gains in conversion rate. They just put up a splash screen because they absolutely want to talk about the new features! In such cases, when I talk about the disadvantages, people are happy to engage in a discussion of alternatives.

Yes, doing things well is usually harder than doing them poorly, but the effect can also be greater.

One more question please

“Ilya, it all makes sense, but there’s a really amazing feature that we’ve been working on for two years. We even made a video about it! We want to put it in the onboarding screen, because it’s important for us that everyone sees it!”

It’s great that you’ve made a feature that you are proud of. I sympathize with your desire to tell everyone. If you put it in the onboarding, you’ll blow the opportunity. How could you communicate about the feature in a way that everyone will love it? Give this question at least a fraction of the care you gave the feature itself.

Marco Arment on UI stability

In ATP Episode 439 Marco Arment had a good speech on UI stability, I even took time to write it down. It starts at 35:07:

UIs so often lack stability. It is such a critical quality. You want the UI to be stable.

Not every surface should be “live”... If you try to select some text on a website with a mouse on a desktop, you don’t want every single thing that you can click on or accidentally brush against with your finger on a phone to be something that is live, that does something. You want stability, you want things to feel solid, and predictable, and forgiving. And not being so susceptible to things like accidental input or imprecision in input... People are doing things unintentionally.

You also don’t want the UI to be moving around when people are trying to use it. And I feel like a lot of the current Mac design language these days, where everything is being hidden behind hover states and then things animate somewhere out of the way and change where they are... this is all violations of UI stability. It makes everything a hot zone or a live zone. And things are jumping around, and it’s disorienting, and it’s inefficient, and it’s unintuitive as well, and undiscoverable and all sorts of other problems.

Anything you can do to make a UI more stable in a sense that things don’t move around too much, there aren’t too many different modes where things come in and out or slide around, or pop in, or pop out, that makes it easier and better and more calm to use for more people. And it’s a better design.

Stockholm: airport and connection to city

I’ve shown you the Stockholm metro in detail.

But I’ve got a lot more from Stockholm. Today it’s the airport and the connection to the city.

Arrivals:

It’s a great idea to point to the next restroom in the narrow hallway:

In the baggage claim area there is a nice advertisement for the express buses to the city:

Swedish is white, English is yellow. Customs has two spaces:

Passage to another terminal:

Stairs to the boarding gates. Curiously, the arrows and exit numbers are yellow, not white:

But I had to go to the city, and the express bus didn’t appeal to me. It turned out to be cheaper and more interesting to get there by regular transportation, not a dedicated airport service. I took a bus to a place called Märsta, then a commuter train from there.

Outside the airport:

The bus stop:

Bus 583 to Märsta:

An almost-selfie from the bus:

A bus stop in Märsta:

The commuter train station next to it:

The trains await at the platform:

A sign:

The door doesn’t open automatically. A funny character points to the button from above:

Inside the train:

There’s an ad in the transportation system style here, too, like I’ve shown on metro trains before. Nice:

The “don’t sit with your feet on the other seat” icon:

I got off at Stockholm’s Central Station and some people went further on. Now the character points to the button from below:

After three days in Stockholm, I went back to the airport — this time, on the very bus from the ad. It runs from the Central Station as well. The boarding gate has automatic doors:

Departures:

The map of terminal 5:

The pictures are from the trip in June 2016.

See also:

Introducing the book “Designing Transit Maps”

Please welcome my second book, Designing Transit Maps. It’s a practical guide to transit map design and probably the most important work of my life so far. The digital book is released by Bureau Gorbunov Publishing. The publisher says:

The book speaks of transit maps history, important principles of their design, and how they evolve together with their networks. The author talks about techniques: plotting the lines, denoting the stops, choosing the fonts, and composing the final poster.

Few designers have an occasion to design a subway map. But the principles and techniques discussed are applicable to any tasks of complex information display: org charts, family trees, control-flow diagrams, fire escape plans, military operation plans, project timelines, architectural drawings. The book sharpens the reader’s eye and inculcates attention to detail.

Circuit drawings are beautiful in their own way, but they immediately tell the reader: “I’m for the pros”. This is not an option for public information graphics. The designer has to untangle complex ties, find the best way to represent key objects, correctly position the labels. No matter how sophisticated the material is, it’s crucial to achieve clarity and legibility in display. Transit maps are a great subject to develop this skill.

The book consists of five parts: The challenge, The principle, The layout, The details, and The system. The chapters of the book are being published gradually. We started with the first three chapters, “Maps and Reality”, “The first transit maps”, and “Transit map diversity” in January:

We followed up with “Map as a symbol” and “Finding a solution” in February, completing the first part:

By the way, each part ends with an interactive test covering its key ideas.

In April, we started publishing the next part with the chapters “Correspondence between lines and routes” and “Color coding”:

In June, we released the chapters “Geometry”, “Orientation”, and “Scope”:

Today, we are releasing the closing chapters on the second part, “Granularity” and “Freedom”, and the chapter’s interactive test:

So two fifths of the book are already available for reading, and I very much encourage you to subscribe and read the book. Learn more about the book and its revolutionary digital format on the publishers website. There are also readers reviews and a free sample chapter “Bends” from the fourth part.

Enjoy and tell your friends and colleagues!

Novosibirsk

Let’s start with the overall impression. There are buildings with fancy signage. “House of Culture of the October Revolution”:

Dimensional signage:

You might assume this is a view of the same building from the other side, but no, this is a different building:

Love the old Aeroflot logo very much:

Oblpotrebsoyuz:

Kukol (apparently, from “Teatr kukol”, meaning “Puppet Theater”):

Kassy (box office):

A nice arrangement of ул. (street) and им. (named after) on the sign:

Sometimes buildings from different eras make good neighbors:

A house with a huge canopy or whatever it is:

Another nice house, but with a terrible fence:

The coolest house:

The coziest house:

The bluest house:

Courtyard as if you were in London:

Underpass:

Looks bad, but on the other hand, it’s about Mayakovsky, so there is something to it:

A more typical view of Novosibirsk is like this:

The pictures are from the trip in April 2021.

Earlier Ctrl + ↓