I found many companies still have barriers between the developers and customers. Although they are often working to break these down, institutional change is usually slow. The more people in the way, the more chance the 'why' is lost and the problem is not addressed.
I wanted to come up with a way to connect the developers with the concerns of the customer irrespective of how removed they were. Collaborating with Dan Rushton, we started to think about conversations that would help make that connection.
All the way through this, I had Melissa Perri's excellent phrase 'Problems not features' ringing through my ears. I wanted to expose the problem we were trying to solve for the customer.
We eventually came up with a concept where we imagined the developer overhearing support calls in a call centre. We saw this as the primary interface for many customers with the companies that provided them with services. We also felt that this would be how a company would get most of it's feedback about it's service.
We thought that overhearing the customer explain the problem they were experiencing would provide excellent context for the developer to better understand why we were building something to solve that problem.
Our first thought was to simply role play a conversation but felt that this would not involve the whole team and could make people feel awkward. We wanted it to revolve around a conversation that was focused but also collaborative.
We then started to think of a storyboard that we could create to convey a conversation. Knowing people can be a bit funny about drawing in groups (unless you work with creative types of course who usually ask for more art materials), we came up with the a neat idea that we called a Situation Card.
The Situation Card is a bounded box and contains a single character in the form of a stick man. A simple conversation needs only 2 types of Situation card - one for the customer and one for the call centre member of staff. More complex conversations can use more types of cards - we created ones for people doing surveys, developers working at their workstation, people on their mobile phone etc.
The character is in one corner and has no face allowing the team to add speech bubbles, thought bubbles, facial expressions etc to convey the content of the conversation.
We found A5 was a nice size. Laminating them means you could re-use them. Here is an example of a Situation Card for a person on a mobile phone:
The conversation is told through a series of Situation cards laid out like in a line or columns like a comic book or story board. You can limit the amount of cards so that the conversation is short and concise - you can also refine or refactor pretty easily since cards can be removed and rewritten easily.
The idea is to tell a story and link the problem the customer has with the feature of your product that solves that problem. In telling the story you can use cues like 'If you could hold the line, I just need to check with my manager' to stimulate conversation in the team and check facts or confirm understanding before continuing the conversation.
The conversation can start off as a complaint and then be refactored to a support call, where there is a happy ending since we have the perfect feature to the solve the customers problem. The process of creating the conversation allows the team to better understand the role of the feature. We also think it could be a good way of exploring if a feature does what we think it does, although we have not tried that yet.
In the experiments we have had so far, we found this useful for connecting the problems of the customer with an unseen bit of infrastructure or service which has no interface as such but still has a part to play in the service being provided.
Still a work in progress, I will post up some examples as soon as I can.
