Notes from Day 4 of UXLx 2018— Designing conversational UIs & Product roadmaps

Jan Toman
Product Unicorn
Published in
6 min readMay 26, 2018

The last day of UXLx and the last set of my workshops — Designing Conversational UIs and Product Roadmapping. TL;DR both of them were great. Actually, workshops and talks at UXLx are usually of very high quality and this year was no exception.

Designing Conversational UIs — Stacey Seronick

“When testing conversation, try to use EXACTLY same words for every participant. Even the slightest change can have a huge impact on answers.” — Stacey Seronick

Workshop summary

Amazing workshop extending information I learned at Tuesday’s workshop (Designing voice interfaces). Some information was mentioned again but the main focus was on research and working with insights from discovery research. I gained a lot of inspiration and I am really happy that we mentioned ethics several times when we were discussing future of conversational UI.

What do I want to remember

  • It’s even more important to understand users that will use our conversational UI.
  • MVP for chatbot needs to be different than for any other product. It’s needed to set good expectations of what it can do for an user. The better way to approach it is MLP (Minimal Loveable Product), however it’s needed to handle unexpected questions respectably.
  • We don’t speak same way we write. We don’t pronounce all words in the sentence, combine words, don’t say some words at all and huge part of our communication is non-verbal.
Simple conversion from text that was originally written for reading to text intended for listening does not work usually.
  • The common problem is that we don’t have all information from the user, so we need to say for them somehow.

“We are still only touching a surface of conversational UI.” — Stacey Seronick

  • Chatbots are relatively dumb, they can only give answers it has specifically been told to give.
  • When testing, observe body language and tone of voice, not just what is said. More than 90% of conversation is non-verbal and you need to catch how people react because you have to express it later only with words in conversational UI.
  • Observe if people feel comfortable with questions of your conversational UI.
Workshop activity helping with processing observations from research.
  • Consider if chatbot is the best possible solution when people need to solve something where they are emotionally involved. There is a big group of people who just want to pick up a phone and talk with the real person on the other side of the line.
  • A lot of conversational UIs is requested by management mostly because it's trendy and cool. Be aware of confirmation bias when presenting your research insights — stakeholders will look for answers they like and why to build something even if it does not have to make much sense.
  • Framing can help with leading conversations in way you intended to.
  • When testing, it can be good to give your “voice” also some face. It can be something very simple, like drawing a face on a paper or plush toy. Just be careful not to choose some very common character because people have already their associations with them (“oh, I love Simba, this conversation will be fun”).

More of my notes on conversation UI from a second UXLx day

Resources

  • [book] Designing Voice Interfaces from Cathy Pearl
  • [tool] Twine — Great for prototyping conversations and mid-stage user testing. Great for testing intents and some specific language. Originally intended for text-based games.
  • [tool] Dialogflow
  • [tool] Mural — Digital whiteboarding, great for early research.

Product Roadmapping — Bruce McCarthy

“Roadmapping is a team effort, it’s not created only by product managers. Role of product manager here is to be a facilitator of conversations that lead to the roadmap.” — Bruce McCarthy

Workshop summary

It’s good to see that product management related topics are more and more common at the UX conferences. The workshop itself was excellent; a huge amount of useful information, lot of examples of roadmaps of other companies and great recommendations. However, I would consider the full day slot for covering all the topics connected to roadmaps.

Things to remember

  • The roadmap should not overcommit to the details, it’s not possible to deliver them in the long-term. The roadmap is more about making clear what the direction is and provide guidance and common focus.
  • There is no “one perfect template” for roadmaps.

“Roadmap is a strategic communication tool.” — Bruce McCarthy

  • Product managers and UX designers should not try to answer the question “Are we on track?”. They should refer them to project managers or tech leads.
Roadmap is more top-level view for what's coming. Detailed information should be provided with project plan.
  • It’s totally ok for product roadmaps to be more abstract and not directly connected to Jira tickets.
  • Don’t overdefine the problems with adding too much information about “how”. You don’t want to limit creativity of your team when looking for solutions.
Every roadmap should have 5 primary components: product vision, business objectives, timeframes, themes & disclaimer.
  • A product vision is how a specific customer will benefit from the product when it’s fully realized.
A product vision should be customer focused, not business focused.
  • Timeframes should be as broad as possible. Usually just “Now”, “Next” and “Later” can be enough. But if date is necessary because something on roadmap is related to a sport event, tech conference, eg.), consider adding “external event”. The goal of external event note is to inform stakeholders that you know about it and your roadmap considered it.
How far out should your roadmap go?
  • A disclaimer protects you from accusations of broken promises; it also protects your customer by making it clear that change is possible, even likely.

“GANTT is just an attempt to predict things that are unknown at the moment. We are not good in guessing what will happen; we should stop trying.” — Bruce McCarthy

  • There is a lot of secondary components that can be added to roadmap, for example features (connected to themes), confidence (how sure we are about something), target customers (which problem a theme solves) or status (in what stage a theme currently is), etc.
Possible secondary components.
Microsoft Office roadmap groups themes by status. Interesting choice to add status “Cancelled” though. 👌
  • It's possible to add secondary components into your roadmap, if needed. But it’s important that everybody sees same primary components, secondary components should help clear some things for more specific types of stakeholders.
Prioritization frameworks.
  • Interesting scale for ROI prioritization can be the scale from -2 to +2. Zero in this scale means that it does not support either damage the objective.

Resources

--

--

Jan Toman
Product Unicorn

I am UXer who enjoys product management and design systems.