Viewing entries tagged
UX

We work for our apps. That's backwards.

We design apps wrong. They’re supposed to help us, right? Make our lives easier, complete tasks for us, simplify things. But that’s not quite how they operate. They require us — users — to help them — our apps — complete the tasks we ask them to do.

Morning ritual

Consider your morning commute. Do you drive? Walk? Bike? Whatever mode of transportation, the routine is likely fairly consistent. You leave your home at roughly the same time each morning. You follow the same path each morning. You arrive at work at pretty much the same time each morning.

My morning commute includes a walk through parts of Boston, ending up in Back Bay. And every morning, five days a week, I stop at Starbucks before getting to work. I stop at the same Starbucks, at roughly the same time, and order the same drink. On my walk I place a mobile order via the Starbucks app so my drink is waiting for me.

These are the steps I take to place my order:

  1. Open the Starbucks app.

  2. Press the floating action button.

  3. Press the “Order” button.

  4. Select my saved drink choice.

  5. Press the store selector.

  6. Choose a different saved Starbucks location.

  7. Press the “Review Order” button.

  8. Press the Continue button.

  9. Press the “Order” button.

I documented these steps and screens in a Medium Series here.

9 steps. I must complete 9 steps for the Starbucks app to order me the same drink I order every day, from the same store, at the same time. Seems like I’m doing a lot of work to help the app help me.

We work for our apps. That’s backwards. They should work for us.

A better experience

What should happen? A thoughtfully designed app, meant to truly help users, would recognize behaviors and adapt to support them. As I approach the Starbucks from which I order every morning, the app should prompt me. It should proactively ask me if I want to get my usual. Something like this:

“Ken, I noticed you are approaching your regular Starbucks. Should I place your drink order so it’s ready for you?”

Wouldn’t that be a way better experience? The app helping the user, automating repetitive behavior, instead of requiring the user to tell it what they want in exact detail as if you haven’t done so 1,000 times before.

starbucks-copy.png

Make it happen

So how do we make that real? I suspect the app would need to know 4 things. And once all criteria are met, the app could prompt you magically.

It would need to know:

Location. The app would need to know where you are so that it can identify when you’re close to a Starbucks. Luckily all smartphones come with GPS.

Drink order. The app allows users to identify a favorite drink. Even better, it keeps a record of every drink you’ve ordered. It can figure this out without even needing to be told.

Preferred Starbucks location. Like your drink order, the app allows you to select a favorite store for convenience. And again, the app already records the location of every order you place. It can already discern your behavior.

Time of day. If you regularly order a drink at a particular time, it needs to recognize that. And again, there’s a record of every order you’ve ever placed.

Hooray! What the app needs to know — it already knows!

This proactive approach can greatly simplify the ordering process. What takes 9 steps today can be reduced to just one:

  1. Would you like me to order your drink — Yes or No?

Much simpler.

Let’s all do better

I don’t mean to single out Starbucks. They make a pretty good app. Their mobile ordering feature saves me about 10 minutes on my commute, having the drink ready for me versus having to wait in line, pay, and then wait for my drink. As I’ve said, I use the app every day.

But we can do better in how we design apps. Let’s craft them in such a way that they truly support and aid the user, not be just merely dumb apps that need to be manipulated/managed by the user.

No UI is a good thing

Pocket Pond is an iPad and iPhone game that is exactly what it’s name implies: a pond — with fish and lily pads — that lives on your Apple device.

 
 

I came across this app recently while waiting for a doctor to insert an IV into my 22 month old daughter. Lucy is fine, a little scare and a long day, but ultimately all better. The nurses loaned us an iPad to entertain her and Pocket Pond was loaded on it.

The game involves users “touching” the water surface. It disturbs the fish and they scatter. There’s a pleasant sound of water splashing as users interact with the app. Lucy loved it. It occupied and entertained her while we waited hours.

It is a very simple game. But what I found interesting about it was the app had almost no UI. The entire screen was filled up by the pond and that’s what you interacted with.

I’m a UX designer. I’ve designed a number of apps, websites, large-screen displays. We are always focused on creating the UI. How do people interact with it, control it, understand what’s possible. To our detriment as designers, the UI is immediately what we focus on. Pocket Pond has none of that. It just is. It’s skeuomorphic design is exactly the point.

 
 

Wherever you touch the app, the water is appropriately disturbed. That is the interface. And it supports multi-touch so touching with just a finger produces a different result than touching with all five or your palm. It “feels” real.

Important to the experience is the sound. The sound is both what one would expect, and soothing. The sound helps create the immersive experience. Playing the game without sound provides a lesser, duller experience.

 

So what’s the point?

The game is certainly simple in what it wants of users (see the part where my young daughter was highly entertained). But that simplicity allows for something interesting to occur.

My daughter experienced real joy with the app, and unlike every other app on my phone, she could play it without unintentionally ending the experience or going down a path that locks out the game (e.g. opening a menu, selecting an alternative option screen, etc.).

And I actually found the game refreshing and oddly entertaining. Immersion can be a powerful experience. There is real opportunity in building apps in this way, or at least incorporating this experience into a larger platform.

I think three things overlap and work together to create this experience:

 

No UI

The lack of UI is a benefit. I don’t need to understand how to use the app because the experience as presented is it’s whole purpose. Just interact with it. You can’t create an error. How do you create an error with a pond?

And this leads to…

 

Immersive

Without the UI to get in the way, the user is that much closer to the “pond” experience. Sound, as noted above, is also extremely important. They work together to bring the user into that world. It is surprisingly powerful.

 

Fun for it’s own sake

The app has little to no purpose other than to replicate a pond. Users find joy in that (or don’t). There’s no effort to make the user do something, to progress by completing tasks.

 

Conclusion

There is a notion that mobile users are task-oriented. They want to open an app, complete a goal, and move on. At the same time all of us are spending increasingly more time on our phones. Might there be an opportunity to build more engaging apps that eschew UI and focus on immersion? Pocket Pond aspires to be little more than the simple game of splashing water and scattering fish. But this approach seems to be rich with experiences that could be more rewarding. And experience in and of itself is a worthwhile end goal.

I would certainly enjoy more apps like this.

How do we make decisions?

Over the weekend I saw this tweet from Andrew Wilkinson:

I love this idea. It connected to me in an unexpected way. I've been spending a lot of cycles thinking about decision-making. Over the past few years as a UX lead - first at Sapient and now at DraftKings - I've helped shape team structure and process. I'd grown into this responsibility as I progressed in my career. But no time was spent training me on how to build process. Sure, I have experiences - been in good situations where the team delivered exceptionally and bad situations where the projects was a shit-show from top to bottom - but that's not a study of process.

Also, to some extent I distrust experience as a way of making decisions. This is for two reasons. First, I haven't had all the experiences there are to have. In terms of experience I'm missing pieces. So how can I build a process based on only what I've seen? Second, I've seen others make bad design decisions based on their experiences. Choices I would not agree with based on my direct experiences. So if I see others making bad decisions and they don't know better, why would I think I'm not doing the same thing.

So I'm thinking about decision-making as a repeatable process where, if followed, I can be as sure as possible that I'm generally going about it the right way. Which is why Andrew's tweet struck me as interesting. Is there a way that decision-making can be defined clearly enough to ensure a good (or more likely good) outcome?

I think so. Though I don't know what that looks like at the moment. Responses to Andrew's tweet suggested several apps/sites out there that offer help, though I found the approaches they take lacking. In some form or another, they treated making a decision as a simple math equation. Input relevant facts, weight them, the app spits out an answer. That doesn't feel right. That doesn't feel like how decisions are made. They can't be reduced to simple either/or statements. I think evaluating and contemplation are necessary parts.

I'm going to think some more about this idea. I think it's interesting, and valuable. I need to work through what this service might look like.

UX portfolios suck

They are poor representations of what UX designers do

Atomic Design: fission or fusion?

A first-hand look at applying Atomic Design to a scrum project

I’m currently engaged in an app dev project where we’re using Scrum methodology to design and build. It’s going quite well. As we began the project, development brought up Atomic Design and wanted to add it to our process. I’ve read a lot of Brad Frost’s work on the subject and definitely see the wide ranging benefits of this approach. But from how I understood Atomic Design, it was a style-guide approach that’s employed once a style is defined to maintain consistency across digital platforms and screens.

Can Atomic Design be used as part of your design thinking from the start?

Credit: Brad Frost, Atomic Design

Credit: Brad Frost, Atomic Design

First, the good:

Atomic Design has kept the designers honest. As we’ve built out our components and styles, there’s been occasions where we’ve shifted a label for an input field from left-aligned to center aligned. The particular element was a bit different from other fields and it just felt “right.” But did it really have to be different? No, and we changed it back.

Because we are working in scrum, UX is rushing to stay ahead of dev as they think out the screens that are to come. They’re sketching furiously on whiteboards and then moving on to the next feature. As more of the Atomic Design style guide is fleshed out, our visual designer is able to translate a whiteboard sketch easily into fully designed comps (more on “comps below). There’s less cognitive load on the designer in terms of how to design the sketch. Tellingly, earlier in the project when less of the style guide was defined, the designer struggled a bit working from just a whiteboard sketch. More thought from his end and more detailed work from UX was needed. Now that our style guide is more complete, this extra effort is no longer needed.

Second, the hard:

There’s still some friction between the development side and the design side. We print out comps of the various pages and pin them to gator boards so we can review and react to them. Developers have occasionally remarked, “With Atomic Design we really should never be building out full page comps.” This misses the point.

The blunt fact is that the comps aren’t for developers. As designers, we’re thinking through the requirements and challenges and figuring out the best way to design a solution. This necessarily requires a holistic approach.
 
 We take the comps and and drop them into UXPin and build lightweight prototypes that are used to conduct iterative testing with users. This has greatly informed our designs, resulting in us simplifying, enhancing, and pivoting. This could not be done with small components alone.

We also encountered confusion between development and design about what was intended by the various atoms/molecules/organisms. Both sides are to blame here, and it came out — constructively — in a Sprint retrospective. The result was additional conversation to set expectations and tweak process. This has helped immensely.

 

 

Atomic Design is a great framework for development AND design in the building of software. But it does need to be flexible to allow creative exploration and to allow the team (because it’s not just designers) to think about the whole product in context. Amazing design is greater than the sum of its individual parts.