Architects and Builders: A Proxy for Designers and Developers
When I started Voxable and transitioned from typical web and mobile interface design to conversational design, I gained a new perspective about what it means to be a designer. Throughout my career, one of my greatest frustrations has been the consistent undervaluing of research and design in technology, especially new technology. I always advocate for user experience research and well-modelled, well-planned software. However, I frequently encounter resistance from companies’ internal stakeholders and product development teams who don’t see the value of investing in research and design processes despite solid evidence that those processes enable companies to grow more quickly as well as have better market positions and higher revenues.
Ultimately, developers have control over the product as they’re the ones who implement any wireframes, screens, or prototypes designers create. Their command over the final product establishes a power imbalance, especially in organizations that lack design and development maturity or are overly siloed. This imbalance made me realize I need to focus on designers’ relationship with developers. How could I reframe my work with developers to make it more impactful? How could I position my role as a designer in a way that conveyed how integral my contribution is to the product? That’s when I had a light-bulb idea for contextualizing the designer-developer relationship: you wouldn’t set out to build an exceptional house without an architect and you shouldn’t set out to build exceptional technology without a designer. And so my architect-builder mental model was born.
In the pursuit of building new things, design—especially in the tech industry—has often been an afterthought. Historically, those who build structures are the ones who lead planning as it’s incumbent on them to execute those plans. This is no different in the tech world as developers define the architecture of an application then build new products based on what’s doable without necessarily exploring alternative, potentially better options. Only recently with the success of startups like Slack and Airbnb, tech companies leading with strong, well-considered UX and design processes have begun to shift the perspective of how technology might be built and are giving design some of the attention and investment it deserves. However, it’s taken years for this progress to be made for web and mobile interfaces and it’s still relatively early days in the life of conversational interfaces. Now, I find myself back in the ring fighting for what I believe is the best way to build technology. Thankfully, at Voxable I have a partner by my side and he just happens to be a developer who understands the value of design. We want to exemplify how a successful designer-developer relationship functions—how I draft the blueprints and artifacts, he references those to begin assembling the product, and we collaborate frequently throughout the product build which results in highly-useful, intuitive software.
Think about the relationship between an architect and a builder. The architect creates plans and renderings for a structure based on a holistic view of what that structure could be considering factors such as budget, size, location, materials, why the structure is being built, who the structure is being built for, and so on. But those plans are not the actual structure, merely a representation of what the structure could be. The architect then hands over the plans to the builder who uses them to begin erecting the structure. However, even the most thoughtfully drafted plans need tweaking as the materials come together in the real world. When there is a challenge or limitation that prevents the builder from executing the plan to spec, the builder consults the architect to determine how the plan needs to change rather than proceeding to make a decision which could affect the plans in ways the builder may not have considered. This back and forth might happen numerous times throughout the building process, but ultimately should result in a sound, well-built structure both the architect and builder can take pride in. It is the symbiotic relationship between the architect and the builder that produces the best results.
Architecture and building, or design and development, are two different modes of thinking. It’s often easier for two people to embody these different modes of thinking, even in web technology. Design thinking is expansive—designers consider the business, users, and implementation of the product while generating ideas for how the components might work together. Conversational designers form principles around branding, user interaction, and information architecture. While developers have the responsibility to apply the principles to a viable interface, designers’ process of forming ideas and exploring what’s possible is extremely important to conceive better solutions. Because, quite simply, the unplanned or ill-planned interface will most likely end in frustration or failure.
Voxable’s CTO Matt and I have experienced a lot of success with our design and development approach which led us to create workshops and courses teaching others how we do what we do. Good conversational design happens when designers are able to lead a process that supports a healthy, collaborative relationship with developers. Here is an outline of how I work with developers to design conversational interfaces:
- Perform and communicate user research. Great products are built on a solid foundation of user research. Conversational designers must gather research about an interface’s underlying technology, interview users, and analyze data to inform their designs. I find it beneficial to include developers in early stages of research—especially user interviews—to help illustrate the scope of the problem and align everyone working on the project in a common goal.
- Get developer feedback on use cases. Developers’ input on use cases is vital for understanding the relative effort and technical challenges of any one problem. It's always difficult to estimate development work at such a high level, but developers' feedback is necessary to define what’s possible within the conversational interface platforms and ecosystems. It’s only by level-setting with developers that I’m able to fully understand the boundaries of the interface.
- Model users’ language to inform the natural language understanding (NLU). While conversational designers should not be solely responsible for the creation of the NLU model, they should understand how to identify intents and entities in the users’ language and be able to create an interaction model that supports the way the NLU will handle the information. Learning to identify intents and entities enables me to work with developers on the creation of the NLU model and have a deeper understanding for how developers will implement the interactions.
- Document and share artifacts with developers in a collaborative way. The primary conversational design artifacts are sample scripts and conversational flow diagrams. I recommend creating a conversational flow using a tool like Figma or Miro so developers can collaborate in real time and comment on the interaction design. By sharing my designs early and often, the developers and I can troubleshoot technical limitations more efficiently as many issues can be identified and addressed before development even begins.
- Help review and test the developed UI. Designers should review and test the UI as it’s being developed so they can provide feedback to developers and ensure there are no obvious usability issues. Usability testing is vital to prove out the interactions after they’re developed, but they can also be performed with the Wizard of Oz method prior to development. The Wizard of Oz method is especially useful when creating an entirely new conversational interface or when designing for a use case where data around the users’ language is difficult to gather during the research phase. Working alongside developers to test the UI pre- or post-development enables me to pinpoint areas of the conversation that need to be improved and how my designs can be refined with users in mind.
The foundation of most successful relationships is a balance of power and sense of equality between the parties. Just as architects have firmly established themselves as vital to building structures, designers must do the same to building technology. We must continue to challenge the software development status quo and insert ourselves into the process until the proof of our worth is undeniable. While I have less day-to-day struggle as I work alongside a developer who values research and design, I will continue to advocate for fellow designers in frustrating positions and educate those who are open to a new—and all evidence indicates better—approach.
