One of the biggest problems in delivering a website, and yet probably the least talked and written about, is how to decide, specify, and communicate just what, exactly, is it that we’re going to build, and why. What problem are we solving? Who needs it? What’s this site for, anyway?
Poor understanding of target user needs or our client’s vision, ineffective use of limited resources, misguided emphasis on the wrong design priorities, over-emphasis on pet technologies — all will contribute to a failed, late, inappropriate or too-expensive website. Experience can teach us how to avoid pitfalls, but the greatest lesson can be learned by the least experienced: the earlier that purpose and goals are clearly defined and recorded, the more easily problems are identified and solved, the easier it is to stay focused, and the better the result is for everyone.
Somewhat surprisingly, web developers seem reluctant to adopt methods and approaches from other disciplines that could reduce their problems. Particularly during the crucial initial phase of projects, we can benefit from emulating certain software engineering practices.
Introducing use cases#section2
An especially useful technique to consider is use cases. Use cases provide a simple, fast means to decide and describe the purpose of a project. They’re successfully employed by many software engineers as a way to capture the high-level objectives of an application during the initial phase of development. There’s no reason that web site developers shouldn’t also benefit from a use-case driven approach. Even a project that initially seems straightforward can balloon into an unmanageable behemoth if the purpose isn’t kept in mind.
So, just what is a use case?
To define a project’s use cases, we need to consider two concepts, and how they relate:
- the actors
- the goals
Actors are everyone and everything that will use (or be used) by our new website. Goals are what one, some, or all of the actors want to achieve. To be complete, every use case must describe a specific goal and the actors that will perform tasks to achieve that goal.
The actors are external to our site — we can’t create or directly control them — but they do perform roles to achieve its goals. The most obvious actor in the case of any website is a visitor to the site. Perhaps their goal is to buy one of our thingamajigs or to check an account balance, book an appointment, download software, or simply absorb content that interests them. Actors are not necessarily human; perhaps we are developing syndication system to deliver information to many subscriber-sites. In this case, the remote consumer-servers are actors.
Whatever our vision, use cases will describe the goals achieved by actors who perform tasks.
Applying use cases#section3
A weblog enables its owners to communicate thoughts about a topic and others to read them and perhaps respond. The obvious weblog actors are the authors and the visitors to the web log. The author plays the role of generating the content and the visitor plays the role of reading the content and responding. The goals are to inform and to be informed.
After a little brainstorming, we could decide that some of these actors’ tasks should include reading an item, creating, editing, and deleting blog content, commenting, syndicating, and some administrative tasks, such as controlling access, permissions, and accounts. Some of these tasks are common to all actors and some may be exclusive to a single actor. All of them can be encapsulated in a use case that describes our initial idea: “Publish Weblog”.
This use-case diagram illustrates the relationship between actors and goals:
Use-case diagrams make it easier to think about the relationships, or dependencies, between use cases and actors. Perhaps visitors and authors would like to be able to search for particular content already published in the weblog:
Both visitors and authors want to be able to search. Furthermore, it’s not possible to search for content that hasn’t yet been published. The “Search Content” use case is therefore dependant upon “Publish Weblog”.
We’ve decided to employ Google for our searching function. Google becomes an actor and the “Search Content” use case is dependent upon Google. Google’s task as an actor is to deliver search results.
By now we’ve already identified some of the actors involved with our weblog, the goals they are trying to achieve and some dependencies between them. We can consider this a high-level conceptual architecture of our site, which will be useful when making design decisions later.
It’s all good#section4
The crucial benefit of use cases is the way they encourage a directed method of considering project requirements. From the very beginning, we are designing a product by concentrating upon the needs and wants of those who will use it.
As with any foundation, the better our understanding of the use cases, the easier, more focused, and more appropriate will be the work that follows. Use cases are the context that allows us to easily picture where, within a project’s life, a particular element will fit, thus promoting clearer decision-making throughout design and development.
The purpose of describing use cases is emphatically not to fully specify the exact nature of what a new site will contain and how it is to be built. Instead, use cases define goals and purpose: the problems we are trying to solve. Establishing these goals lays the foundation for the scope that will follow. Additionally:
- If we simply consider the roles played by the actors and their goals, the use-case model can very rapidly emerge.
- Use-case diagrams can distill a complex project into a more easily comprehensible picture.
- A well-constructed use-case model can be understood by all the stakeholders in a project: developers, managers and clients. It’s a powerful aid to collaborative development.
- Use cases ensure that scope is under control from the outset. The identification of use cases and their dependencies makes it easy to distinguish between core goals that must be satisfied and subsidiary enhancements that may be postponed as. Scoping in this manner allows for better planning and prioritization.
- It’s an implementation-neutral picture of a project. No assumptions about tools and technologies are made, nor should they be.
- It’s transportable. No special tools are required — sticky notes, a whiteboard, pencil and paper, or your favorite graphics application can all be used to document your vision.
Use-case driven development is a mindset, as much as it is a technique. By emphasizing the actors and what they wish to achieve, project teams can advance with greater confidence and clarity. A solid early foundation of understanding amongst all concerned allows more rapid decision-making later on, and encourages a continual focus on the project’s true purpose. Much has been written about best practices for describing use cases — Alistair Cockburn’s is probably the best 1.
To see some more use cases in action, visit guibot.com, which offers alternative, use-case views of many pages.
This is a great example of how practices used software development can benefit web designers. I’ve also written a bit on the subject too of a more agile approach (taken from software design) and it’s application to building web applications with standards:
http://hookom.blogspot.com/2004/12/easing-project-development-with-css.html
Thank you! Good article and very useful sounding approach. One point I’d like to make is, in my experience, this type of activity generally needs to happen during the RFP phase (before the client is “your” client).
Thats just distilled several weeks of lectures on UML into a much easier to understand approach. Thanks very much.
I can definitely see this coming in helpful for teams. I suppose you could parellel this to something like documenting your own code. It’s especially recommended when working with programming teams, but can also be highly beneficial to oneself.
Plus, pictures make for easier understanding on project managers and clients and the non-techies.
The use of use-cases is also very similar to writing pseudo-code. In the end, the lesson learned is that you need to draw some kind of map out of the project before diving right in.
As Jan Marie pointed out, you can use this approach to land a client or even write an RFP
Actors, UML and documention, oh my! Nice to have a double issue (if it is), just having some flashbacks to my software project courses.
A tool I like to use a lot is creating scenarios. I would say they are the same than use-cases, except scenarios are explained by words instead of pictures. I would recommend to use both, the use-case gives the overview, the scenario tells the client what happens (in case you don’t present it).
Am I wrong with my interpretation?
Michael, yes, storyboarding a project in terms of user-scenarios might be considered an informal application of the idea of use cases.
The chief advantage of the more formal approach that use cases encourage is that they make it easier to infer and explore relationships between different scenarios, which is very useful later on, when making more specific decisions about implementation and functionality.
We include user scenarios as the make up of the use case. The use case defines the goal and the user scenarios make up the tasks to acheive said goal. So the use case actually puts boundaries around the scope by grouping the user scenarios.
A use case is a description of the interactions between some actors and a system in order to achieve some goals. A scenario is a specific instance of those interactions. You can think of a use case as a collection of scenarios. Many things can happen in a use case (from success to failures).
A use case is usually in text and can be as short as a paragraph to a fully-dressed written with all the details. It is nice to have diagrams, but the text is essential.
These use cases can be presented in another way using UML. The result is those diagrams. The ones used in this article are usually called the “use case model”. There is a box to delimit the system’s boundaries, with the actors on the ouside and the use cases inside. Scenarios can also be diagrammed into sequence diagrams.
I wish the author would have shown a concrete example of the “publish weblog” use case. We are told it is a use case, but what does it do? It can be interpreted differently by different people, and that is confusing. Another article to go into more details would be nice.
We will be writing more detail in following articles, but more detail is immediately available at http://www.guibot.com/ as well as in Dr. Dobbs February 2005 issue under our article “Extend UML”
This is just a very global view on what and how to do in a development process. In fact information architecture has become an important part of web development process a long time ago and it has enormous amount of methods and approaches which were not mentioned here.
However useful or helpful this methodology may be, it’s worth pointing that this is generally not at all what your clients or coworkers will be expecting when you are asked to deliver a “use case.”
What is described here could be considered a “business use case,” but it seems more like a user scenario to me. True use cases, by contrast, specify the goal in context, preconditions for success, success and failure end conditions, primary actor, and relevant triggers (if any), and proceed by stepped actions (including branching actions) from task inception through completion. This, at minimum, is the information your deliverable will be expected to convey.
Norm and Tim began their article with pointing to the most difficult questions, which still are undecided for many projects in development. They are: “What problem are we solving? Who needs it? What’s this site for, anyway?” (These questions are just a quotation from the article and later I’ll restate them.) But later in the article they put these questions aside leaving the global level and descending to more practical level of the work on the project.
And I think that before using some practices like use-case we must concentrate on the global planning and answer to 3 main questions:
1. What are we designing the site for? What are the goals that will be archived by this site?
2. For whom are we designing the site? What are the goals, needs and demands of potential users?
3. What information can we deliver by the site both to archive the goals of the site’s owner and to satisfy the users?
I think these are three pillars of any web-site development project. And they are exactly those main questions about which Norm and Tim just mention at the beginning of their article and then go over to practice, to use-cases.
But without clear understanding of what we want, who our users are (what they want) and what we can give to them by means of our site, we won’t be able simply to say WHAT WE HAVE TO DO, we won’t know how we should work and what we should get as a result of our work.
And later, after answering to these questions, as an evolution of the answer to the second question we finally can get back to use-cases described in the article.
I liked the article but I did think that the choice of case was a little confusing I’d have had blog in the centre rather than publish blog then labelled the right line publish and possibly also given them an administor link as well and then given a visitor comment and also read.
Overall a good introduction with a lot of scope for a follow up.
i call bullshit. software engineers don’t know much about design, the actually fuck up most of the projects designwise. look at how bad most software is. and the best part is that most software development happens outside the “established” software engineering theory, because this theory again adds nothing to the process, but it actually kills good design.
do you really want everything to be as unusable and unstable as software is? if you want to look at examples, look at architects, look at product designers, look at other design disciplines where at least some portion of the products are decent. forget software engineering as a role model, it can’t teach you nothing.
“forget software engineering as a role model, it can’t teach you nothing.”
What an enlightened approach tho the pursuit of knowledge and understanding.
I’ve found use cases very helpful in developing websites with a lot of back-end functionality, i.e. web applications (which, like it or not Peter, are pieces of software). Use cases are just a tool that can be utilised, just becaue you use them doesn’t mean your site will be an outstanding example of good design, and vice-versa.
Architects have been around for thousands of years and you still get crap buildings. Software engineering is still very much an evolving discipline and to say that people who build websites can learn nothing from it seems a bit, well, dumb.
Excellent! I think there’s much to learn from Use Cases.
However, forgive me if I’m wrong, but I believe that what this article describes is more the Use Case model than the Use Case per se.
The use case model is a visual representation of all the use cases: the stick figures, the arrows and the bubbles. Each buble in this diagram is *a* use case.
A use case is usually documented in writen form (paragraphs and bullets), and describes the actions taken in that bubble. That is, the user inputs/actions and the system responses. These could potentially “link” over to other use cases (sort of like a sub-routine in programming).
My preference is to have both, the Use Case Model and the acompanying Use Cases. That way you can look at the diagram to get the big picture while reading each use case (the bubble stuff) for the details.
All in all, a good teaser…
Regardless of what title seems fitting, creating a visual for clients can be extremely valuable to communication.
For those of you out there with OmniGraffle, I’ve put together a rather simple stencil to create use case diagrams.
http://www.mediaville.net/projects/stencils/
Hope it’s useful.
I have to agree with Adam Greenfield that the examples demonstrated here are not a good representation of ‘real world’ use cases.
As a programmer who has endeavoured to work closely and thoughtfully with interface designers, I’m quite aware that a improperly rendered drawing – however simple – can confuse and muddle a conceptual understanding of a simple functional model.
For example, the first illustration in the Carr and Meehan article might suggest that both the Visitor and the Author can publish the weblog. Is this the case? Of course it’s not, because both arrows point towards ‘Publish weblog’ this could suggests interaction by both actors, this is where confusion can arise.
I am lucky enough to have colleagues who are developing code using agile methodoligies. Exposure to these guys is providing me with some techniques and learnings to experiment with during project definition and scoping with designers and client managers. In particular user stories, sometimes combined with use case illustrations can be very effective.
Unfortunately, it seems that Peter above, is of the opinion that software developers know little about design. Artistic and graphic design maybe, but if you’re to suggest that they know little about application design – well, you’re wrong. There is a language for every field of knowledge and to communicate with individuals from other fields you must learn their language. Bearing this in mind can improve how effectively you can work with software developers – and how software developers and work with designers.
Now, I have to admit that this article totally shines a new light on most of what my company does… Thanks!
Good introduction to get people started on UML, I am just curious what program was used to create the articles UML diagrams, or what suggestions do people have for UML diagrams, also does anyone have any good articles/links/examples of UML with regards to web development?
Michael,
As for the application to make uml diagrams:
give argouml ( http://argouml.tigris.org/ ) a try. It’s open source and basicly platform independent (Java).
Consideration is good, and important. However, observation is better, and is nothing more than simply discovering actual use cases. Go directly to the source!
To answer Mike Dance’s question – the Guibot website shows how Use Cases generate the menu for the web site. Also, the Guibot tools will generate the Use Case diagrams and the Use Case specification. Argo UML is an open source tool, Borland has a community edition designer and IBM Rational carries the more expensive sophisticated UML tools.
Besides Cockburn’s excellent book, may I recommend, by the same publisher, “Building Web Applications with UML”, Jim Conallen. Addison-Wesley, 2003. ISBN 0-201-73038-3. The author, from Rational Software, has developed a UML extension for modeling web applications.
peter wrote:
>>>i call bullshit<<< I smell trollshit. >>>software engineers don’t know much about design<<< Design is a fundamental part of software engineering. Without it, you would have a lot of people saying "OK, this is what the software needs to do" and then start coding without thinking about how it should be done. A software engineer knows a good deal about design by definition, or he/she isn't a software engineer. Unless, of course, by "design" you mean "graphic design" or "web design". And unless, of course, by "software engineer" you mean "programmer". (Which is not to say programmers don't know anything about design. But they don't necessarily need to.) >>>look at how bad most software is. and the best part is that most software development happens outside the “established” software engineering theory<<< See, this is the part that tells me this message was just intended to provoke. The '"established"' theory that "adds nothing to the process" isn't used for "most software"... and "most software" is bad? Can you miss the connection?
Since everyone involved in the project — client, developer, coder and visitor — are ‘Actors’, this is an excellent metaphor. It removes the site development them vs us thinking.
Developing a good scope of work plan [SWP] for a project — in the form of a proposal — is an important first step. Design & development is a cooperative process between the client, developer, coder and often test-users. Effective scope of work plans leave room for the ‘Actors’ to have input into schedule and sequence of things to be done PRIOR to signing a contract. Everyone has ownership.
A well thoughtout scope of work plan — revealing the often misunderstood complexity and many steps of an assignment — often serves to give the client a better understanding of why development fees should be at an adequate level.
We often spend a day developing a scope of work plan for an average project. Spend more time developing a thorough scope of work plan and you’ll have a clear blueprint for completing your assignment, invoicing, and client/vendor interaction, resulting in a project with less miscommunication and more satisfaction.
Just wanted to point out an interesting collaboration tool relevant to the audience here. http://www.taskportal.com
You wrote that “everyone involved in the project — client, developer, coder and visitor — are ‘Actors’,” but this is a misunderstanding of the terminology. (In fairness to you, it’s easy to see how this misunderstanding arises from the article.)
An actor, in the context of a use case, is generally the human being actually interacting with the application, device, or site – a user – although actors can also be institutions or systems. In this context, developers, coders, and clients are precisely *not* actors.
Misunderstandings like this are part of the reason why I believe UML is best used for what it was originally intended for, mapping application architecture, and not discovery-phase business- or user-needs analysis. It’s just not the right tool for the task.
Learned about User Stories (or use cases) through a book called Extreme Programming, which has the unfortunate acronym of XP.
http://www.xprogramming.com/xpmag/expCardConversationConfirmation.htm
In any event, the books on XP helped tons in my role as UI designer and liason between customer (User) and developer. And shaped how I communicate with any new client, no matter how small the site or job at hand.
Joshua Porter makes a crucial point when he says that observation is better than consideration. This is a distinction I make between weak and strong user-centered design. In weak UCD, we think about, or read articles about, users and then design stuff for them. In strong UCD, we observe them, preferably in the field, not just in the lab, and iterate with them during the design process (an approach at least somewhat compatible with agile methods).
Use cases can become simply another way of foisting our pre/misconceptions on unsuspecting users if we do not ground them in a rich understanding of users’ motivations, tasks, environment, and characteristics. The risk of this happening increases as the people for whom we are designing/building are less like us.
While either use cases or scenarios can help interaction designers and software engineers communicate, I prefer Contextual Design, with its emphasis on involving the entire cross-functional team in UCD. I’ve seen it transform an entire organization’s approach to developing software.
Mark
This article’s Russian translation is avalable at:
http://www.webmascon.com/topics/planning/21a.asp