Illustrate Requirements with a Gnome Narrative

Over the years I have been approached by numerous people who have an idea for a great software application or website. Sometimes these are individuals that are looking to start a new business, sometimes they are the executive of the company I work for and sometimes that person is me.

I developed the Gnome Narrative method over time as a way to both limit the amount of time I spent defining and illustrating projects and as a way to communicate logical designs to non-technical decision makers. Gnome Narratives have slightly more details than a napkin drawing but not much more. Often the diagram can stand on it's own without much description.

I start the process of creating a Gnome Narrative by reviewing the project concept with the decision maker(s) and collect as many details as possible. I then work on decomposing the concept into three phases and filling in the blanks with research or follow up questions with the client.

The Diagram is often created in PowerPoint and is split into columns that represent the three phases. The columns usually represent the Input, Processing and Output. Within each column I include a high level flow diagram of the major use cases in the narrative related with arrows. Depending on the project, I may also include a bullet list of outcomes for each column.

Below is an example of a Gnome Narrative that I created for one of my projects to replace a file mapping and import module.

The original solution we were replacing had merged all three steps into one UI and code base. The result was something that was difficult to use and even more difficult to maintain. Once I drew out this narrative diagram and presented it to the client there was complete understanding of where the existing solution was not working and what we were going to build to replace it. 

I have found this method to be very effective at communicating high level designs to non-technical and technical audiences. It is structured but not too detailed so everyone can understand it and everyone will actually read it and refer to it.

You will know you were successful in creating a Gnome Narrative when executives start showing up to project meetings with the diagram. It is referred to regularly throughout a project as a type of map that indicates context for a conversation or an understanding of progress in completing the overall picture.

That said, this is not the only artifact I will create for a project and it is not the only artifact I will present to the client. This is the starting point that will guide me through the rest of the design process. I usually present a high level entity model diagram and wire frames that represent key concepts in the application along side the Gnome Narrative. These additional artifacts are more oriented towards the design of a solution and provide everyone with a high level picture of what is going to be built.

If the project progresses beyond the concept phase, I usually identify Use Case Summaries and wrap the artifacts into a document that includes many of the details that were verbalized in the concept phase of the project. The Use Case Summaries are then used for generating an estimate and become product backlog items.

I hope you find the Gnome Narrative as useful as I have. I welcome any comments or suggestions on how to make this method better.