Do you know what Use Cases are and why do we need them on a project? How to draft Use Cases? Let’s knock it down.
Hey Crizpers, how often do you utilize Use Cases and do you even use them? I would like to touch base on the importance of their usage. Why and when we would need Use Cases on a project and how to actually draft them.
Subscribe to CRIZPER YouTube Channel not to miss the latest Project Management Tips I have shared.
What the HECK is that?
What the Use Case is? Factually, this is a step-by-step description of the situation a user could get into while interacting with the system. As I have mentioned multiple times, Project Management and most of the items we are discussing here are applicable to many industries. Same here, as we can create Use Cases for every solution and product. The cases are the paths a user may act. They are the logical actions a user may undertake while working with a solution.
Sample
For instance, should this be a Mobile Application, let’s say, WhatsApp, the easiest and the most straightforward Use Case would be the process of sending a message.
E.G: tap to the app icon, browse the list of existing chats, pick one of them and tap on it. Tap on the message area and wait until the keyboard is displayed. Type the message and tap on the ‘Send’ icon. Ensure the message is sent and no error is displayed. If there is an error (exclamation sign next to the message), press on the not-sent message and pick an option to send a message again. When the message is sent, you will see a tick under it. If it is not sent, the escalation sign will remain. Should you keep seeing an error and the message is still not sent, try to check the connection and bla-bla..
Ok, we got on a high level what a Use Case is, but why would we need such paper?
Why and When?
From the Project Management perspective I see a couple of benefits Use Cases could bring to products in general. This was not a typo and I have intentionally written ‘products’. As you are aware projects are often being initiated for products, and usually to launch a product we need to kick-off a project. In Use Cases we describe the product workflow thus a product is a target for this tool.
As for the application area, I usually utilize Use Cases in three situations while managing projects.
Spot #1 – Planning
The first touch point when we need the workflow description is while planning the product design and the user experience for the solution riders.
Factually, this is a part of the project specification as in the spec we are going to describe the overall solution workflow providing an overall understanding of the solution. This will give an opportunity to discuss it with the product owner and with the team, and to improve it if needed.
By the way, wireframes are a good supplement for the Use Cases, they allow a great transparency for the solution and for the anticipated workflow. So initially Use Cases would work as a description of the engaging process and the ways of interaction that are available for the end-users. I would also advise checking out the ‘UX importance’ article to get more insights on the wireframes and their utilization in Project Management. It also describes the importance of the intuitive user experience and here again Use Cases could help.
Additionally, Use Cases within the solution specification will be needed for the developers while working on the product creation. Therefore, you are going to take the spec, parse it into the functional units, take the relevant Use Cases and put them into the tasks for your team.
Spot #2 – Quality
Quality is extremely important for every product and this entity should be built in it in order to deliver a solution of a high quality and demand. And here is the next touch-point when we are going to refer to our Use Cases.
While panning quality (check out the ‘Quality in Projects‘ Article) we are to identify the areas and the approaches of the solution verification. Thus to check out the certain functionality we need to interact with it and to define whether it works as anticipated. Where to take the information about how it is expected to work? Definitely, from our Use Cases. They are describing the steps a user is going to undertake in order to engage with the product and to get the desired outcome from this interaction.
In some cases, especially when a spec is not very much detailed, we are drafting Use Cases individually for the verification procedure. This is an evident part of the quality assurance process – to check out the solution in all the ways a user could try to interact with it.
Once again, great design starts from the great user experience. And user experience comes together with the Use Cases. Therefore, the more intuitive and straightforward the interaction with the product is, the less probability it could be broken. QAs goal is to break the app for finding the vulnerable areas of the solution. And the less interaction ways a user has to get to the desired goal, the more robust the product will be. That is why it is extremely important to draft the accurate Use Cases.
Besides, in terms of the quality assurance, usually the product grows further, acquiring new functionality. The instant Use Cases will become a basis for the regression tests and general functionality verification. In this instance Use Cases could be utilized for the Test Scripts creation.
Spot #3 – Demo
Moving on, there are more opportunities for the Use Cases exploitation. When we come to the part of the solution demonstration, to facilitate the demo procedure, Use Cases could be a great basis for the demo scenarios.
Usually, we want to demo either a certain workflow, or a specific solution functionality. And here we come again to the workflow description and to out instantly drafted Use Cases. To apply them here in the demo part when we need to show a progress or an outcome, grab a Use Case or a couple that are relevant, build a model situation and move forward with the presentation. Very convenient, moreover, we already have all the workflow paths in our pocket.
Let me know if you exploit Use Cases in any other ways, I am curious.
How to Draft Use Cases?
And we have come to the point when we need to define how we can create the Use Cases efficiently. What way for the Use Case creation can we utilize?
For the development and verification processes the more specified the Use Case is the better. This will help to reduce the ambiguity of the situation where the app rider could finally get.
However, to proceed with it we initially need to draw a high-level action plan. We need this to capture an overall impression and an understanding of the solution workflow.
Roles
First of all, every solution is for users. Thus the instant step we are going to make when taking a pen, is to understand who the solution is for and what roles users may have. This will be the first move to start. Split the overall system into the user roles. This will help to define the number of actors we could have in the application.
Goals and Priorities
Once we have the roles on the plate, we are going to set up the goals for them and the priorities among them. So we need to know why we have this role; what a user can aim with a specific role; and what is the roles’ hierarchy.
For instance, this is an e-commerce solution. We have the user and admin roles. Admin is going to have more rights than a regular user.
The goals for the user are: to be able to register; to be able to complete the account information and save it in the system; capability to choose several products and put them to the cart; to be able to pay for the goods online and to complete the order.
The goals of the administrator could be to view the user information; to view the order information; to send notifications to the users.
Enter & Exit
When we have a list of roles, let’s think and define the entry points where a user can get into the application; and the gate points – where a user can exit the app. And this should be done for every role individually. Depends on the solution the roles could have many different paths to travel to the app and out of it.
Interaction and Boundaries
Define the roles’ interaction opportunities. If there are several optional use roles, we need to know if the roles could collaborate within the solution. And if they can, what are the ways of collaboration they may have. Also, if there any possibility of changing a role.
Along with the collaboration paths, we are to set up the boundaries among the roles and boundaries for available actions. In other words, we should also outline what users will not be allowed to do and what are the restrictions of the functionality.
Scenario
Now based on the information above we are moving on to compose the collaboration scenarios and the user workflows. Should this be a user, how could he / she enter the application; what actions could be available for him / her; how the user travels through the application pages and functionality. What are the ways of achieving the goals for this role. What options a user has to exit the application. This will become a cornerstone for the project specification, test cases and demo scenarios.
Do you use a different approach for drafting Use Cases? Let’s compare our methods.
Cheers!