Use cases in the Fluid Project Erin Yu, Interaction Designer, The Fluid Project Allison Bloodworth, Interaction Designer, The Fluid project

Our Context - The Fluid Project Very large scope - content management Trying to design general components which will work across projects instead of for a specific context Multiple teams in different locations with different levels of experience doing the work Created our models in a distributed fashion Our large scope made us do things ‘backwards’ in a sense, as we were not able to focus on a specific context. Resulted in a lot of information to process. Talk briefly about challenges creating models in a distributed fashion

User-centered design at Berkeley User research Modeling Requirements definition UI framework definition UI design Development support

How do we define use cases? High-level descriptions of how users: Currently use the system Need/want to use the system Their goals The context Gathered during user research Use cases separate functionality into logical, manageable chunks Current use cases don’t get into analysis or design our use cases are more user-focused that traditional use cases, which are equally user and system focused. Our use cases weren’t as enumerated in great detail, as some use cases are, due to the large number of them.This could be done later for the use cases important to our designs. Determining how the users need to use the system requires on some analysis on our part, and is not necessarily based on what they tell us they need. System use cases represent patterns of use cases we see among individuals.

Other definitions "Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful.” - Bittner and Spence “A sequence of actions that takes place in a problem domain between a user and the system.” - Menlo Institute This seems to be equally focused on the user and the system

Step 1: Research - Contextual Inquiries Interviewed & observed users in the context of their work Used focus structure document to guide each user visit Took detailed notes & photos Processed ‘raw’ notes into a more categorized & synthesized format Processed notes included lists of use cases, but we also reviewed the entire document for additional use cases. [could add screenshot of a processed notes page - ensuring there is no personal information]

Step 2: Deriving use cases Part of the Modeling phase Levels: Motivation, Goal, Need, Task Reviewed processed notes to find high- level activities users are performing A use case is usually made up of smaller tasks Described each use case in a simple sentence (the “title”) Mention Personas are also part of the modeling phase When reviewing notes, look for nouns and verbs to find actors & use cases Talk about the different levels in the context of getting to work. Motivation: security, happiness, being respected Goal: Get to work on time Need: A way to get to work: use the car Tasks: Get in your car, start the car, back out of your driveway, take I-80 south to the University Ave exit

Use case lessons learned Finding the appropriate granularity is hard Try not to define solutions Make them specific enough that you and the rest of the team can understand them later Tie them to user goals e.g.“Read course announcements,” “Collaboratively create a lab report with other students” Examples “Read course announcements” to ensure you are up-to-date on all the requirements for class. “Collaboratively create a lab report with other students” because that is one of the class assignments. Something like “print out syllabus” was not specific enough.

Use case example Use case title: Grade student assignments Goal: Assess student’s understanding of course material and provide feedback Collect student assignments Review and mark up each assignment Enter grades in Gradebook On our post-its the use cases were only represented by the ‘title.’ If the goal was not obvious, we ended up having to add it to the post-it note later. Sometimes goals are easy to infer, but we learned it was best to write it out if it was not. Each of these tasks may have smaller sub-tasks beneath it. Looking at the tasks being performed, you can think about whether this use case represents the most efficient way to accomplish the user’s goal.

Step 3: Creating post-it notes Use case ‘title’ in big letters Different color post-it notes represented current vs. future use cases Colored dots represented the user role Users’ initials in small letters Upload marked assignments MB Could be multiple user initials on the same post-it, or because many different people were creating the post-its by themselves, sometimes post-its had the same or very similar descriptions and were stacked on top of each other.

Step 4: Affinity diagramming Grouped use cases based on similarity or relatedness Similar to card sorting Because we had so many use cases, we came up with categories as an initial organizing scheme e.g. Authoring, Presentation, File Organization, Communication Placed post-it notes onto category sheets

Step 5: Affinity diagramming Placed duplicates on top of each other Found patterns Within each category, we organized post-it notes into groups Named the groups Ideally we would do more abstraction and synthesis to determine which of our use cases were the high-level ones we really want to target, and which are more task-oriented steps necessary to achieve the goal. Since our problem space is so large, we probably will not have time to do this for all of the groups, but likely will do this more in-depth analysis for those related to any components we decide to build.

Step 6: Use-case frequency matrix Types of users on one axis Use cases on the other axis Instead of X’s, you can also indicate frequency, e.g. daily, weekly, monthly, each semester, yearly, never, etc. Can see frequency of activity across user type (ideally we’d map this to personas, but have not yet finished our personas)

Step 7: Priority matrix Frequency Importance Frequency of occurrence goes up the Y and starts low going high. Importance of the use case starts low and gets higher as you go to the right.  So the top right would be highest importance and highest frequency. The colors of post-its indicated various categories of functionality -- assessment, communication, site management, etc. We would make these for each of the components -- with the use cases that map to them in order to help decide which use cases it is most important to support. Can also map difficulty on a matrix like this. A use case relationship matrix can be used to show which use cases use or are used by other use cases Frequency Importance

Step 8: Activity Diagrams Activity diagrams are used to map out task flows through more complex use cases (what the user has to do to complete an activity/use case). Activity diagrams are like flowcharts. They include decisions users have to make and try to capture their cognitive load. They can be used figure out how we better support users’ needs in the system.   What do they have to do manually that might be better automated?   Are there places they have to keep in memory and the system could actually keep track of that for them?

Step 9: Requirements Definition Use matrices to prioritize use cases Are there frequent/important use cases that can be addressed by Fluid components? Is there overlap between frequent/ important use cases & pain points found in an earlier analysis? Validate choice of some upcoming Fluid components Fill in roadmap for future Fluid components Requirements are in a sense “an ongoing conversation about what the business needs and when the business needs it.” - Menlo Institute Using use cases to pick Fluid components The collected use cases are all in a sense requirements, but we can’t address them all with our time and resources so we have to pick the ones we think will be most helpful to our communities.

Next steps User research Modeling Requirements definition UI framework definition UI design Development support Information on this process was covered in the previous personas presentation.