Once Upon a Time…

We all know that a picture is supposedly worth 1,000 words. As an employee at a firm that specializes in visualization, I’ve seen first-hand how modeling systems with stakeholders can build clarity, reduce errors, and increase the likelihood that the systems that ultimately get built are those the stakeholders thought they had described. This week, though, I’ve been reminded that sometimes the thing worth 1,000 words is – well – 1,000 words.

My teammates and I are finishing up the pre-visualization phase of a major project (if you’re wondering what “pre-visualization” is, click here to read Robert Grashuis’s excellent description). Over the past six months, we’ve helped our client model nearly 400 workflows for a system that will serve hundreds of thousands of users. On Friday, we will deliver a rudimentary, working model of the system along with several hundreds of pages in written documentation.

But how do you make it easy to “consume” such a large system? I would suggest leveraging one of the oldest forms of human communication – storytelling. Stories hook us. We remember them. We understand them. We read them. And, in an age where the average executive is tasked with reading (or skimming) hundreds of pages daily, that is no small statement.

What do I mean by stories? Well, let’s start with what I don’t mean. I am not advocating the two- to three-sentence “user stories” the term probably conjures up for many of you. Nor am I talking about their more technical brother, the Use Case. These may have their place in system design/development, and several good articles have been written about the pros and cons of each (for some of the best, I suggest you check out this list of articles from the Practical Analyst).

The user stories I’d like to advocate are actual stories. They follow fictional (but realistic) users as those users interact with the system over time. They are populated by characters with names, histories, and lives away from their computers. You don’t have to write a novel, but we should get enough background to make the stories compelling, memorable, and easy for someone with no knowledge of the system to understand. For each story, I create a corresponding “map” that tells the reader how to drive through the model and take the same actions within the system that the stories’ characters take.

Why “waste” time writing these fictional accounts? This type of user story can serve several functions when used as a bridge between pre-visualization and the fully visualized system. Stories can:

  • Help identify gaps in the model early

Because you have to trace each action taken in the story to its location in the model, writing stories can help you find holes earlier than you may otherwise notice them. You’ll describe how a character reads an email sent to her through the system, and you’ll realize, “Oops! We included a workflow for WRITING an email, but we forgot to include the flow for VIEWING one.”

  • Validate the analysts’ understanding of business processes

Let’s face it – we’re analysts, not SMEs. The next time you THINK you understand how a process works in an organization, try writing a story about it. You may find it humbling. But, if you discover early where you’re confused about the organization’s workflow processes (Hmm- would it be the paralegal that does that? The clerk?), you can make sure to clarify those potential problem points early.

  • Demonstrate how multiple users interact with the system as a result of the same event

The great thing about user stories that are actual stories is that they can have multiple characters. Several different users may have to interact with the system before X change can occur. Narratives provide an easy way to describe all of these interactions in a fluid, cohesive manner.

  • Create a readily accessible way to communicate what the model does

If you’re trying to communicate a system’s features to its requirements team, this probably won’t be a problem. But what about to others in the entity? To outsiders – potential clients, investors, partners? Anyone can understand a well-written story, regardless of their baseline knowledge level (or complete lack thereof!).

  • Provide a roadmap for particularly large, unwieldy models

In my mind, this is one of the most compelling reasons to write fully mapped user stories. In the project I mentioned above, for example, we are delivering a model with nearly 400 unique scenarios. A user could start at the top of the list and click through each, but that would give the user very little context. S/he may (quite understandably) have a hard time keeping track of what s/he is looking at. The mapped stories allow a user to ground his or her navigation in realistic narratives about which scenarios users would actually click through, in what order, and for what purpose.

  • Breathe life into the purpose of the system

Let’s face it: when we can sink our teeth into a name, a history, a plot – even if it’s fictional and very basic – we’re more likely to remember what we’ve read. Think of art. It could be my lack of culture, but I find modern art much less satisfying than art that has an identifiable subject matter. I am drawn to the story implicit in Renoir’s La Lecture. What are those girls reading so intently? It’s hard to see the Mona Lisa without wondering what she’s smiling about. A Jackson Pollock, while interesting, lacks the human interest factor that so intrigues many of us. So, too, for systems. When the business stakeholders can picture “Flight Attendant Nicole” or “Architecture Student Keith” instead of faceless users, they’ll be more likely to remember why they’re building the system to begin with.

So, the next time you deliver a “picture” of a system to a client, why not try accompanying it with 1,000 words?

You must be logged in to post a comment