Thinking like a developer, part II: design the edge cases
Bridging the gap between software engineering and UX design processes and languages.
In my first post, I talk about how can designers build empathy with developers and start thinking like them. My goal with this article is to offer handy tips for designers to use software methodology and jargon in their process. Should designers code? No. But one superpower we can bring into our process is designing for the edge cases.
What is an edge case?
In the development of a software program, engineers first consider a general case: the average scenario that is most likely to happen. Afterward, they consider the edge cases: boundary conditions that are less likely to happen. But if they don’t take care these, the program can crash and burn.
What I mean by designing for the edge cases is a fancy way of saying: Think of all your users .You can design the edge cases by debugging with extreme users and localizing not just for languges also for cultures.
Debug with Extreme Users
Software applications can encounter either software errors or hardware errors. A bug is the issue in the code that is causing that error. Grace Hopper, one of the first female programmers, recorded the first software bug. She found a moth in one of the components of Mark II. Who knows what the moth was doing there, but bugs came to take the blame for software errors since then.
A great way to debug issues considering your designs is examining the extreme users. People who fall off the wagon too early. And those who use the wagon so often that they want the wagon to fly and to become a submarine overnight! Formally, extremes are either the rejectors, who uninstall your app or churn really quickly, or the power users, who use your product day and night. Extremes are important, as they help you identify the pain points.
We hold weekly office hours to stay in contact with our users. Our power users can ask us questions over a messaging platform. Usually one person from our support team and one from the product team join these conversations.
Back in the early days of Periscope application, broadcasts expired within 24 hours. One piece of feedback we got from a power user was that their fans would take screenshots during the stream. They had no way of knowing. This was controversial, as we had promised people that their stream would disappear with no evidence. We wanted to solve this sensitive issue in the most thoughtful way.
We made a camera heart that popped in the middle of the heart stream whenever a viewer took a screenshot of the stream. Our broadcasters loved this custom heart, it felt special. Also people liked having another way to feel the pulse of their watchers. In this case, they were so engaged that they wanted to keep memories of the broadcast experience in their camera roll!
Localization: Know your audience
Localization in software is the translation and adaptation of a program. While traditional translation takes place after the source document is final, in software localization runs in parallel with the development. This way the feature can ship in all language versions. As a designer, considering your users should include thinking about internationalization. Here are some questions to ask yourself to design for localization:
Most basic question: what language do you design in?
We design in English, since it’s the common ground that is familiar to everyone on the team. This particular example I have is for button text. One challenge with the phrase “Go live” is that this button reads both go ‘lɪv’ and ‘laɪv’. Since ‘what’s happening right now’ is core to Twitter, we decided that all capital LIVE reads laɪv. Besides capitalizing the word, we often use it in a rectangular red badge, encapsulating it like the live sign on TV.
What translations do you include in your designs?
Additionally, it is important for us to design for some of our biggest markets. An easy way of doing this is placing translated strings in our mocks. For example, continuing on the button text example, some of our largest markets are in Turkey and Russia. “Canlı Yayın Başlat” and “начать трансляцию в прямом эфире” are much longer in context as you can see.
Is your imagery culturally universal?
Another way to consider different markets is understanding cultural connotations. For instance, Twitter uses a Quill for the Tweet compose icon.
Tweet compose is arguably the most important action on the platform. Yet the Western idea of a quill as a writing tool doesn’t play out on the East. In Japan, one of our fastest growing markets, they never had quills but just brushes. Research showed that too many people in Japan tried tapping it to update their timeline, because it looked like a refresh button. We eventually landed on a single word instead of an icon: Tweet. Tweet is a word that Twitter invented. And Tweet is universal to all Twitter users.
From Software to Design
Jargon to takeaway
An edge case: a boundary condition that is unlikely to happen in the general use case of the program.
A software bug: an issue in the program that is causing a software error.
Debugging: fixing a software bug.
Localization in software: the translation and adaptation of a program.
Processes to takeaway
Design for edge cases: thinking of all users with different languages, cultures, and views of the world.
Debug with extreme users — they give you insights about the user experience.
Localize not just for languges also for cultures. Do this in your mocks.
I used to believe thinking in code while designing restricts creativity. I wanted my designs to be unprecedented. I knew that conciseness and reusability in programming was important. But I did not see the link between unique designs and the systematic way of code and logic.
I discover that the more I bring what I know from programming into my design practice, I am able to move faster and iterate more throughout the process. By including software methodology in my design process, I grow as a designer.
Here is Part I, where I talk about how designers can think in code.
Here is Part III, where I explain why and how to design with the engineering constraints.
Follow me on Twitter @aslithelion, leave a reply, and don’t forget to 👏👏👏 if you read this far! I will share more tips on how to think like a programmer as a designer.
