Prototyping for a tiny screen

Just about everyone I know got an animated emoji from me the first day I got my Apple Watch. I was smitten.

As a designer, I felt inspired, too. I’d never designed for tiny screens before, and the thought of creating something in a space that has such a unique set of constraints and strengths appealed to me.

So for a side project, I decided to design an Apple Watch app. As a jumping-off point for my design, I looked to the mobile app I use to monitor my electricity use and pay my monthly utility bill—it seemed like some of its features would work well on a Watch.

Comparing monthly usage, adding payments, and other tasks that are more easily displayed on a phone or a tablet would present interesting challenges on a Watch. Here’s a closer look at my first attempt at prototyping for a tiny screen.

Tackling a tiny beast

If you’ve ever had to design an app for iOS and Android, you’ve noticed that it’s important to take their familiar constructs into account: tabs on top for Android and on the bottom for iOS, for example. That’s how users expect to experience them.

You can’t recreate a mobile app for Apple Watch. A Watch app should be an extension of a mobile app—a tiny-screened friend that helps enhance the experience with the phone. Just like iOS and Android, Apple Watch has its own sort of visual language and ways that a user is intended to experience it.

I wanted to be true to the Apple Watch experience, so I thoroughly read through Apple’s design docs. I wanted to know what sort of navigation constructs and controls were unique to Apple Watch, and all the technical insights that I’d need to be aware of.

In my digging, I discovered that Apple has specific navigation and layout patterns designed for the Watch platform. The patterns have been designed with a lot of thought given to the scenarios in which they’ll be used.

A quick breakdown:

• Glances: browsable collections of timely and contextually relevant moments from the user’s favorite apps
• Short looks: notifications that appear briefly, giving the user just enough time to see what the notification is about and which app sent it
• Long looks: provide more detail about an incoming notification. The long look appears when the user’s wrist remains raised or when the user taps the short look.
• Page-based navigation versus hierarchical navigation: page-based nav is based on swiping horizontally through pages. It has the familiar horizontal series of dots that you see at the bottom of home screen on an iPhone. Hierarchical navigation is a drill-down way of accessing information. Tapping on a menu item takes you to the next screen.

There’s a lot of nuance in these constructs: glances, short looks, long looks, hierarchical navigation versus swipe navigation. Just like mobile, there are instances where each is appropriate, and if you use them in the proper context they’re intuitive for the user.

While figuring out how to navigate wearables, my advice to you is this: don’t reinvent the wheel. The types of navigation and data displays were designed for particular scenarios. Figure out how they can handle information that you want to get to the user, rather than trying to design these patterns from scratch.

Research

Once I had the basic understanding of how Apple Watch presents information, I started experimenting with how data would be visualized in the scenarios. For example, what sorts of information goes into a glace versus what info goes in a notice?

I added tons of Watch apps so I could play around with them and see how others had solved translating features from a mobile app to the new format of the Watch. It gave me clues about the designers’ thought process. What parts did they keep? What did they throw away? How did they show me on my wearable? Did they make good choices?

The first swing

At first I thought I wanted to do hierarchical navigation, as it was the way that the mobile app was laid out. While it made for a complete app, I realized that it wasn’t working exactly the way that I’d wanted. It lacked life and delight. It felt text-heavy as opposed to being able to quickly present information.

I realized I should embrace the “Apple Watchness” of Apple Watch: great data visualization without much text.

I showed the initial take to the design team, knowing there were changes needed. I got a lot great feedback: “Doesn’t look much like a Watch app. Why not try out the data-driven design examples?”

They were right. So I started over.

Sometimes you just need to gut the room and start over

I’d gotten lost in a 1:1 mapping of features from app to Watch, and I hadn’t followed my own process. Usually a project starts with a list of features or business requirements, and from them I’d generate flows and wireframes, and then finally move on to comps and prototyping.

In my first shot, I didn’t establish a baseline MVP (the minimum viable product needed to make an app functional and useful). I just wanted to kick the tires and see what happened. And what happened was unfocused and lackluster.

I would never have approached client work like that, so this time around I took a step back and planned out an MVP. I collaborated with developers to outline a realistic MVP set of features to design around. Then I took that list, grabbed my notebook, and got to work.

A word about sketching: I can’t recommend it enough as an initial problem-solving method. And I’m not talking about those perfect, gorgeous sketches in leatherbound Moleskines you see so often in designers’ blog posts. I’m talking about ugly, fast, disposable sketches. The ones that you’re afraid to show because people might say, “I thought you said you went to art school?”

Working quickly on a whiteboard wall or in your notebook, make a list of features. Group like data and actions together. Draw out fast, crude wireframes and flows. Don’t fall in love.

As soon as you’ve invested any effort into making them perfect, you’re less likely to be mentally willing to look for alternatives or throw them away and start over when you find a problem or need to make a change. I wind up producing beautiful versions later for presentation to the client, usually digitally.

Walking through every little detail helps me see different ways to group features together for a page-based (versus hierarchical) app. I broke features down into granular tasks and then started to combine them into screens (see the notes like “A1, A2, B1” next to my sketches). I worked loose and fast because at its core, this was just a grocery list—a tool to help me organize and account for the features.

Inspiration

I was intrigued by the way the Weather app for Apple Watch evokes a watch face by presenting weather data in a circular manner. I attempted to express some of the user stories together in a circular layout, like days remaining until your bill is overdue. It’s an interesting challenge to take a calendar and present it in a circular way or translate a comparison bar graph into a circular piece of data visualization.

Lather, rinse, repeat

Rethinking the app as page-based allowed me to combine a lot of different pieces of data and potential jumping-off points onto one screen. It allowed me to make it concise and heavily visual. Paging through a Watch app made using the app much faster, more fun to use, and even more fun to design.

Lessons learned

One of the most important lessons I learned: just dive in and do it. Build your design from user stories. Flow, wireframe, prototype. That’s how you learn.

If you can get feedback from other creatives and iOS developers, ask for it. They’ll help you spot things that you may have overlooked, and you’ll build a better prototype.

Along with that, having realistic MVP features helped me better identify what I needed to spend time on and what needed the most focus.

Try things, re-evaluate your work, and don’t be afraid to abandon a course when you see a flaw. Keeping a copy of older screens can be handy when presenting work to clients, or even to your team.

Even if you don’t have a client paying you to design a Watch app, completing a design like this as an exercise pays off. It can be a blog post on a new and interesting topic that shows prospective clients that you’re up on all the latest happenings. It can be a great addition to a portfolio that shows how you approach a project.

Plus, it’s an opportunity to communicate your critical thinking skills, something I unfortunately rarely see when I’m reviewing job applications.

Although this project wasn’t client work, I’ve used this design to show a prospective client how I approached UX, designed with platform and user in mind, and thought about how a Watch app can integrate with an existing mobile app.

In case you’re wondering: I got the gig.