Yesterday, we identified the high priority goal for the third release of nexus to be supporting creation of bundles of articles. In this article, we will define the use cases we need to support.
Defining The Use Cases
The first step in defining the use cases is to review the scope and vision for the product. Once we’re sure we’re operating within the scope, we review the goals of our personas, and then we define the use case names. The next iteration of the use cases is in the form of use case briefs. And finally informal use cases. This agile approach to use case definition seems like a lot of work, but the mechanics don’t take very long – most of the time is actually productive time spent thinking about the use cases. And the effort of writing a few things down introduces some implicit refactoring and editing. An analysis of the stakeholders at this stage will help identify any missing use cases – it helped us identify a missing one, as we’ll see below.
Scope and Vision Analysis
We reviewed the scope and vision yesterday as part of defining the goal for the release. The goal of bundles is to leverage the effect that the whole is greater than the sum of the parts to leverage articles from nexus to create valuable meta-artifacts that combine articles into cohesive collections, designed to achieve particular objectives. At a sound-bite level, people combine articles into bundles, and people will consume the collections of articles found in a bundle.
Persona Goals
We initially focused on Paul the product manager’s goal of sharing ideas, and started sketching out some design concepts based on how Paul might want to create his bundles. Those sketches helped keep us on target as we moved forward on use cases. From a classical requirements definition perspective, they were a bit of a segue. From an interaction design perspective, they were important embodiments of the ideas.
We actually missed a persona goal, until we did a quick stakeholder analysis. Until we reviewed the stakeholders, we completely forgot about consumption of the bundles – we had focused only on their creation.
All of our personas would be consumers of the bundles, with the possible exception of Brian the blogger, who is focused more on getting information out to others than pulling information in. Brian may be a bundle creator – he probably already creates summary-posts on his blog that collect multiple articles together. He can use bundles as a secondary means to organize his articles, or to combine his thoughts with others.
Use Case Names
The use case names we initially defined for the bundle-creators are
- Create a Bundle of Articles.
- Update a Bundle of Articles.
After reviewing the needs of other stakeholders, we added
- Study a Bundle of Articles.
Considering both the consumption and creation of bundles will definitely affect how we design the interactions and the implementation.
Use Case Briefs
Create a Bundle of Articles (Paul the product manager is the primary user, Jill the business analyst is secondary)
Paul defines the topic and a brief explanation of the goal of the bundle (to teach a new product manager how to write use cases). Paul creates an outline of the topics to cover in the bundle, organizing his thoughts and the topics. Paul then begins inserting existing nexus articles into the bundle at each point in the outline. Alternately, Paul may need to submit some articles to nexus in order to include them in the bundles.
Update a Bundle of Articles (Paul the product manager is the primary user, Jill is secondary)
Paul returns to an existing bundle, and adds new articles to it. Alternately, Jill adds an article to a bundle that she is studying to “complete” it from her perspective.
This raises an interesting question – should people collaborate on bundles? Or should it be single-author? I’m leaning towards collaboration, or an implementation that allows people to control it (e.g. make a bundle “open” for anyone to edit, or closed).
Study a Bundle of Articles (Jill and Ellen are primary, Paul is secondary)
Jill browses the available bundles in a particular topic area, and finds one that looks interesting. The bundle is a tutorial on how to write use cases for a project. She starts by reading the first articles, leaves nexus, and returns later. On each visit to the site she gradually reads the articles, occasionally rating the articles and providing feedback on them. Jill also provides feedback about ways to improve the bundle.
This use case would be greatly facilitated if there were a way to manually or automatically track which articles Jill has already read.
Stakeholder Analysis
Stakeholder analysis is important because it identifies who cares about a particular feature or functionality. It can be very effective for finding missing use cases – usually because of a focus on the indirect users of a product. For example, an accountant may generate reports with a product, which are then delivered to a regional manager. Although the regional manager does not use the software, her needs must be addressed when generating the report.
In the analysis of bundles, we initially overlooked the consumption of bundles. This was immediately obvious when we started to think through how they would be used. We went back and added the Study a Bundle use case. We also uncovered the possibility of a consumer becoming a collaborator on a bundle.
Summary
This analysis of use cases presents us with the inputs we need for designing the interactions, and defining the specifications for the bundles. The “under the hood” implementation will probably be very straightforward, while the user interface work will be more significant.
