In March 2016, Google updated Material Design to add bottom navigation bars to its UI library. This new bar is positioned at the bottom of an app, and contains 3 to 5 icons that allow users to navigate between top-level views in an app.

Sound familiar? That’s because bottom navigation bars have been a part of iOS’s UI library for years (they’re called tab bars in iOS).

Bottom navigation bars are a better alternative to the hamburger menu, so their addition into Material Design should be good news. But Google’s version of bottom navigation bars has a serious problem: mystery meat navigation.

Whether you’re an Android user, designer, or developer, this should trouble you.

What’s mystery meat navigation, and why’s it so bad?

Mystery meat navigation is a term coined in 1998 by Vincent Flanders of the famous website Web Pages That Suck. It refers to buttons or links that don’t explain to you what they do. Instead, you have to click on them to find out.

(The term “mystery meat” originates from the meat served in American public school cafeterias that were so processed that the type of animal they came from is no longer discernible.)

Mystery meat navigation is the hallmark of designs that prioritize form over function. It’s bad UX design, because it emphasizes aesthetics at the cost of user experience. It adds cognitive load to navigational tasks, since users have to guess what the button does. And if your users need to guess, you’re doing it wrong.

You wouldn’t want to eat mystery meat—similarly, users wouldn’t want to click on mystery buttons.

Strike 1: Android Lollipop’s Navigation Bar

Material Design’s first major mystery meat navigation problem happened in 2014 with Android Lollipop.

Android Lollipop was introduced in the same conference that debuted Material Design, and sports a redesigned UI to match Google’s new design language.

One of the UI elements that got redesigned was the navigation bar, the persistent bar at the bottom of Android OS that provides navigation control for phones without hardware buttons for Back, Home and Menu.

In Android Lollipop, the navigation bar was redesigned to this:

See the problem?

While the previous design is less aesthetically appealing, it’s more or less straightforward. The Back and Home icons can be understood without the need for text labels. The 3rd icon is a bit of a mystery meat, but on the whole, the UX of the old navigation bar wasn’t too bad.

The new bar, on the other hand, is extremely pretty. The equilateral triangle, circle, and square are symbols of geometric perfection. But it’s also extremely user-unfriendly. It’s abstract—and navigation controls should never be abstract. It’s full-blown mystery meat navigation.

The triangle icon might resemble a “Back” arrow, but what does a circle and a square mean in relation to navigation control?

Strike 2: Floating Action Buttons

Floating action buttons are special buttons that appear above other UI elements in an app. Ideally, they’re used to promote the primary action of the app.

Floating action buttons also suffer from the mystery meat navigation problem. By design, the floating action button is a circle containing an icon. It’s a pure-icon button, with no room for text labels.

The truth is that icons are incredibly hard to understand because they’re so open to interpretation. Our culture and past experiences inform how we interpret icons. Unfortunately, designers (especially, it seems, Material designers) have a hard time facing this truth.

Need proof that icon-only buttons are a bad idea? Let’s play a guessing game.

Below is a list of what—according to Material Design’s guidelines—are acceptable icons for floating action buttons. Can you guess what each button does?

Ok, that’s a simple one to warm you up. It represents “Directions”.

What about this? If you’re an iOS or Mac user, you might say “Safari.” It actually represents “Explore.”

Things are getting fun (or frustrating) now! Could this be “Open in contacts”? “Help, there’s someone following me”? Perhaps this is a button for your “Phone a friend” lifeline.

Hang on, this is the button for “Open in contacts.” Right? Or is this “Gossip about a friend” since the person is inside a speech bubble?

Ready for the final round? Here’s the worst (and most used) icon:

You might think the “+” button is rather simple to understand—it’s obviously a button for the “Add” action. But add what?

Add what: that’s the problem right there. If a user needs to ask that question, your button is officially mystery meat. Sadly, developers and designers of Material Design apps seem to be in love with the “+” floating action button.

Precisely because the “+” button seems so easy to understand, it ends up being the most abused icon for floating action buttons. Consider how Google’s own Inbox app displays additional buttons when you tap the “+” floating button, which is not what a user would expect:

What makes things worse is how the same icons have different meanings in different apps. Google used the pencil icon to represent “Compose” in Inbox and Gmail, but used it to represent “Edit” in its photo app Snapseed.

The floating action button was intended to be a great way for users to access a primary action. Except it isn’t, because icon-only buttons tend to be mystery meat.

More on floating action buttons:

Strike 3: The New Bottom Navigation Bar

This brings us to the bottom navigation bar, introduced in March 2016.

For bottom navigation bars with 3 views, Google’s guidelines specify that both icons and text labels must be displayed. So far, so good: no mystery meat here.

But for bottom navigation bars with 4 or 5 views, Google specifies that inactive views be displayed as icons only.

Remember how hard it was to guess what the floating action button icons mean? Now try guessing a row of icons used to navigate an app.

This is just bad UX design. In fact, the Nielsen Norman Group argues that icons need a text label, especially navigation icons (emphasis theirs):

“To help overcome the ambiguity that almost all icons face, a text label must be present alongside an icon to clarify its meaning in that particular context.… For navigation icons, labels are particularly critical.”

That Material Design’s newest UI component condones mystery meat navigation is not only frustrating, but also weird. Why should text labels be shown when there are 3 views, but be hidden when there are 4–5 views?

An obvious answer would be space constraints.

Except tab bars in iOS manage to contain 5 icons, and still display the icon and text label for each of them. So space constraint isn’t a valid reason.

Google either decided that icons can sufficiently represent navigational actions (which is bad), or they decided that aesthetic neatness is more important than usability (which is worse). Either way, their decision worsened the UX of millions of Android users.

Material Design and Form over Function

When Material Design was launched in 2014, it was to much fanfare. It’s bold, and rides on (and one-ups) the flat design trend. The pairing of vibrant colours and animations make it pretty to look at.

But perhaps it’s a little too pretty. Perhaps while working on Material Design, the designers got a little carried away.

Time and again, Google’s guidelines for important buttons and bars seem to prioritise form over function. Geometric prettiness was chosen over recognisability in Android’s navigation bar. Aesthetic simplicity was championed in floating action buttons, turning them into riddles in the process. Finally, visual neatness was deemed more important than meaningful labels in bottom navigation bars.

That’s not to say that mystery meat navigation is a Google-only problem. Sure, you can find mystery meat in iOS apps too. But they don’t usually appear in critical navigational controls and promoted buttons. They also aren’t spelt out specifically in design guidelines to be mystery meat.

If Google designers could devote time and effort into creating speed graphs for animations, perhaps they could spend a little time to make sure their designs aren’t mystery meat.

After all, an animated mystery button is still less delightful than a static but clearly labelled button.

SNEAK CONTEXT IN. (ALWAYS)

A dataset might lead to many stories. Data is a tool that filters reality in a highly subjective way, and from quantity, we can get closer to quality. Data, with its unique power to abstract the world, can help us understand it according to relevant factors. How a dataset is collected and the information included — and omitted — directly determines the course of its life. Especially if combined, data can reveal much more than originally intended. As semiologists have theorized for centuries, language is only a part of the communication process — context is equally important.

This is why we have to reclaim a personal approach to how data is captured, analyzed and displayed, proving that subjectivity and context play a big role in understanding even big events and social changes — especially when data is about people.

Data, if properly contextualized, can be an incredibly powerful tool to write more meaningful and intimate narratives.

To research this realm, I undertook a laborious personal project: a yearlong hand-drawn data correspondence with information designer Stefanie Posavec. We have numerous personal and work similarities — I am Italian and live in New York, and she is American and lives in London. We are the exact same age, and we are only-children living far away from our families. Most importantly, we both work with data in a very handcrafted way, trying to add a human touch to the world of computing and algorithms, using drawing instead of coding as our form of expression. And despite having met only twice in person, we embarked upon what we called Dear Data.

For a year, beginning Sept. 1, 2004, Posavec and I collected our personal data around a shared topic — from how many times we complained in a week, to how frequently we chuckled; from our obsessions and habits as they showed up, to interactions with our friends and partners. At the end of the week we analyzed our information and hand-drew our data on a postcard-sized sheet of paper, creating analog correspondence we sent to each other across the Atlantic. It was a slow, small and incredibly analog transmission, which through 52 pretexts in the form of data revealed an aspect of ourselves and our lives to the other person every week.

We spent a year collecting our data manually instead of relying on a self-tracking digital app, add- ing contextual details to our logs and thus making them truly personal, about us and us alone.

For the first seven days of Dear Data we chose a seemingly cold and impersonal topic: how many times we checked the time in a week.

On the front of my postcard, (as shown above) every little symbol represents all of the times I checked the time, ordered per day and hour chronologically — nothing complicated. But the different variations of my symbols on the legend indicate anecdotal details that describe these moments: Why was I checking the time? What was I doing? Was I bored, hungry or late? Did I check it on purpose, or just casually glance at the clock while occupied in another activity? Cumulatively, this gave Posavec an idea of my daily life through the excuse of my data collection — something that’s not possible if meaning isn’t included in the tracking.

As the weeks moved on, we shared everything about ourselves through our data: our envies, the sounds of our surroundings, our private moments and our eating habits.

We truly became friends through this manual transmission. And in fact, removing technology from the equation triggered us to find different ways to look at data — as excuses to reveal something about ourselves, expanding beyond any singular log, adding depth and personality to quantitative bits of information.

In a time when self-tracking apps are proliferating, and when the amount of personal data we collect about ourselves is increasing all the time, we should actively add personal and contextual meaning to our tracking. We shouldn’t expect an app to tell us something about ourselves without any active effort on our part; we have to actively engage in making sense of our own data in order to interpret those numbers according to our personal story, behaviors and routine.

While not everyone can do a project as hyper-personal as this one, data visualization designers can make their interpretations more personal by spending time with any type of data. This is the only way we can unlock its profound nature and shed light on its real meaning.

Making Chatbots Talk — Writing Conversational UI Scripts Step by Step

As a content writer, working in UX design agency, I’ve learned to accept the fact that visuals usually have much bigger impact than the text. From my perspective, this is a bit frustrating. So when my team was faced with the task of designing a website chatbot, I was really excited: finally the time has come for writing to take over!

In this article, I want to focus only on writing the script, describing the whole process step by step. The complete case study of designing the chatbot was written by Leszek Zawadzki.

First Things First

As the chatbot was to be represented by our client’s brand hero — Cody, the script had to match his friendly and playful personality. The first ideas came to my head as soon as I’ve heard about the project: I immediately started creating the first conversation scenarios in my mind. But, soon I realized the bots and user exchanges are all quite meaningless. Yes, small talks are good for starters, but the script has to fulfil some goals. Determining what these are and figuring out the ways to fulfil them should, then, be the first thing to do.

Step 1: Setting the Goals

The main aims of our client — a web development company — was using conversational UI website to present their skills and services as well as increase brand awareness. Focused on these two, my team created a list of end goals to which the conversation was supposed to lead:

• the user visits company blog
• the user shares feedback about the company blog
• the user leaves his/her email
• the user leaves information about his/her occupation
• the user visits services page
• the user visits about us page
• the user visits main company page or one of the landing pages
• the user contacts the company
• the user shares the chatbot website
• the user bookmarks the chatbot website

With the end goals determined, we knew exactly where should the conversation with the bot lead to.

Step 2: User Research

Since end goals are well… at the end, we knew it’s crucial to write the script in such a way that the user feels engaged enough throughout the whole conversation to reach that final point. Unfortunately, it’s rather difficult to entertain someone you know nothing about and it’s even harder when your conversation is taken out of context. In everyday life, you always have some basic idea about your interlocutor (even if it’s just your first impression based on their appearance) and your meeting usually has some, more or less obvious, reason.

We wanted to achieve a similar conversation background, at least to the extent it’s possible in the chatbot script. It didn’t seem possible without some kind of user research. I started with entry points, writing down all the possible contexts the user might enter the conversation: Medium article, Facebook post, Twitter ad and so on. Then, I created a basic profile of each type of user, including their profession, interests, lifestyle, and the reasons why they might decide to chat with a bot.

In the end, the different types of users were organized into two main groups: 1) potential clients of the company 2) people interested in the chatbot per se.

Step 3: Initial Transcript Form

Now I was ready to write the script. Or at least, I thought I was. I took A4 pad (don’t think I’m crazy, I just like the old-school methods) and got down to work. 5 minutes later I already knew I had one more thing to figure out: “How the hell am I going to write this down?” Each response the user can choose from means starting another conversation, so should I write them all separately, cross-reference, do a tree diagram? I decided the last option would be the best and I think it was. I had to rush, though, to the nearest stationery store to buy large bristol board, since it turned out my tree had been sprouting branches like crazy.

Overall, when the script was finished, I was pleased with the form I had chosen. On a tree diagram the conversations were clearly separated and at the same time visible all together. What’s more, using arrows when the different parts of talk meagered helped to save time on rewriting the same part a couple of times.

Step 4: The Script

Finally, after a few hours of work, I reached the phase I initially thought will be the first and also the last one — writing. In fact writing per se took less time than the ideation process that accompanied it. Before I composed any part of the conversation, I had to take into account a lot of different things.

Open-ended vs. Closed-ended questions
We wanted the conversation to feel as natural as possible, so initially, I planned to include quite a few open-ended questions. This would definitely be beneficial from the point of view of users who would have freedom to speak (or rather write) what they like. However, since our bot wasn’t supposed to be based on AI, it would be extremely difficult to create relevant responses. No matter how hard you try, you won’t be able to predict what the user might say and any time you fail to provide a relevant answer the talk becomes nonsense or at least awkward. Also, in the case of open-ended questions, we would run the risk of the conversation drifting away from the end goals.

We wanted to avoid that, even at the cost of limiting the interlocutor freedom, so in the end I decided to keep only two open-ended questions to which the bot’s answer can stay the same, no matter what the user writes.

1) Question about the user name to which Cody would always* answer “Nice to meet you” 
2) Question about the user profession which, apart from 3 pre-defined options to choose from, would feature a text input (these would help to filter the users from client and non-client group). Here whatever* the user says, Cody can express interests and pass to another topic.

*That’s what I thought until I realized, I should also take into account…

Random and irrelevant answers
Yeah, even if you ask a simple question, like “What’s your name”, you have to be prepared for the possibility that someone won’t give the most expected answer. Some people will for sure try to challenge the bot by typing swear words or simply gkbbsdfjsdtvbndxus. Of course, you may just ignore that and let your bot politely say “Hi!” to Supercalifragilisticexpialidocious or fuckerfuck, but I decided to solve this problem by preparing a special answer for such circumstances.

Leszek says more about dealing with irrelevant answers in his article.

Context
In real life, the circumstances of the talk are always meaningful and shape the conversation in some way. It may seem that in the case of chat with a bot, the context will always be the same — the user enters the site and that’s it. But the source he/she enters from, time and frequency matter and it would be a pity to ignore them.

The first thing I wanted to do then, was to take advantage of cookies to determine if a given user is talking to Cody for the first time. If it’s a re-visit, instead of asking the user for his/her name again (which would be quite strange if Cody was a real person), I decided to refer to the previous meeting.

Another way to give conversation some context is by using referral URL analysis to determine the source the user enters from. No matter if it’s an ad, social media or blog post, referring to it can be a good starting point for the conversation, which will feel much more personalized for the user. The same goes for the device the visitor browses the site from.

In Cody’s case, mobile or desktop context had a big influence on the script. Unfortunately, I realized that at the point it was almost finished. I included in the script a fragment where Cody was showing the keyboard shortcut for “add to bookmarks”, encuranging the user to press Cmd/Ctrl + D. Probably because I liked that part so much, I somehow didn’t realize it won’t make much sense on mobile and later was forced to add an alternative version for that part, which with an almost finished script wasn’t an easy task. 
 
Fulfilling Goals
As we already had the user groups determined, all I needed to do is to create a path that would lead them to the end goals. First, I linked different user groups to the goals that should be the most beneficial to achieve by them from the company point of view.

1) Potential clients were to be directed to one of the company pages and encouraged to contact or leave their email. 
2) Those interested in the bot per se were to visit the company blog and share feedback on it.

Additionally, sharing the chatbot website and bookmarking it applied to both groups.

I decided it will make sense to create two separate scripts and link them only at the beginning and end of the conversation that I wanted to be similar in both cases.
 
The script for clients seemed to be more complicated. The most important goal here was to direct the user to the appropriate company page or promotional landing page. To do that, I had to collect some basic information about the visitor. The initial research I made helped a lot here. Knowing that most of the potential clients would be designers, developers or business owners, choosing one of these options when Cody asks them about their job, determined the next steps. In the case of first two clients, these were limited to providing the right page or contact person, but in the business owner case, the next filtering was necessary.

Having the more difficult part of the conversation done, the part for non-clients went pretty fast with Cody speaking mainly about his story and origin. A pleasant chit-chat, you usually exchange with a new person, was subtly filled with utterances focused on increasing brand awareness.
 
Loops
To avoid creating hundreds of separate conversations and risking some important information are missing in one of them, I decided to depend on what I called loops: one conversation was split in two or three, proceeded for some time and then a couple of different talk branches met in the same place. That way, we were sure things that really matter from the point of view of project goals will be featured in each chat scenario.

There was only one problem with that, once or twice it turned out the user was asked the same question for the second time. Spotting that at the point where I already had half of the script was a huge frustration. I had two options: rewrite a big portion of the script, this time making sure none of the loops lead to repetition, or… find another solution. I instantly decided on the latter, but it took me some time to come up with a remedy.

In the end, it turned out to be very simple. If people can forget and ask about the same thing a couple of time, what’s wrong with Cody doing the same?

Step 5: Development Instructions

Ok, the script is ready and checked a few times for potential holes or mistakes. All that needs to be done is hand it to developers in some digestible form — we couldn’t give them bristol tree diagram with my terrible handwriting and force them to decipher and type it all by themselves. Our script needed to be developer-friendly.

First idea was to use some kind of software like Xmind of Freemind that would enable me to reconstruct the tree form, but when I looked at two bristols that covered half of the wall, I decided it wouldn’t be the best solution. Then I thought about cross-references, however, I was worried it might be too many of them which would make the script very complicated to read. I started with writing down all conversations separately, then.

After 3 hours of writing, copying and pasting, I had almost a hundred conversations and, though I’m not the best at maths, I estimated we’ll finish with 480 different versions, if I continue this way. It didn’t make sense so after discussing the script form with my them, we’ve ended with writing it down in the cross-reference form.

The whole conversation was divided into unique parts (any fragment that repeated at some point, appeared only once) — each named and accompanied with a number and a letter that referenced to one another. The developers were provided with the key to read the script.

Key

/ diffrent responses that:

- change the conversation if the sign (1) or (1A) appears

- not change the conversation if no sign appears

| different user responses followed by relevant bot responses, without changing the course of conversation

[1A] parts of conversation

(1A) cross-reference to another part of conversation

12 pages instead of 86 I already had (remember I’ve done less than a quarter of it before I gave up) was an achievement. And though it took us a moment to explain the script and the key to developers, in the end they knew exactly how to approach it. Our job was done.

Conclusions

Writing doesn’t usually seem like much of a challenge. Good coffee, text editor, a bit of inspiration and voilà. Not this time… Creating conversational UI script is a challenge, especially when you do it for the first time. That project taught my team a lot and next time we’re faced with preparing chatbot script, we’ll already have a set of guidance:

• start with determining the main objectives of the script — end goals the users should be lead to
• do research to get at least the basic idea of who the chatbots visitors will be
• prepare the script outline first, deciding on the type of questions to use and a basic path leading users to the goals
• think over the context of the conversation (device used, entry points, reasons to enter the site) and accommodate the script to it
• try to predict less expected situations such as revisits or irrelevant answers
• decide on the form of the transcript, before writing
• think of the structure of the conversation — should it consist of separate chats or should they be connected at some point
• talk to developers and decide in which form should the script be digitalized

And last but not least: think twice before rushing into doing something.