The Life of a Button

Hello everyone, I'm Julian, later we'll be joined by Hugo who designs sounds across our products. Before we begin I wanted to explain a little bit about why we're going to be talking about a button for a while here.

I design and prototype user interfaces for future hardware. Because of the nature of my work I can't always use standard UIKit. I have built and rebuilt a lot of basic user interface elements like scrolling, zooming, paging, and of course buttons and I've learned a lot about the details involved in designing and building these controls.

So I'm here to share a little bit about what I've learned with you. I want to show you how something so simple, a button, has a lot of consideration and complexity behind it. And I hope that through looking at this button you can learn a few things.

I want you to use standard controls more thoughtfully.

To consider when to build your own custom controls. And when you do build custom controls I want you to consider your interactions all the way through.

So let's get started.

Hugo and I are expanding our artisanal toast app empire.

We are building a new simpler app that is connected to a toaster. If you imagine for a moment you're getting ready in the morning, you want to make sure you have breakfast ready by the time you're heading out the door. All you have to do is launch our app, press a button and expect a fresh piece of toast waiting for you in your kitchen. Now this works with our connected toaster. Our connected toaster goes through a few different states, it's ready and waiting for a new piece of toast, it's making toast, and finally the toast is done, the important part. But the way that our connected toaster ends up transitioning between these states is people using our app. When they use our app they can request a piece of toast to start the toaster going.

When the toast is done they will of course eat it. Maybe for some reason they'd want to cancel it, I'm not really sure about this one. And of course we want to make sure our toaster is always ready to serve. I'm not going to disclose exactly how this works but trust me it does and it's great. We also have big plans for the future, we could have AR toast, queues of toast, multiple toasters per household, and eventually we'll connect this back up to our toast social network.

My point is there's a lot going on in here and for today's session we're going to dive deep into the details of a single screen, in fact a single button on a single screen of our app. If we get to the details of our most important interaction right the rest will flow from it.

So if we look at our system again I think the most important interaction here is actually when we request toast. Obviously, all the rest of this has to work, but requesting toast is the first impression and if people aren't able to start the toaster the rest of it doesn't really matter.

So to do this today we're going to start by talking a little bit about what a button is, then I'm going to share with you a way of thinking about interactive controls. And finally, Hugo will join us at add some sound to our Button.

So what is a button anyway? The buttons that we are talking about today or onscreen user interface controls.

Buttons are indirect controllers of action.

What I mean by this is when you tap a button the action happens somewhere else. This is as opposed to a direct interaction where here I'm grabbing the lever and controlling the lever directly.

Direct interactions can reference the real-world experience and feel more fun. But the real power of indirect interactions like buttons is that they can be clearer and more powerful because of their separation.

The interesting thing here being that even the physical buttons that these onscreen buttons are imitating are indirect.

Even though the action, the result is happening somewhere else the button controls that action. And just like the action a result can be designed a button can be designed, we can consider both of these things separately and connected.

To do this today we're going to be relying heavily on a single lens of design feedback.

Feedback is how you let people know what your app is doing.

I'm sure a lot of you have thought of a variety of different ways that you can provide feedback within your apps and are already doing so. But I think there are two major categories of feedback.

The first is that you can tell people, you can literally put text on screen explaining what's going on or design icons that explain things.

The second is that you can show people, you can allow people to experience the results of their action more like the real world through visual, audio or even haptic change over time.

Now we're going to apply feedback to three phases of an interaction, not just its completion. We can think of these phases in terms of a physical button.

Before I have pressed the button it's just hanging out there. During my interaction with that button it's being pressed in. And finally after I've pressed