I used to take pride in the fact that I was the type of person who would jump head first into a project and then make my way through challenges as they arose. While that approach has gotten me pretty far in my career in a short amount of time, I am at a point in my professional life where I can’t afford to rush into projects anymore. That’s where some of the more important principles of use cases come into play.

Use cases — defined as ‘a series of related interactions between a user (or more generally, an “actor”) and a system that enables the user to achieve a goal’¹ — generally are found in software and systems engineering projects. There is no one right way to write a use case but they all generally include the following:

• Name – A clear description of the use case.
• Brief Description – A short paragraph going into greater detail describing the use case.
• Actors – User(s) engaging in the activity described in the use case.
• Preconditions – Truths prior to when the use case begins.
• Basic Flow – The list of steps an actor needs to take to successfully accomplish the stated goal of the use case.
• Alternate Flows – Less common steps that could occur when the actor is working their way through the basic flow.
• Exceptions – Roadblocks that can interrupt the basic or alternation flows.
• Post Conditions – Truths when the use case concludes.

I was introduced to this line of thinking in the midst of my academic pursuits. One of my classes revolved around creating working prototypes for software, apps and websites. My first few forays into creating prototypes were largely directionless and unorganized. Once we were introduced to the idea of a use case and I started to build out features in my prototypes based off of those documents the proverbial light bulb went off.

While I have not been writing full use cases for everything I’m doing professionally now, I have started to co-opt those middle four bullet points: actors, preconditions, basic flow and alternate flow. I have branched outside of the realm of social media in my company and have spent more time working on creating landing pages, reviewing e-mails for campaigns, updating microsites, etc. Those four bullet points that I just referred to have helped me out big time when thinking through exactly who we are looking to target and what we are trying to establish.

Let’s apply those four elements to the creation of a brand new landing page.

• Actor – Individual looking to refinance.
• Preconditions – Actor is on our mailing list, has a current account with us and is eligible for refinance savings.
• Basic Flow – 1) System sends e-mail to Actor. 2) Actor opens e-mail and clicks on link. 3) System passes Actor through to customized landing page. 4) System displays custom phone number and messaging based on UTM info in e-mail link. 5) User fills out information on form and clicks submit. 6) System checks that all field have been filled int. 7) System displays thank you message.
• Alternate Flow – 5a) User utilizes click-to-call by clicking on phone number. 6) System uses installed software (e.g. Skype) to connect the call. Process picks up at Basic Flow step 7.

If I wanted to I’d be able to check all the boxes in the classic use case if I wanted to: Exception – User doesn’t have VoIP software installed, Post Conditions – Customer has started the refinance process, etc. but I like to focus on those middle four because they really help me have a solid plan heading into a project.

And it’s always great when a good plan comes together, right?

---

1) Shrivathsan, Michael. “Use Cases – Definition (Requirements Management Basics).” Product Management Insights. N.p., 19 Sept. 2009. Web. 14 July 2016.