Use Cases, User Journeys and Understanding Your Enterprise

Use cases are contracts that focus on behaviours between stakeholders of a system. Often found in user interface design and software development, use cases are useful in almost any context which involves several stakeholders interacting with one another under a system.

One context that is often overlooked is in business. While not true for all businesses, most businesses will at most implement use cases as a tool in marketing. Often overlooked as common sense in understanding how your customer receives a product or service, this is where the exploration tends to end.

By learning and using use cases, innovative thinkers are introspectively examining their internal systems and processes to better understand not only their customers as a stakeholder but also their staff, suppliers and key partners.

When used correctly, Use Cases help document and communicate processes to stakeholders within a system, showing the intent of the 'actors'and different scenarios that play out as a result.

Cockburn, author of 'Writing Effective Use Cases', puts it best stating that -

Use cases are made up of a few concepts, however, Alistair Cockburn, writer of the book 'Writing Effective Use Cases'states they must all include -

• Scope - What is the system in the discussion?
• Level - How high-level or low-level is the goal?
• Primary Actor - Who has the goal?

Beyond the scope of defining in this logbook, but still commonplace throughout case study methods, you will find Other Actors, Stakeholders, Preconditions and Guarantees, Main Success Scenarios, and Extensions.

Use cases are best made up of text Cockburn argues. However, use cases can also be found visually; this is especially true in the context of UID (User Interface Designs) where designers will create 'User Journeys'.

'User Journeys' help show the flow of a user's experience within a product but are not to be confused with Use Cases. The primary difference between the two is the level of detail they present. Often 'U'er Journeys'include surface level details, what button the user should click, as opposed to a deep understanding of their needs and how it translates to why they are clicking it in the first place.

Cockburn explains through anecdotes and shares lessons he had learnt from Steve Adolph; a software development consultant describes using use cases to discover requirements rather than to document them, Adolph.

With the 'use cases first'approach, Adolph has innovated in his mentality of use cases. Not only does this approach provide value in encouraging problem solvers to explore undiscovered solutions, but it also evokes discussions around processes, and creates documentation of the agreed solution.

To solve a problem, the problem must first be defined in as much accuracy as possible. In the context of problem-solving within a system, this involves gathering requirements for the solution.

Within the process of requirements gathering, Kulak says use cases act as the centrepiece, and the interactions they illustrate form the basis of most of the requirements that must be documented.

Becoming aware of every moving part within a system or expected outcomes allows for an accurate solution to be designed and developed by those leading the solution.

A significant difference to be aware of in use cases is that there are inevitably going to be differences in how detailed a use case may be.

Some business and teams that do not suffer due to errors and misjudgements in the accuracy can often work with a basic, trimmed down 'essentials only'view of a use case. The use case may include a simple “if this then that” method where the steps within a process are documented sequentially.

Visual learners may work best in diagram form, where they sketch out the actors, systems, processes and link them together with short text labels describing the relationships that exist. These are especially effective for remote teams that look to collaborate on the use case without being in the same room.

Other teams that work on isolated issues with high risk may opt to spend longer assessing and discussing the problem, detailing heavily what steps occur and how errors are resolved along the way.

Both teams are using use cases correctly; there is no one size fits all.

As with any solution, it is for the judgement of the team leaders to decide on what levels of depth their use cases cover.

No matter what level you sit within a company, whether you are a sole trader or an employee, understanding your enterprise is key to achieving practical results and maximising performance.

By understanding the primary actor interactions within a business's system's, you can make informed decisions that take benefit from innovative thinking, adapting to how internal and external processes are managed.

• The initiator
• What preconditions are required
• How the initiation is begun
• Who is involved in the process Stakeholders)
• What can go wrong in the process
• How these errors are managed
• How the success of the process is assessed

All of this information is clearly displayed and digestible to anyone without prior knowledge of what a Use Case is, without the need to reverse engineer diagrams, and most importantly to those without any background knowledge on the stakeholders the system includes, further supporting Cockburn's claim of text being the best form of a Use Case.

The clear communication of information within an enterprise is the primary benefit of learning and embracing the tool that is Use Cases.