Thursday, 5 November 2015

The One Button Approach

A great way to start off a blog post is to tell a story about Steve Jobs. So I will do that. Unfortunately I don't think it's true. Not even slightly. I've only heard it as an anecdote. But let's pretend it's true, it's funnier that way. The story goes like this:

Apple was about to implement a "clone DVD" feature. So a group of people got together to specify and sketch out how this clone feature was going to work. They prepared some documentation and some wireframes for the day when Steve Jobs was going to meet them and approve their work. They felt prepared. And the day came. Steve entered the room where the group sat. They were ready to hand him their work and present it to him. But Steve just walked up to the whiteboard and drew a big button that said "Clone DVD". He then said "This is what you are going to build. Good luck!", and then he left the room, leaving the group staring at the whiteboard.

This little story has got me thinking if it (besides not being true) is a good way to think about how one could "slice" stories. Or split the work into something minimum.
Imagine if all your application had, or some part of it, was just a single button. Not likely, but not the point. Work your way backwards from there, ask "Why isn't it possible to just have a single button?"
I like to use stories as just that: stories. Perhaps just some short note on what we want to achieve. Like "Clone DVD". Just a verb and a substantive. Perhaps you could use user stories as well, but they don't really serve as a button, do they?

Let's take another example. Let's say we have a site or other application where one of the things people can do is apply for jobs. You already have a button:

Why won't this suffice? Well, one obvious thing is that a user doesn't even know what job they would apply for. Another is that we, as a receiver, wouldn't know who the applicant is. And there are lots of other things we could do here to make people want to apply for the job. But still, as a first iteration (or sprint), why not keep just the button? Make up all other things meanwhile. This way we can work on making the whole thing work all the way through the process and actually make a fully working job application. Then keep adding the other features when you know it works all the way through.

Or, this single button could work as a starting point for a discussion. As said previously "Why won't a single button do?" then let the discussion flow, but keep in mind "Do we really need this now?". The ultimate goal is to just have that single button. Wouldn't you love this as a user as well? "Clone DVD" and voilà!

What is the point here?


After I've got some feedback I feel I wanted to update and clarify.
The feedback was that a button feels like a solution. While this actually can be true (as in that we in a first iteration deliver a single button) it isn't the main point. I'd like to emphasize that it probably never will happen that we deliver a single button at any point.
First of all, the button should have the name of some capability (like "Apply for job") and then act as a conversation for what is required for e.g. applying for a job and how it can be achieved in simplest way. But, most likely the end solution will not even have a button named "Apply for job", it might be just "Save" or "Send" or something.

The button is hopefully a good way to trigger an early conversation about the UX (User eXperience: the user interactions, the flow, the design (although not initially the graphical) etc.). The true value of an application happens in the usage - the interaction that happens "between the screen and the chair". An application won't ever be valuable unless someone uses it and it makes that person more productive or creates better quality work or is faster or is just simply happier or whatever. And the best way is to start (and end) in the use. Having a discussion around the UX is also a great way to create shared understanding of what we want to achieve in general. Hopefully we can also see the value in having a UX designer at an early stage. Perhaps start building "paper prototypes" etc. "Visuals" are usually much better at trigger discussions than just plain text.

So please don't mainly see this as a way to deliver a single button. It's just a conversation starter. You can still read my previous point (it's strike trough to note it is the "old" one.):

It's about simplicity. Do not add more than necessary. I think The One Button Approach can help with this. Perhaps you struggle to come up with what do deliver in the first iteration? Just focus on making it work with the use of one single button. Like a vertical slice. And as I've mentioned already, it could also be used in story discussions (or call it "gathering requirements"). The thing to discuss is "Could the user experience just be a single button; 'Do the thing a user wants to achieve'?". And evolve from there, perhaps add more buttons for all the things a user of the application would want to achieve.

Still valid, though it is mostly confusing perhaps..?