Abi Jones: All right, yes, I have slides. That doesn't move, that's really heavy. Okay, so, oh yes, all right, sound too.
Hey, I'm Abi Jones. Before I start talking, I want to ask if any of you have ever used the reason of consistency to explain why a certain interface should be implemented?
So have you ever been like, oh yeah, we should do this to be consistent with other things? Okay. All right, you're all horrible people.
Okay, thanks. I've been told the spotlight is over here, but it's nice here 'cause I can actually see all of you.
So I'm up here today to talk about reasons why consistency's helpful, but also when not to be consistent with your own interface, other interfaces, or the real-world. And before I do that, I have to give you a disclaimer, because I work at Google. And so, you should know that these are my own opinions, they are not Google's opinions. I'm not, Google is not paying me to be up here to say these things.
Today, I'm going to give you examples about brains, experimental aircraft, Google Docs, emoji, Microsoft Word, Pokemon, design software, virtual reality, coffee and games. And I'm gonna skip the Q&A afterwards so you can get to lunch.
So first of all, put your hands up in the air. Wiggle your fingers around. Like real, come on, I see people just standing there. Really wiggle 'em. Okay. Now put your hands on your lap, like this. You can close your eyes if you want. Imagine a keyboard. So if you're using a browser, can you open a new tab with your laptop? What about making a rectangle? What if you don't want a rectangle? Undo the rectangle.
Were you able to accomplish those things?
You can nod now, you can look at me, it's okay.
You've probably developed pretty good procedural memory in using a keyboard. So what is procedural memory? Well, it's what we think of as muscle memory. It's really that you've practiced something so much that you don't even have to think about it anymore, and actually thinking about makes it hard to do that thing. So it's not in your muscles, it's actually in your brain. Procedural memory is partially stored in your cerebellum, that's the part of your brain that's back here. But it doesn't just take place in one area of your brain. We use procedural memory when we ride a bike, tie our shoes, type on a keyboard, or when we fly an airplane.
And so we think about somebody like a test pilot, this is Milton Thompson. This is him in 1966 flying some test flights at Edwards Air Force Base. And when he was going to fly test flights, the U.S. space program was using these types of pods to land people from space. If you can't see it, here's the outline.
There are a lot of problems with using a command module as a spacecraft returning to earth. For one, you're just literally falling through the atmosphere without any control, which is a problem, and you land using a parachute. And so, sometimes the landings be pretty on target, but other times astronauts would be hundreds of miles off course. And that was an issue. And so, NASA in association with Lockheed Martin was working on some test aircraft.
The other issue with landing with these kind of pod things is that g-forces are hitting you in the wrong direction. So when astronauts are in those pods, they'd be laying backwards and g-forces are coming from behind their head. You can actually withstand higher g-force if it's eyeballs in versus eyeballs out. I never really thought about the phrase eyeballs out until I was reading about experimental aircraft, but just so you know, it's the same kind of force you feel if you go on a rollercoaster and it feels like your stomach is in your throat. That is your stomach literally trying to go into your throat. So just so you know what's happening. So eyeballs in, easier to withstand g-forces coming at the front of you, versus behind.
So why not make a new aircraft? This is the M2-F2, and it's what they referred to as a heavy lifting body. It's not a sunlight weight glider, it's made of a steel core and aluminum. And it's pilotable, which means it can be landed, which means that somebody is coming in and experiencing g-force from the front and they're going to be able to land in the right place. And it's the predecessor to something like the Space Shuttle.
So the examples I am showing you today are from 1966. The Space Shuttle went into, program went into effect in the early 80s.
There's a problem though. These things don't have wings on the side so they're really unstable. They experience what's called lateral oscillation, so the back and forth, side to side movement. And even before they built the aircraft, the engineers and designers on the aircraft knew that it would have this problem.
So they put a special wheel in the aircraft so the pilot could control the rudders and the flaps. So the rudders are what's on the back of the plane that might move back and forth like this. The flaps are on the side and they move up and down. That's how you steer a plane and how you stability.
So they put in one of these wheels, and on the morning of July 12th, 1966, Milton Thompson got in the M2-F2, which is attached to the bottom of the wing of a B-52 airplane. Gives you an idea of how small it is. It's only 10 and a half, 11 feet wide. It's a really small aircraft.
So that morning, they're at Edwards Air Force Base, they're going to have him land in a dry lake bed because that seems safer than landing on a runway. And so, what Milton went through is he, as a pilot, when he took off, did his checklist, made sure all of his instruments were in the right place, and then counted down only from five when he wanted to be dropped from this B-52. And we actually have video of this event.
So not much better than the other kind of spacecraft at this point, just being dropped through the air.
But the nice thing about it is it has a jet engine in the back of it where you can actually steer it. The bad thing about it was that as Milton was completing a series of maneuvers, which were mostly turns, and he was lining up for his last turn, he felt like there would be a controllability problem with the aircraft.
So he moved that wheel to the side to point for to try to reduce the oscillations that were happening. And instead of getting a reduction in oscillation, it got worse. And where he was expecting slight lateral oscillation, his aircraft started bucking back and forth. This wouldn't have been that big of a deal, except that he was at 8,000 feet altitude and he was descending at 18,000 feet minute.
So with less than 30 seconds to go, what Milton Thompson had to do was ignore all of his procedural memory that he built up training for this mission and instead, he reset everything in the cockpit to zero and stopped messing with it.
Because if you have PIO, or pilot induced oscillation in an aircraft, the best thing to do is stop giving the aircraft inputs and instead, let it damp out the oscillations on its own. And so, with less than 30 seconds to land, he let go.
He ended up flying a half dozen test flights of this specific aircraft. The final test flight of this aircraft ended with a spectacular crash from another pilot who was pulled from it alive.
But what happened?
Why did the aircraft end up having longitudinal oscillation when just lateral oscillation was expected? Why didn't the interconnect wheel work to control the amount of oscillation that was happening during the flight?
Well, here is the wheel, and here is the simulator.
So this is the aircraft that Milton Thompson trained on. And what I really like about this is that you can see the plywood on each side. It's built out of some old jets.
And the problem is that when they built this simulator, they hadn't designed the wheel yet. And so, the engineering team used an old brake handle from another aircraft and stuck the brake handle in the same spot, but when you push the brake handle forward it increased the interconnect ratio, whereas when you pushed the wheel forward it decreased the interconnect ratio.
It's kind of like natural scrolling.
Complete unexpected interaction there through something that's mediated through another interface.
And so I have a feeling that very few of you are aircraft designers, but the reason you should care about this is that we design a lot of interfaces that have significant impact on people's lives. Either because those people are making decisions about the health, the safety, or well-being of other people, or because they're designing software and tools that help people connect with their loved ones, make financial decisions, or keep up with their own health.
We hear a lot about making interfaces consistent so they can be intuitive. But really, intuition just means that something has become part of your procedural memory and you can do it without thinking. So try not to ever use the term intuitive. I think it's something that doesn't really exist. Everything that we do is learned or a response to some sort of stimulation.
Instead, I like to think about making software that's predictable, especially if it's software where somebody's trying to do a job.
So today, let's look at a few different types of consistency and think about how predictability can help people.
Three ways of dividing things into consistency types, or thinking about internal, external, and real-world consistency. And in both internal, external consistency we can look at interface consistency in the context of color, typography, language, visual elements, layout and location, and interactions.
And so, layout and location, interactions were the primary problems that Milton Thompson had in switching from the brake handle for the interconnect to going to a wheel for the interconnect.
There are benefits to having internal consistency in an interface.
So it helps users bootstrap their internal learning, it can improve ease of use, and you end up with higher perceived quality in an interface that's consistent.
So let's look at a couple other examples of internal consistency.
Here, we have sharing in Google Docs. And so, you can see that on the top if I wanna share this set of emoji, I can just hit that share item in the menu. When the modal for that pops up, it uses the same language, which is about sharing. But if I wanna use the mobile app, it doesn't share say, it says add people.
And this is something really confusing, right?
It suddenly makes you say, oh, wait a minute, what, is there a difference? Like what happens when I add people versus when I share something with other people?
And so, that's one of the early things in consistency to do is it's not just about naming things, but it's about using the same language each time when somebody's going to perform a similar action.
In the same menu on a desktop for Google Docs, I can rename a document or I can share it, and you can see from these two modals which are launched from the same menu, one is Material Design and one is Kennedy Design. But you never see 'em at the same time and they're similar enough to each other, they use the same terminology, they use the same interactions, and they use the same colors that it's easy to get away with being inconsistent here.
And the reason it's important to start thinking more about consistency is that cognitive control is a depletable resource.
So think about how hungry you are right now and the hungrier you get the worse you will be at processing what happens in a talk or any other information you hear. And it goes the same with consistency. Dealing with an inconsistent interface is mentally taxing. And so, having one that is consistent can help reduce the cognitive load on your users and in turn, help them make better decisions.
So let's take a look at versions of external consistency.
All right, who here uses an iPhone? Raise your hand. All right, and an Android device, Android phone of any variety. All right. And any other kinds of phones? When I worked at MySpace, I used a BlackBerry. So it's okay if you use some other kind of phone. Okay.
So if you used a Android device in 2016, you would see this emoji. I am not a really experienced emoji user, technically I'm a millennial, but I feel really nervous about using emoji. And maybe it's because I feel nervous about using emoji that when I see this one, I think of it as nervous sweating.
And so, at work, at work, it's tiny too, it's not 10 feet tall like it is here where it's obviously not sweating. But to me, the version that's just 24 pixels tall, it looked like sweating. And so, in group chats at work, I was confused about why my colleagues were always using nervous sweating. And I was like, maybe it's just me interpreting it that way because I sweat a lot. And it turned out that was the case. Because on a iPhone, it looked more like this, and it's obviously crying while you're laughing. Not sweating. Or it is sweating and you're sweating out of your eyes, which would be really painful.
So I have my own problems with emoji. It turns out I am not alone in this. So if we look at 1F601, which is the grinning face, there's some research out there that shows that there's a high variance in how people interpret this grinning face across different platforms. So you can see the Apple one has a negative aspect to it, whereas the Google one is super positive. That means that people who have iPhones and Android devices that are trying to communicate with each other, they're sending completely different messages to each other, which is horrifying.
And even within just the iPhone version of it, there's really wide degree of variance. Like some people would think, oh, it's super positive. Then a serious number of people were like, this is a very negative emoji. It's called grin, and yet, it's problematic.
And so, what might happen is you could send your friend a message like, I just went on a date! Ugh! But if your friend, who's probably not at this conference 'cause everyone has an iPhone, if your friend is on an Android device, they see this. That's not okay.
So external consistency is, especially in systems that communicate with each other, is really important.
Consistent UIs also help bridge a knowledge gap. You can think of a knowledge gap as where you are right now, so your current knowledge point, and then where you want to be in the future. Here is the knowledge gap.
So think about something like Microsoft Word. And you can see at the very top of it, got some buttons, a dropdown menu for text, a dropdown menu to choose text size, which is similar to this other interface.
So if you're thinking about when to be externally consistent, one way that's helpful to think about it is do I want to bootstrap learning from another interface and make it possible for all of those users to also use my new thing?
So if we think about the elements of UI consistency, aside from typography, they're all pretty much there between these two UIs.
If Google Docs had used neon colors instead of white and gray, if it had used different language for the top menu items, like file, menu, view, insert, which are, I have to say, the first five menu items on both of these UIs are exactly the same. So our language is the same, the visual elements are the same, drop down menus for choosing text, a button to print something, ways to align text. And they are laid out and located in the same place. And aside from the real difference in Google Docs, which is the ability to edit a document at the same time and collaborate with other people, the interactions on these two interfaces are the same.
So the reason we wanna have consistent interfaces is that we don't wanna underestimate the proficiency or efficiency of our users.
Because the people who use our products, unless you're Cameron, spend most of their time in other people's apps.
Or unless you owned Pokemon at the time of the Pokemon Go craze. So at the moment Pokemon Go launched, people kept using Facebook, YouTube, and Snapchat, but you can see this massive uptick where people who used Pokemon Go were using it a much higher rate than they were any of those other applications, which would've been a prime time for any of those applications to steal UI elements or interactions from Pokemon Go.
And I'm a big fan of using the same interactions across different interfaces, in part because I rely on my procedural memory a lot as a designer. In some ways, it's important to be able to mindlessly build a new, build a new grid or design a new interface.
Does anyone here use Photoshop? That's like the lowest raised hands I've ever seen in my life. It's okay. What about Sketch? All right, Framer. People, all right.
So I switched about five or six years ago from Photoshop to Sketch, and it was really difficult. In part, because the letter R, for example, has vastly different meanings between Photoshop and Sketch.
And so then, when I started trying new design software, like Principle, there's always this moment where you, first of all, never read the instructions for anything, and second, you open up a new piece of software and you try using all the new keyboard shortcuts you already know, and you have this feeling where you're holding your breath, like please let it work, please let it work, please let it work. And R makes a rectangle in Principle. And my reaction was like this. I was like, it's a rectangle! Which shows you how exciting my life is.
But things like that are really important when you make, you can make 100 rectangles in a day and you think about if you don't have to think about how to make a rectangle every time, that's really nice.
So if you're thinking about making some design software or you're making improvements to design software, make sure you already understand what your users are doing and what they're using, and then try to take the shortcuts and the mental model they already have and use it in your own software.
So if you wanna attract existing users of someone else's products to your product, you should try to interpret user's commands in the same way.
I feel good about putting Bruce Tognazzini up there rather than saying this myself, because it sounds like I'm advocating, just straight up stealing people's UI ideas, but it wasn't, it's not me, it's Bruce.
So these conceptually consistent interfaces are faster, they're more dependable, and they're friendlier to people. And you have a good feeling, if you're a Sketch user and you start using Principle, you're gonna have a relatively good feeling about it because it uses the same metaphors and the same shortcuts that you're already used to.
And so you can see across interfaces like Photoshop, Sketch, and Principle that the metaphors translate from one to the next.
Lastly, I wanna go into real-world consistency before I tell you all the reasons to not be consistent. One of my favorite VR applications is just a test app and it's where you are at an office and you get to try out new VR interactions by doing the things people do in offices. Like drinking coffee.
[Computer Announcer]: Awesome work.
Abi Jones: And the first time I used virtual reality, I have to say, I've never used virtual reality at home for fun, I've just done it at work, which probably makes my use of it really weird. But the first time I used it, I played this test game which teaches you a lot of VR skills.
[Computer Announcer]: Awesome work.
Abi Jones: Oh, sorry. I don't want you listening to this. Turn off the sound from my computer. Thanks.
So I went to, I'm wearing this crazy headset, and it's attached via a cord from the back of my head...
[Computer Announcer]: Awesome work.
Abi Jones: To this mega computer at Google. And I'm in a virtual reality room with 10 of my peers, which is the least comfortable way to ever do something in virtual reality, where everyone else is not wearing a headset and you are. It's a very vulnerable feeling. And I played this and I put...
[Computer Announcer]: Awesome work.
Abi Jones: I had my headset on, I was like, okay, I had my two joystick controllers, and I poured myself a cup of coffee, and then I was paying attention to something else and I bobbled my cup of coffee and the coffee, in virtual reality...
[Computer Announcer]: Awesome work.
Abi Jones: I jostled it in the cup. And I realized, oh no, I need to hold this cup straight so I don't spill this coffee, which is ridiculous, because it's in virtual reality, it doesn't matter if I spill the coffee, I could throw the coffee across the room. But because the physics...
[Computer Announcer]: Awesome work.
Abi Jones: Of the coffee were consistent with real-world physics, my reaction to it was as though it was in the real-world.
So consistency, it builds on prior knowledge, it maps to people's concept model of the world, and it can close the knowledge gap. And it's important to think about consistency and how to apply it because software is kind of magical. It's not mechanical. Software does not have to reveal the inner workings of a system to be able to provide an interface to people.
So there are some good reasons out there to be inconsistent in the interfaces that we create.
This ugh, okay. Kerning, man.
So the first reason to be inconsistent is that technology should make things easier than they are in the real-world. So if your interface makes something, is consistent but makes something harder to do, then you have not done a very good job. So you should be inconsistent when you have a better metaphor. When I talk about metaphors, I mean things like page swipe versus tap on a UI, or thinking about a desktop itself.
Every day, you choose to save or not save things to a folder called desktop, and yet, it is in no way a desktop.
So you can think about different metaphors like Tinder, for example, is that it's a different metaphor for thinking about judging somebody's looks. You wouldn't wanna apply this metaphor to adopting a baby or a foster kid, but for trying to figure out if you wanna have sex with somebody, it can be helpful.
So you should also be inconsistent when you want to stand out.
So if you think about something like coffee, you can have small, medium, large cups of coffee. But if you want people to think about your coffee in a really different way, you can call your cup sizes by different names. This only really works if you're planning on opening 10,000 stores around the world and dominating an industry, but it works.
You should also be inconsistent when you want to have fun. And not just when you want people to play games, but when you want to add a feeling of delight to an interface. I think this is especially important and difficult for crowded marketplaces like to do apps, where you need to have a bit of inconsistency because otherwise, why build your app at all? But a balance of consistency to make it possible to use it.
And you should be inconsistent to use the advantages of technology. And my favorite example of this is teleportation. So think about the pipes in Mario Brothers and how you can use a pipe to get from one place to the other. It's really important to think about what makes the technology you're using so special and what it does that's different from the real-world, and then start using that.
So with virtual reality, the most boring virtual reality in the world is any virtual reality that is consistent with real life. If virtual reality is completely consistent with real life, what is the point of putting on goggles? Like the beauty of virtual reality is that you can fly through the air, you can be teleported, you can instantly zoom around, you can blow things up that are usually small to enormous sizes, or maybe you can take things that are usually large and make them tiny. So if you are designing for virtual reality, I would say that consistency is more your enemy than your friend.
So types of consistency. Internal, external, real-world consistency.
With an interface consistency, we have six general areas that are important to us.
And you should be inconsistent when you have a better metaphor, when you want to stand out, when you want to have fun, or when you're creating magic.
And the way you can do that is by knowing your users and their tasks, and if you're not making the next version of Excel, then knowing their needs a little better than everyone else.
So thank you.