How do you communicate a complicated idea? Do you break out diagrams and power-points? I usually do. What happens all too often, though, is that the idea ends up understood in fragments. And while key points may come across, people end up with different understandings of what connects those key points or their details.
These and other problems led to Kedron and I trying something new in a recent client meeting — storytelling.
While working on the design of an app, we found ourselves in a situation where our thinking about the app and its features had diverged from what our client originally had in mind. We’d started from our shared understanding, then unpacked the ecosystem in which the app would be used, and things shifted from there. Whereas our client was envisioning a stand-alone iPad app that would be used to create documents, we were envisioning a service-based app with a web component.
We needed to get back in sync with the client before moving on, both to test our assumptions and to set their expectations on what we were planning to produce. But how to do it? Confronting our customer with a detailed technical picture of what we had in mind could fail to communicate why our thinking had diverged from theirs or, worse, lose them in a cloud of technical jargon and buzzwords.
The approach we decided on was a story. With a story, we could relate our proposed features to the customer’s needs and motivations. We could communicate the user’s actions at the level of intent without getting bogged down in technical details. We could craft a plausible story starting from app discovery, segueing through user buy-in and purchase, into what the user might do with the app and why they’re doing it.
I wrote my first short story of my career featuring our user personas, and Kedron drew pictures to go along with it. Our story told of how our user first heard of the app, what she did to learn more information about it, and why she decided to download it. We explored how the app introduced itself to her and how she started using it. We introduced other personas as necessary to flesh out the story, ending up with an end-to-end picture of how we thought the app and its supporting ecosystem could work.
This approach ended up working very well. We were able to transfer our thinking about the app to the client with ease. Not much is more natural than listening to a narrative about people, emotions, motivations, and actions. Had the story not been one our client would like to tell after the app was launched, it would have been immediately obvious.
Our story mostly hit the mark, but even so there were places where our understanding of the domain and users’ motivations was a bit off. Our client pointed out the parts where the story didn’t ring true, and we updated them to more accurately reflect their expert knowledge of the domain.
Further, the story focused on intentions and motivations, not actions anchored in user interface designs or widgets. Not once did the story use the words “click”, “tap” or “swipe” – instead the user searched google, shared content, and demoed functionality. Whereas conversations around a concretes can degrade into quibbles about design and language, our conversations were about motivations and the aptness of our metaphors.
After getting buy-in of the story, we were able to explain how making it come true would require building additional technical and marketing infrastructure for the app, which would take longer to develop. The client saw how the new pieces would enable different parts of the story and that, without them, parts of the story couldn’t come true.
Overall, I think the approach was a huge success. The next time I need to communicate something complex, I’ll definitely be thinking about whether a good story might be the best way to get the point across.