The Dialog Method
A design method to prioritize functionalities through the constraints of a conversational user interface
In Short
Write down the dialog that the user is trying to have with your product. Staying text-only and creating the feeling of a natural and pleasant conversation are the constraints. They will force you and your team to prioritize on the key information and interaction possibilities. It will make you put content first.
It can be used to evaluate current products and to generate ideas for a well balanced information architecture.
Conversational interfaces are here to stay
The era of chat-based interfaces has come, with Facebook M, Magic, Operator, Meekan, Luka and many more. By definition, they can only expose a conversation-based interface. And the experience is promising; Human-like interaction and the complexity reduced to the minimum. It can feel purely magical.
A lot of discussion has been going on about the future of conversational interfaces. They are here to stay, that’s true.
But if we look deeper, it’s clear that conversational interfaces are only a solution for a very specific problem space. The development risk is huge, and the danger is real; if not done correctly, the interface will quickly feel annoying, repetitive and dumb. So it is likely, that while it might be a conceptual fit, it may not be a wise business decision for your company right now.
But we, as designers, can learn a lot through the limitations and challenges of a conversational interface.
The Dialog Method
The limitations and challenges of a conversational interface are quite similar to the high level constraints of a “classic” graphical interface.
- The user needs the right amount of information at the right time.
- The user needs to get to know what they can do and how they can do it.
Conversational interfaces are forced to accomplish this in a natural and simple fashion. They need to introduce themselves and clearly state what they can do, and what they expect from you.
Let’s assume you are in a discussion about the core functionalities of your product, the vision or just about adding a new feature. Wireframes or prototypes are shown where you slam some information onto the screen and put in some visual signifiers. But then the discussion can quickly drift away about the layout, the style or the interaction principle.
This is where it would be helpful to write down the dialog that the user is trying to have with the product. Having a conversation is something that all of us do in our daily lives, so there is a common understanding of how a pleasant dialog feels like.
Forcing your team to frame the dialog will reveal what is actually most important. You will realize when the dialog feels “off”. The discussion will then be about the information and interaction architecture, and only once that’s understood move on to the actual execution, style or layout.
It will force you and your team to ruthlessly prioritize what is important and what not.
Keep in Mind
This is not a general design rule. It probably works better for simple, rather than complex concepts. It will not generate the perfect solution. It will help you evaluate and prioritize functionalities and information architectures.
You should have a clear user story to start with. What is the user trying to accomplish in which context? The solutions will differ depending on the goal of your user story.
If used to evaluate the current state of a product, it’s important that it is done separately to what exists already. You want to have a fresh view on the problem.
It can also be used to prioritize from a set of functions and ideas, especially if a team can’t agree on the core functionalities.
For some teams it might help to write down a first draft of the dialog. Then you have something on which you can improve and there is no need for the team to imagine the conversation from a blank state.
Read it out loud to yourself and the team, to see how it feels. Then come back here and let me know your mileage — I know I’ve had a lot of fun applying this concept.
Thanks for reading! If you have additional thoughts, please let me know.
Written by Nikolas Klein, 03|2016
Thanks to Jürgen, Raphael, Jens and Christoph
