Much of the tension in product development and interface design comes from trying to balance the obvious, the easy, and the possible. Figuring out which things go in which bucket is critical to fully understanding how to make something useful.
Shouldn’t everything be obvious? Unless you’re making a product that just does one thing – like a paperclip, for example – everything won’t be obvious. You have to make tough calls about what needs to be obvious, what should be easy, and what should be possible. The more things something (a product, a feature, a screen, etc) does, the more calls you have to make.
This isn’t the same as prioritizing things. High, medium, low priority doesn’t tell you enough about the problem. “What needs to be obvious?” is a better question to ask than “What’s high priority?” Further, priority doesn’t tell you anything about cost. And the first thing to internalize is that everything has a cost.
Making something obvious has a cost. You can’t make everything obvious because you have limited resources. I’m not talking money—although that may be part of it too. I’m primarily talking screen real estate, attention span, comprehension, etc.
Making something obvious is expensive because it often means you have to make a whole bunch of other things less obvious. Obvious dominates and only one thing can truly dominate at a time. It may be worth it to make that one thing completely obvious, but it’s still expensive.
Obvious is all about always. The thing(s) people do all the time, the always stuff, should be obvious. The core, the epicenter, the essence of the product should be obvious.
Beyond obvious, you’ll find easy. The things that should be easy are the things that people do frequently, but not always. It all depends on your product, and your customer, but when you build a product you should know the difference between the things people do all the time and the things they do often. This can be hard, and will often lead to the most internal debates, but it’s important to think deeply about the difference between always and often so you get this right.
And finally are the things that are possible. These are things people do sometimes. Rarely, even. So they don’t need to be front and center, but they need to be possible.
Possible is usually the trickiest category because the realistic list of things that should be possible will often be significantly longer than the list of things that should be obvious or easy. That means that some things on the possible list might be better off off the list completely. Instead of making them possible, maybe not making them at all is the right call.
Coming to know the difference between obvious, easy, and possible takes a lot of practice, deep thinking, critical analysis, and, often, debate. It’s a constant learning process. It helps you figure out what really matters.
But once you’re able to see the buckets clearly, and you begin to think about things in terms of obvious, easy, and possible instead of high, medium, and low priority, you’re on your way to building better products.
Jake
on 29 Nov 11How does Twitter fail into the buckets?
It can be argued that it does just 1 thing.
Tanner Christensen
on 29 Nov 11How many of us spend our time building products that do the obvious thing? How many innovators should, instead, start focusing on what’s possible?
The best question innovators can ask themselves is this: how do you know what’s possible if you don’t already know what’s obvious and easy?
Great insights and a lot to consider. Thanks Jason.
JF
on 29 Nov 11Jake: Twitter doesn’t do one thing. You can tweet, you can subscribe to people, you can make lists, you can advertise, you can retweet, you can star tweets, you can view media inline, you can use geolocation, you can search for friends, etc etc etc. It does a bunch of things.
Jake
on 29 Nov 11@JF
But Twitter didn’t do all of those things originally.
Originally, it was just 140 character posts that were sent out as a text message. Nothing more.
JF
on 29 Nov 11I’m not talking about then, I’m talking about now.
just wondering.
on 29 Nov 11Concerning David’s rant against top-tier schools below in the blog: um, seriously? Sure, some students at “top-tier” schools don’t outperform everyone. And sure, some companies love to hire them for the name. And sure, some of the students that come from these schools are arrogant. Blah blah blah… So what’s new?
But really, 37 signals? You don’t give a “fuck?” Who the hell are you arrogant assholes? Even as you imply that those of us who kicked our asses to get into these schools, then kicked our asses to get through the programs are assholes—you then act like the very assholes you are decrying? Um, I mean, did I just read that?
For the record, I never trained at my “top-tier” school to work at a company like yours. Hello?? I never wanted to work at a company like 37 signals, and I never will. The work we do is entirely more complex. It demands not only in depth, robust coding skills but also the ability to deeply engage with other fields in highly nuanced and critical ways. I’m sure your coders are fine for what you do, but God—please don’t pretend like your projects are anywhere near as complex as what you act like they are. Wow.
And I love your customer support motto: “happiness.” I’m just laughing out loud right now. Well, children, you can add another face to your “happiness” customer support system: “completely mystified.” That is, completely mystified that you all have the ability to actually shit on some of your best customers that way.
So just put me down as one of many customers you just lost forever. I WILL NEVER USE YOUR PRODUCTS, NOR WILL I EVER RECOMMEND THAT OTHERS USE YOUR PRODUCTS—FROM NOW ON. I guess you could say that my friends and I suddenly “don’t give a fuck” about 37 Signals anymore.
I’m sure this post will be removed, but whoever reads it and does the removal: just remember that David’s post has reverberated in ways that does not help people feel “happy.”
Cheers, and keep up the good work, children.
Jake
on 29 Nov 11@JF
What in saying is, it’d be interesting to know how you’d apply this post trchnique talking about “bucketing” to what Twitter originally was … a Minimal Value Product.
More concisely, how do you “bucket” things when all you’ve built (per the recommendation of this blog) is a Minimal Value Product?
Peter Whittaker
on 29 Nov 11Actually I think you have it exactly backwards: Things that are done infrequently, especially complex things, need to be obvious, because they are done infrequently. Think rarely executed administrative tasks with high impacts if gotten wrong, things you do every 6 months.
Why? Because if you do something all the time, it will take you time to get it right, but you will remember the twists and turns and do it right every time because you do it every day.
But the stuff you need to do infrequently you will get wrong every time unless it is obvious, because so much time goes by between attempts that your forget.
If your stuff/app/product does some very frequent thing in a mind-blowingly amazing way, users will learn painful steps to blow their minds with this frequent thing. But they will forget the complex steps for the infrequent and tedious and non-mind-blowing things, so those things need to be obvious.
Dude
on 29 Nov 11I read your post. But, ‘wtf, send an e-mail’, was my first thought. Or at least tell us what this is about…
Rander
on 29 Nov 11The last sentence disabled 3D. It was the word “instead.” Your awesome concept of obvious, easy and possible really becomes possible (and practical) when combined WITH priority. Because priority just ain’t going anywhere. A thought.
Tim
on 29 Nov 11Jason – thanks. This is a really good way to think about design.
Of course Microsoft have been using this approach in their UI forever. Everything needs to be obvious (i.e. on the button bar) AND everything needs to be easy (i.e. on the context popup menu) AND everything needs to be possible (i.e. via a k/b short cut)
Good to see WP7 has taken a new approach.
Hope you readers can find this comment buried under the off-topic crazy rant above :)
Alex Miller
on 29 Nov 11I think a related distinction is the one between making components of a thing easy (close at hand) vs simple (not entangled). This is explored better than I can explain by Rich Hickey in this video.
Alex Miller
on 29 Nov 11(Repost to fix link – feel free to delete the other one)
I think a related distinction is the one between making components of a thing easy (close at hand) vs simple (not entangled). This is explored better than I can explain by Rich Hickey in this video.
BT
on 29 Nov 11Jason,
I think you nailed it. I am responsible for a complex online product with at least 100 features and a customer base that is confused and contradicts itself a lot. In this environment, switching from a mental model of high, med, low priority to your concept of obvious, easy, possible makes things clearer and gives a fresh perspective on what site features to improve or build next.
-BT
ploogman
on 29 Nov 11Editing down to what is essential is not the same as easy/obvious/possible, but approaching a project and starting with easy/obvious is one way to at least get started, which is important too – so thanks for the post Jason – you’re like the calm zen force of design and protecting against overbuilding too early
Officer Grammatica
on 30 Nov 11Typo – Making something obvious is expensive because it often means you have to a whole bunch of other things less obvious.
Jon
on 30 Nov 11@ JF: Brilliantly put, I’d never thought of it that way before.
Freddy
on 30 Nov 11Thanks for your insights. It was really helpful.
Peter SHINe 신동혁
on 30 Nov 11These are the principles we often forget and we shamefully make bloatware we can’t even maintain effectively. Thank you for reminding us the importance of Obvious, Easy, and Possible elememts
@just wondering
on 30 Nov 11Did a top-tier school teach you how to comment?
It seems that writing comments in the right post needs to be an “obvious” feature for you.
Perhaps that’s not a necessary skill for whatever complicated stuff you do. Anyway, who needs skills when you’ve gone to a top-tier school!
Dan
on 30 Nov 11I think it still counts as prioritizing.
Priority 1 – Obvious Priority 2 – Easy Priority 3 – Possible
If you use a tool that lets you label priorities.
Chris Shepherd
on 30 Nov 11I’ve always loved a book by Don Norman called ‘The Design of Everyday Things’. It gives similar insight (although at somewhat greater length).
Kishor Gurtu
on 30 Nov 11What is not obvious about a paperclip is that it can annoy the hell out of MS Office users.
mONAi
on 30 Nov 11I started writing a response to just wonderings comment and I deleted the whole thing saying what’s the point, he doesn’t get the basics.
Thanks for tweeting this dhh.
Hugues Peeters
on 30 Nov 11Your article reminds me of Larry’s Wall moto about Perl: “Making Easy Things Easy & Hard Things Possible”.
Merle
on 30 Nov 11Comments are closed on dhh’s post that’s why just wondering posted here.
Bill B
on 30 Nov 11A developer’s idea of “obvious” and “easy” doesn’t necessarily match the user’s ideas.
Chris H
on 30 Nov 11I like this approach, and it’s possibly the focus I’ve been lacking when trying to design apps. To the guy who says it’s backwards, you don’t seem to be getting it – the mental expense of figuring out “how do I import an Excel document” or “how do I set up multiple accounts?” is minor compared to “how do I create a task?” or “how do I add a new user” assuming they are core to the product.
For twitter I imagine it looks like this. Obvious: Reading and posting tweets. Easy: Following people, retweeting, DMing, search. Possible: Changing privacy settings, creating lists, changing your avatar/personal info/account name, advertising etc etc.
David L
on 30 Nov 11@Chris_H +1 on your Twitter analogy; I think that’s the perfect way to think about how you might classify product/interface features under this rubric.
Good thought approach to user experience.
ps @justwondering, sorry you wasted $150k on a piece of paper, but you mind staying on-topic?
Travis Butler
on 30 Nov 11@Peter Whittaker: Yes and no. I think you’re confusing two meanings of ‘obvious’ here.
‘Obvious’ in the sense of the original post is mostly ‘how easy is this to find?’ Can the user see that they can do this? Is it easy for them to get to? The stuff they do ‘always’ needs to be front-and-center, or at least easy to access, because they’ll be doing it all the time; it can’t be buried.
‘Obvious’ in the sense you describe is also extremely important – but here, I think it’s mostly ‘how easy is it to figure out how to do this.’ I agree completely that the rarer and more obscure the task is, the more important it becomes to make it easy to figure out, for exactly the reason you describe – the user never does it enough to really ‘learn’ the behavior, so it must be as easy as possible to figure out from context and from the interface.
But, as the original post noted – while ‘easy to find and get to’ is a significant part of ‘easy to figure out’, it’s a zero-sum issue; anything you do to improve ‘easy to get to’ for one thing is going to reduce the same factor for something else. For example, the more elements you put on a menu screen, the more things are put in the user’s face to choose from; taken to an extreme this will start making menu screens cramped, elements smaller and harder just to click on.
drawtheweb
on 30 Nov 11Great post. Regarding how this applies to twitter (early twitter, not it’s current evolution) is a completely different issue though.
If your app is for super web nerds as twitter once was, less things need to be obvious, as the nerd will poke around to uncover all the possibilities and often receive satisfaction from uncovering features. I’ll suggest that twitter only had 1 obvious feature, to post something 140 characters or less. Everything else was possible. It was not obvious it use # or @ characters in a post for added functionality. This had to be learned, then it fell into the easy bucket. Now it’s so easy that it seems obvious.
I think the concept of evaluating obvious vs easy vs possible is most valuable when designing for the ‘non nerd’ set, specifically those applications running in a business context.
Byron Ruth
on 30 Nov 11This post is very poetic.
Ferenc Mihaly
on 01 Dec 11These thoughts must ring familiar to many designers. I just wish we could agree to use more precise and accurate words to talk about design trade-offs than “obvious”, “easy” and “possible”. The meaning of these is not only poorly defined, but also subjective. For one person obvious may mean a big, prominent, obtrusive, in-your-face, screaming “Buy now!” button on the screen. For the other it simply means a design consistent with previous buying experience. We engage in a lot of unproductive debates because we use the same words, but mean different things. I’m doing API design these days, but the challenges are very similar.
Rick
on 01 Dec 11@JF Great post, I think you nailed it. One thought on the debate about where/how priorities should be used… I see priorities as being the map, but the EOP being the destination(s). When someone is planning a trip, they first determine their destination and then figure out how to get there (at least that’s my experience).
Perly Unpatterns
on 02 Dec 11Easy things easy, and hard things sometimes possible.
Ryan Bradley
on 05 Dec 11The obvious and easy are definitely possible.
This discussion is closed.