To make something that people love, that they intuitively understand and can take advantage of, takes a lot of dedicated thought and hard work (and continuous evolution).
At the start, most projects don’t sound like they’ll be all that complex, but that’s because most people are really just thinking about the high level end product.
They aren’t initially thinking about all the tiny, required, steps that take a user from start to finish for a given task.
The complexity is hidden.
After 20 years of building ‘web stuff’, I’m still not an expert at dealing with this myself, but one of my best tricks for fleshing out the complexity of any project is to story board every scenario I can think of.
I’ve found that this gives you a lot of advantages actually:
1. It requires you to state every action, result, or goal you’re asking your user to go through (forces you to think about every detail).
2. It gives you a visual representation of just how involved your product is (ie. how much work a user needs to go through to accomplish anything/everything).
3. It shows you how all your 'features’ are tied together (or not). This in turn, gives you a great feel for what kind of 'flow’ your system really has (overall 'flow’ is *way* under rated in software development these days).
4. Most important of all, it makes you think about everything on a detail level from your users eyes…and that can go a massive way in pointing out real spots of complexity and confusion.
So it seems there are lots of advantages to story boarding, but how do you do it?
Well on a basic level it’s pretty easy (in my examples below I just use bullet points so as to highlight the general concept, but I *highly* recommend you do this on paper with boxes and arrows and stuff in real life – I think it just 'feels’ better and more complete that way):
1. Start out making a list of all the things you want a user to be able to do (be as specific and complete as possible – warning: this will and should take a lot of time).
So for example: A. Create an account. B. Sign into an account C. Change a password D. Change an email, etc. etc.
2. For each of the things you listed out in #1, start with 'home screen’ and map out what a user must do to get from that starting point to accomplishing the specific goal (and don’t forget to include the last step which is what is presented to the user when they have accomplished that goal).
So for example, to create an account:
A. Homepage B. Click 'create account’ C. Fill out create account form (list all fields here if you can, maybe as an appendix; iterate as needed) D. click 'create’ button E. If created, take user to 'Activity stream’ page, if not created reload create account form and give reason for error.
What you’ll hopefully notice here is that there is actually very little 'logic’ listed in this process. I list one condition because there are two different screens that a user can be sent to, but I don’t list out the details of what the business logic is to really make that (or any other) decision.
You can do that on your story boards if you like, but I find that it makes these things a bit too cluttered and complex for this stage.
We’ll eventually have to breakdown and list out that business knowledge of course; but it doesn’t have to be a part of our story boards – this gives us the added advantage of being able to widely share our story boards to the public without having to reveal any business logic secret sauce (if you’ve got any).
Anyway, in the example above we only talked about some *very* basic account stuff that almost every web service is going to have…and yet you see that even just that quickly explodes into a lot of stuff that a user must go through and understand (not to mention what a developer must build)…so imagine what happens when you apply this to the more complex and meaty sections of your actual service (ie. the real product and features).
But trust me, if you put the work in up front on this sort of thing you’re end product will have a *much* better chance of being simple, intuitive, and something people can truly love.
This post has received 39 loves.
Kevin has a day job as CTO of Veritonic and is spending nights & weekends hacking on Share Game Tape. You can also check out some of his open source code on GitHub or connect with him on Twitter @falicon or via email at kevin at falicon.com.
If you have comments, thoughts, or want to respond to something you see here I would encourage you to respond via a post on your own blog (and then let me know about the link via one of the routes mentioned above).