In our agile programming case study, we have two corporate goals, but one of them (learn Ruby on Rails) only drives constraints, not requirements. The other goal is to make it easier for people to find and read great content in our niche. This makes the documentation of goal-driven use cases pretty straightforward. All of the use cases support this single goal.
With an understanding of the goals, the next step is to define the use case names.
Before we can do that, we have to revisit and re-organize our goal definitions.
User Personas Drive Practical Goals
However, we’re folding in some elements of interaction design by defining user personas, which means the hierarchy of support structure for our goals is a little different.
We defined four personas in our earlier article:
- Jill the Business Analyst (Primary)
- Paul the Product Manager (Secondary)
- Brian the Blogger (Secondary)
- Ellen the Program Manager (Supplemental)
Defining Practical Goals
These practical goals represent the role that each persona might play in achieving the corporate goal. There is a lot of overlap in what the different personas want to do, and that is further complicated by the context in which they want to do it. The ideas are really very simple, but describing them simply is complex. We looked at the needs of the different users earlier.
To bring things together with clarity, we will document the goals here, and parenthetically identify the personas that share each goal.
- Learn a Beginner Topic (Jill, Ellen)
- Learn an Expert Topic (Jill, Paul)
- Promote an Article (Brian)
- Share an Idea With Non-Users (Paul)
- Participate in Discussions (All)
- Score a Good Idea (All)
The last goal is more nebulous than the others. For some people, scoring an idea may be “the cost of doing business”, recognizing that it is the way the site works – ideas that are scored highly are easier to find. These people may see the scoring of articles they have read as their payment into the system, so that they can more easily find articles with great ideas (because other people score those). It is a communal dynamic.
Other people may simply score articles because it is a good thing to do – a for-the-betterment-of-all approach. This is easy to rationalize, because by raising the skill levels of everyone in our niche, we raise the value and visibility of the value we can provide to employers. And this increases demand for our services. This is very indirect, but intuitive. I honestly don’t know if this is a motivator for most people.
Here’s a quick poll – please let us know why (and if) you would score the articles on the site.
[poll=6]
Also, please note that we’ve used promote to imply promotion of your own article, and score to imply “promotion” or demotion of articles written by other people. This distinction will be necessary to clarify when we are discussing features to support Brian’s objectives.
Defining Use Case Names
The diagram above shows scenarios instead of use cases as the next step. From the referenced article:
The practical goals are an analog to the Wiegers goals – they represent the software-relevant goals of the company, in actionable language, associated with a particular persona (class of users). The association with the persona is the key element that allows for great design. The actionable nature of the goals may incorporate or imply particular business process design decisions (made outside of the scope of either process).
The main benefit we get from this approach is the ability to not implement the non-essential features. The absence of these fluff-features allows the most important users to master the software faster without having to deal with low-value complexity.
The scenarios are effectively the same as informal use cases.
For this project, we will use use cases – it probably simplifies communication, and as the quote above mentions, the same objective is met. Each goal is listed again below (in bold), and the names of the use cases that support the goal are listed underneath it. A use case name is listed multiple times if it supports multiple goals.
Learn A Beginner Topic
- Create an Article Mashup
- Browse an Area
- Search for a Topic
Learn an Expert Topic
- Browse an Area
- Search for a Topic
Promote an Article
- Promote an Article
- Rate an Article
Share an Idea With Non-Users
- Broadcast an Article
- Broadcast an Article Mashup
Participate in Discussions
- Comment on an Article
- Comment on an Article Mashup
Score a Good Idea
- Suggest an Article
- Rate an Article
- Create an Article Mashup
- Rate an Article Mashup
Note that “suggest” is used to represent creating a link/entry in the site for a particular article written by someone else. Also note that “promote” and “suggest” may get combined if the Brian the Blogger persona ranks lower in the priority for the site. Or Brian may be able to use the “suggest” functionality to achieve his goals.
New Idea Introduced
As part of naming the use cases, we introduced a new idea – the idea of an “article mashup.” Think back to when you did research for a paper in high school (if you’re old enough) – you found passages in magazines and books from all over the library. You photocopied them, and maybe even stuck them all together in a binder and called them “research.” Then you referenced those articles from different sources when compiling your paper.
Now imagine if you could do the same thing, but make it useful for everyone else, and make it be easy!
You could have a mashup like “Intro to Use Cases” which included references to several articles about use cases – the ones that you found to be most helpful when getting started. All bundled together, put in order, and made easy for consumption by other people. These ‘mashups’ of articles can be pulled from anywhere on the internet, mixed and matched as you please. Since these mashups have a value beyond the sum of the articles included in them, they should also be rated and reviewed – just like individual articles. This may even be the killer feature for the site.
Did We Miss Anything?
Any of the user goals slip through the cracks?
Any use cases that you think we missed?
Got any feedback on the mashup idea?
The mashup idea makes me think of a combination of Squidoo and Amazon’s “So You’d Like To…” feature. I like the idea of putting this functionality into more topic-specific applications, and I think rating is key to its usefulness.
Hey Sarah, thanks for chiming in!
By “So You’d Like To…” do you mean the stuff at Amazon where people who liked one book like others, or something else?
That’s an excellent idea – when you record your likes and dislikes about articles, have the system suggest other articles that you would like, based upon an analysis of [a bunch of stuff].
For example, if you rate an article highly, and 75% of the people who rated it highly also liked another article, then you would too.
Extremely cool! I think this is another killer feature.
Hey, Scott—actually the “So You’d Like To…” guides are a little different. For example, see this one entitled “So you’d like to…learn a little about Web page and Web site design.”
I think personal, viewing- and rating-based recommendations are definitely another area that has potential. You might want to check out Criteo down the road as a simple way to implement this; they have some really interesting technology.
Hey Sarah – thanks for explaining. OK, so the “So You’d Like To” idea is pretty much exactly what I wanted the mashup to be. I actually started with the idea of listmania lists from amazon, and thought “what if the items are in order – it could be a tutorial.”
Also – great link to Criteo, thanks! Would be an easy way to outsource the “you would like” algorithm – but the API is pay as you go.
The idea of learning by creating and broadcasting is simply sexy. I’d like to see that as a key feature.
Hey Rolf – totally. The main reason for delaying it is pure incremental development: first get articles, then get mashups. I agree that it is a killer feature.
Thanks for chiming in!