Use cases as a brainstorming tool
Use cases define how users interact with a product or system, including actions users can take and how the system responds. It also identifies user goals and paths for the system to handle errors.
An example use case:
User Registration and Onboarding:
Actor
: New user.
Goal
: Successfully create an account and complete the initial setup.
Steps
:
- User navigates to the registration page.
- Enters required information (e.g., email, password).
- Receives a confirmation email and verifies the account.
- Completes a guided onboarding tutorial to set up preferences.
Variants:
User enters incorrect details, such as an invalid email or weak password.
Use cases can be written for different purposes, and the templates can vary to highlight the relevant aspects of the scenarios. Design and engineering teams utilize use cases to create a shared understanding of what the system or product does and how users are expected to interact with it. Use cases can also communicate technical requirements and the scope of the project.
Although use cases are typically written later in the design cycle—once the overarching features of the product have been decided and not at the ideation stage—we have found they can be a good tool for brainstorming.
Templating our use cases
At the Data Lab, we develop solutions for intricate problems, which have a slew of interwoven scientific and engineering complexities influencing design and implementation.
Traditional brainstorming techniques, like rapid ideation or mind mapping, did not allow us the space to consider these factors, which meant that either we needed additional rounds of discussion to surface the nuances or could only discover them much later in the process.
To mitigate this issue, we used use cases to explore the ideas before deciding which ones to pursue. Our use cases are structured a little differently from the above example to ensure that they highlight the aspects essential to us.
Each use case has:
- A scenario describing who the user is and what their goals are.
- A problem they are trying to solve.
- A set of information/artifacts they expect from the system.
- Details about their context.
- A list of system actions which describes what the product needs to do for the user to succeed in the scenario.
Use case format:
I am a _______________. I am trying to____________, but I have trouble __________. I would like to _____, ________, and _______, so I can _______________.
What does the system need to be able to do to meet this need?
-
-
-
-
Our process in action!
Here's an example use case from an ongoing project: the Pediatric Cancer Cell Morphology Atlas. In collaboration with the Way Lab at the University of Colorado Anschutz, we’re creating a web portal for exploring Cell Painting data of pediatric cancer cells generated by their lab.
The Portal is meant to allow researchers to search, explore, and download cell morphology profiles. These datasets are large, often containing thousands of columns. Handling and visualizing data of this magnitude with scientific accuracy on the web adds complexity to any seemingly simple idea. This project was a perfect candidate to employ use cases to brainstorm features so we could add those extra nuances to our ideas.
In this example, we use persona as a shorthand to describe who we expect the user to be in a scenario.
Example:
Applicable to:
Disease and Imaging Expert
I am a neuroblastoma researcher. I have conducted experiments treating a cell line with my lab’s favorite compound in the REPO1 library. I would like to know what compounds induce similar morphological changes in my cell line of interest and their structure. Ideally, I’d be able to see what morphological features contributed to a high similarity score.
System actions:
1. Users must be able to filter by individual cell line.
2. Users must be able to search compounds.
3. Users must be able to view metadata about the compound, such as its structure.
4. Users must be able to view and rank by a similarity measure calculated between compounds within the same cell line.
5. Users must be able to download ranked lists of compounds, which include metadata about compounds.
6. Users must be able to inspect features that underlie the similarity measure (example: rank features by contribution if using cosine similarity)
Having both a user's context and system actions gives us a better picture of the complexity of an idea and its implementation. It also allows us to identify items that require some feasibility analysis early on. The use cases help us identify feature ideas worth implementing and areas where we need to gather more information or conduct feasibility analysis.
Is your team tackling a complex project? Use cases can be a powerful brainstorming tool to guide smarter design decisions from the start!
Use cases define how users interact with a product or system, including actions users can take and how the system responds. It also identifies user goals and paths for the system to handle errors.
An example use case:
User Registration and Onboarding:
Actor
: New user.
Goal
: Successfully create an account and complete the initial setup.
Steps
:
- User navigates to the registration page.
- Enters required information (e.g., email, password).
- Receives a confirmation email and verifies the account.
- Completes a guided onboarding tutorial to set up preferences.
Variants:
User enters incorrect details, such as an invalid email or weak password.
Use cases can be written for different purposes, and the templates can vary to highlight the relevant aspects of the scenarios. Design and engineering teams utilize use cases to create a shared understanding of what the system or product does and how users are expected to interact with it. Use cases can also communicate technical requirements and the scope of the project.
Although use cases are typically written later in the design cycle—once the overarching features of the product have been decided and not at the ideation stage—we have found they can be a good tool for brainstorming.
Templating our use cases
At the Data Lab, we develop solutions for intricate problems, which have a slew of interwoven scientific and engineering complexities influencing design and implementation.
Traditional brainstorming techniques, like rapid ideation or mind mapping, did not allow us the space to consider these factors, which meant that either we needed additional rounds of discussion to surface the nuances or could only discover them much later in the process.
To mitigate this issue, we used use cases to explore the ideas before deciding which ones to pursue. Our use cases are structured a little differently from the above example to ensure that they highlight the aspects essential to us.
Each use case has:
- A scenario describing who the user is and what their goals are.
- A problem they are trying to solve.
- A set of information/artifacts they expect from the system.
- Details about their context.
- A list of system actions which describes what the product needs to do for the user to succeed in the scenario.
Use case format:
I am a _______________. I am trying to____________, but I have trouble __________. I would like to _____, ________, and _______, so I can _______________.
What does the system need to be able to do to meet this need?
-
-
-
-
Our process in action!
Here's an example use case from an ongoing project: the Pediatric Cancer Cell Morphology Atlas. In collaboration with the Way Lab at the University of Colorado Anschutz, we’re creating a web portal for exploring Cell Painting data of pediatric cancer cells generated by their lab.
The Portal is meant to allow researchers to search, explore, and download cell morphology profiles. These datasets are large, often containing thousands of columns. Handling and visualizing data of this magnitude with scientific accuracy on the web adds complexity to any seemingly simple idea. This project was a perfect candidate to employ use cases to brainstorm features so we could add those extra nuances to our ideas.
In this example, we use persona as a shorthand to describe who we expect the user to be in a scenario.
Example:
Applicable to:
Disease and Imaging Expert
I am a neuroblastoma researcher. I have conducted experiments treating a cell line with my lab’s favorite compound in the REPO1 library. I would like to know what compounds induce similar morphological changes in my cell line of interest and their structure. Ideally, I’d be able to see what morphological features contributed to a high similarity score.
System actions:
1. Users must be able to filter by individual cell line.
2. Users must be able to search compounds.
3. Users must be able to view metadata about the compound, such as its structure.
4. Users must be able to view and rank by a similarity measure calculated between compounds within the same cell line.
5. Users must be able to download ranked lists of compounds, which include metadata about compounds.
6. Users must be able to inspect features that underlie the similarity measure (example: rank features by contribution if using cosine similarity)
Having both a user's context and system actions gives us a better picture of the complexity of an idea and its implementation. It also allows us to identify items that require some feasibility analysis early on. The use cases help us identify feature ideas worth implementing and areas where we need to gather more information or conduct feasibility analysis.
Is your team tackling a complex project? Use cases can be a powerful brainstorming tool to guide smarter design decisions from the start!