robjam.es

Over the years, I have been involved in many web development projects (web sites and web applications) and teams, and something that we constantly do, but everyone has their own method, is to design or describe the web site as a whole. Some people use wireframes, prototypes, use cases and a whole variety of methods with the main purpose being to communicate the site across.

So I have come up with a method that has treated me well over the years, and I have found it to be the most effective and simplest way to get the message across. Firstly, lets clarify what this ‘message’ is. With lots of people getting involved in the project, you need a way to describe what it is about, particularly from the point of view of the user. Once someone sits through your PowerPoint presentation, wireframes or screenshots you want the audience to say “I get it, I see what you are doing” They may have questions – but the questions should actually clarify that they understood. So here is my method.

I use something that is called a Scenario, and this is not anything unique, but I have a very clear method that works for me. A Scenario is a creative writing piece, written in prose. You are writing a story where the “stage” is your web site. And you are describing the most likely path a user(s) would take in your site. It is the 80/20 rule and we are just focusing on the 80 side. Don’t get distracted by the “what about if this happens?” questions, you will deal with them later. Focus on what you WANT the user to do. A Scenario has three main parts; the overview, character introduction, and the Scenario itself.

The Overview

The overview is really straight forward, and it sets the scene. I like to describe what is going to be demonstrated in the scenario. For example, if I were to write an overview for the popular site digg.com (one of my favorites), I would say something like;

“This scenario will show how Oscar has found a news article that he would like to share, and he posts it on digg.com. Mary then comes along and reads the article that Oscar posted, and votes it up by digging it”.

Now, you will probably put a little more detail than that, but you don’t want the overview to be longer than a paragraph. You will notice a couple of important things here. Firstly, I am only concentrating on the core story I want to tell, I am not mentioning digging down, subscribing etc. You may want to mention these things in the body of the Scenario, but only if it is considered part of the core story. The second thing you will notice is that I have introduced real characters. This is important, don’t use names like User1 and User2, use real names as they help people visualize the scenario. This brings us to the second part of the Scenario.

Character Introduction

In the previous section we named a couple of characters, and now you are going to describe them. In this section, you outline all the characters in you scenario and you talk a little about them. Make sure you don’t have too many Characters; I prefer 2-3 and never more than 5. If you have more than 5, your story is too complex and you should consider breaking your scenario out into multiple scenarios. To carry on with our example above, lets see what Oscar’s introduction might be;

“Oscar is considered a power user of the net. He is a professional in his mid 30’s and spends much of his spare time looking for anything he thinks is exciting on the web. Oscar blogs a fair bit and is on top of technologies such as Twitter and uses his iPhone a lot to communicate with friends”

So in those few sentences we have a pretty good idea of who Oscar is. And we can visualize him and what motivates him. Again, use the 80/20 rule, make sure the character your describing, describes 80% of the users that you think would use the site. There is no point describing Oscar in this way if most of the users of your site are going to be 18 year old high school students. Also, some people like to give their character a “purpose” of what they are doing on the site – I don’t like doing this, as I use a scenario to describe the options, not to be concrete about what this user is going to do.

The Body

This is where we get into the meat of the Scenario. This is where you are going to start telling a story. Now the format you want to follow here only has 2 rules. First rule is that you need to break out your Scenario into parts if there are clear parts (think scenes in a movie). So from the overview above, there are clearly two parts here; Oscar posting his news item and Mary digging it later on. You may want to add parts for becoming a member on the site as well as commenting or other things that you want to describe. But clearly label the parts as “Part 1?, “Part 2? etc.

Second rule is that you want to write the scenario in numbered bullet form. Where every process or series of steps is a bullet. So again, continuing with our example;

“PART 1
(some other steps about logging in)
d. Oscar  clicks on the Post Story link. He is taken to a page that describes the process for adding a news story. Oscar pastes the link to the story, provides a title and short description, and clicks on the ‘Post Story’ link.”

Notice that we don’t talk about spell check or other things on this page, as they are just not important yet. You just want to get a clear flow of what the story is, and describe in as much detail as you think is relevant to tell the story. You will find this pretty easy, as you will start to draw a picture in your mind about what this should be and you just describe it

The only thing that you may want to do in the body of the scenario is add the odd comment that is not part of the core story. Try to avoid this, but if you think that it is important to get certain points across – then do. For example, I usually add technical comments here. If there was a payment processing page; “Need to determine if PayPal will be sufficient or need to process Credit Cards directly”. This is perfectly fine and is a place holder for the future.

What to do now?

OK, now that you have the scenario, you should find that this is adequate to circulate to get feedback from parties on the flow and what the expected user experience should be. You will also notice that a few interesting things happen. The first is when you are writing the scenario, you will certainly hit some hurdles. And these are probably because those aspects of the application are not detailed out as yet. And that is fine. The Scenario is a living document that you can constantly update.

I use Agile as my development methodology. So once I am happy with my Scenario, I usually print a copy off and start going through it and scribble “story cards” out. You will find this real easy to do. You will start to see things like; “User Creates new Article Posting” or “User Diggs story by clicking on vote button” etc. These things not only become blatantly obvious, but there is also traceability. Meaning that they are there for a reason, they were in the Scenario, it was not something that was added for the sake of it.

And don’t stop at one scenario, write a scenario for anything that has a user process, even admin functions, it will help you understand and visualize the end result. And it is a low cost way of doing it and anyone can do it with a few simple guidelines.

The Scenario also gives you the opportunity to start detailing out parts of it. In my example Scenario above, the ability to post an article might be quite complex, but in the Scenario it will be a simple overview. But now you can start discussing, arguing, creating wireframes etc to get the detail out.

So think of the Scenario as your application blueprint, the reason why you build the functionality that you do. And it is also a sanity check. You should be able to go back to your Scenario to see how a feature fits. It may fit and you have to rework your scenario (or create a new one), or you might just say “Why the hell are we adding this!?!?”.