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.

Here is a catastrophic error when user hit an edge case. Source

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

Grace Hopper found the first bug ever! Source

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.

Rejectors < Most Users > Power Users. Source

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.

Camera Special heart ? from Periscope

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?

Bringing translations in your mocks can make a HUGE difference ?

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.

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.

Author: Asli Kimya

Collect by: uxfree.com

Comment

Top