When I started my career decades ago as a junior analyst, much of my job was writing functional specifications. These were extremely detailed documents that attempted to explain how a particular screen, program, or report should work, often down to the level of spelling out the text of each button and describing each dialog box that should appear.
Even at its most persnickety, functional specifications were often difficult for application developers to understand since a critical nuance might be missed. The author of the specification might spend several paragraphs describing how a dialog box should look but might omit a key detail about how the user would interact with the system, and thus cause the developer to create a less-than-ideal screen through no fault of their own.
SEE: Job description – Social media analyst (Tech Pro Research)
To avoid these conflicts, there’s been a transition away from functional specifications as the key communication to developers and a move toward tools like use cases, user stories, and other tools that attempt to explain the “why” of how a user will interact with the system, rather than detailing the features of each button. The thinking goes that this shift allows the people interacting with end users to focus on what interactions they need and then convey this to the technicians who have some leeway in determining the best technical means to deliver that interaction. This approach can be wildly successful; however, there are some potential stumbling blocks.
Is it the right use case?
Considering use cases can be a fun problem. It often requires a deeper understanding of the end user, gleaned through interviews or even observational research, and provides the analyst some freedom to interpret how to make that person more effective in their jobs. Preparing a use case even requires some creative writing skills since you need to interpret and convey those circumstances to the developer that’s ultimately building the system.
Occasionally this encourages analysts and leaders to create use cases before considering whether they’re the right use cases. It’s easy to shortchange the critical process of determining, which technology is appropriate to solve that user’s problems, or even whether a technology-based solution to a problem is the right approach.
Use cases require user-focused developers
The best use case in the world will fall completely flat if your developers lack the skills to understand the end users’ environment, mindset, and challenges. If a use case painstakingly explains a new system for a hospital and the challenges of working in an emergency room, but the development team lacks the context or empathy to attempt to understand the users’ environment, all of that extra work will be for naught.
As IT leaders, we should assume that our technical team readily understands every nuance of a use case, especially if they’re thousands of miles away. Furthermore, if you as the leader fail to emphasize the importance of fully understanding and implementing the content of the use case, you’ll see little return for the extra work that’s required to develop a good use case.
SEE: Job description: Ecommerce tech analyst (Tech Pro Research)
A functional specification by another name
Done well, a use case conveys to the technical team why an end user performs a certain task and even the circumstances under which they’re performing it, allowing the technicians to optimize for that particular scenario. Something as simple as an expense management tool could be very different if the user story suggests that the end user furiously tries to capture their expenses on their phone each week while running through airports, versus an activity that’s occasionally performed on a 24ʺ desktop monitor.
Done poorly, a use case is a hodgepodge of technical requirements like which fields to display and which buttons do what, without that overarching context, and effectively an old school functional specification by another name. An unfamiliar person should be able to pick up a well-done use case and picture the end user, his or her environment, and the how and why of what they’re trying to accomplish, and use that as the basis for what they’re building.
Don’t forget use case when it’s testing time
Even with the best use case and well-executed development, the work is not yet done. Use cases should also form the basis for your testing, both early-stage, and pre-release testing. As a well-done use case ultimately serves as the “voice of the end user,” it can inform even the earliest attempts at testing, and developers should be held to the standard of developing not only technically functional code but meet the needs articulated in the use case. In later stages of testing, the use case can also validate that the application has not strayed too far from its original intent or a sanity check to ensure that end users’ needs haven’t evolved dramatically since the use case was first created.
Well-done use cases take time to create, but ultimately help your organization deliver technology that meets user needs from the get-go, avoiding the deadliest sin of an IT leader: Deploying a technology on-time and on-budget that no one actually uses.
Image: Traimak_Ivan, Getty Images/iStockphoto