What's the best way to "hand off" design?
Do you think the concept of a hand-off (like a UI spec implemented by an engineering team) makes sense for conversation design? If so, do "static" materials like scripts and tree diagrams work well or is something more sophisticated and dynamic required?
I think this question gets at some even deeper issues, namely: how do designers get their “true” designs built the way they envision, and how do we empower software engineers to build the design efficiently and creatively?
Obviously this applies to any type of software design, but conversation design has its own nuances. We absolutely need an effective way for designers to communicate accurately to engineers.
Within this, there are different philosophies as to how detailed the designs should be. Should designers get all the way into pseudo-code—capturing the logic, the places backend calls are needed, etc? Or should the designers focus at a higher level and let the engineers fill in the gaps?
The thing is, conversation design requires designers to go deep into logic. The user might hear only one prompt—but there were ten different paths to decide which prompt to play. (Has the user been here before? What was the prompt just played? Will there be a follow-up question?) Therefore, there has to be an effective way for designers to specify this accurately.
Before I get into more specific recommendations, I want to emphasize that ideally, it’s not a strict handoff. That is, if your designers go off and create a design, then throw it over the fence to the engineers, there will be trouble. Why? Because designers often don’t have all the knowledge of backend constraints, or how long certain features will take to implement. Sometimes a flow will seem easy and straightforward to a designer, but during development, the engineers have to inform the team “sorry, that’ll actually take three weeks”.
So step one: get your designers and engineers talking early! Write sample dialogs, discuss data needs, and review them together. Engineers should point out potential issues as early as possible, so designers can work around them (rather than a panicked engineer suddenly have to write a filler prompt at the midnight hour).
There should be periodic reviews of the design throughout the process as well. (Note to designers: don’t just send the engineers a spec and say “let me know if you have any questions”. Walk them through it, pointing out complexities and asking questions. You’re a team!)
Now, on to the actual question: what are the best design artifacts to be used?
As usual, there’s no one right answer to this. It depends on your team and the complexity of the design. It depends on your toolset. Some companies have internal content management systems, or other processes in place. There are also external design tools such as Voiceflow, Botsociety, and Voxable. Some design tools export artifacts engineers can use (including code), some do not.
Sample dialogs, flow diagrams, and detailed design specification docs are all very common for representing designs. Spreadsheets to capture prompt lists can be helpful. The main thing is to find a set of documents/tools that can capture all the information—prompts, flows, logic—that can be easily shared and understood, and used in a standardized manner.
You’ll also need a way to include multimodal aspects, if you’re designing for a device that includes a screen. Some tools allow you to import visual assets from Figma, Sketch, etc. Ideally, these design elements are presented together, not as separate pieces.
(Note to engineers: during development, if you have a question about the design—ask! Designers will always appreciate being asked for clarification, or being notified if something won’t be able to be built as expected, so they can create a workaround.)
So, a resounding yes: there should absolutely be design/UI artifacts that a designer hands off to the engineering team. There is no absolute rule on the format, but typically sample dialogs, flows, and a place to put in design details (error behavior, if/then logic, etc) are needed, as well as a place to specify/link to screen design elements.
Finally, try not to have a wall between your designers and engineers. The more they trust each other and work together, the more seamlessly the process will go, and ultimately, the better the experience for the user.