A case study on how architectural frameworks, developer processes, industry tech lingo, and practitioner understanding can influence your Product UI content and terminologies. Let's take a deep-dive into how a tech-heavy workflow like deployment lifecycle was initially conveyed and how UX transformed the thinking into a suitable user-friendly mental model.
The problems
The bot building deployment lifecycle is tech environment-driven, using terms like: staging, stable, and production.
The bot building deployment lifecycle is initially used for bot developers to run various regression test activities: code differences, API checks, and logic validations.
The word 'deployment' is a standard technical terminology, that may not be easily understood by any other practitioner.
The product inherits these terms into the UI: buttons, tabs, referenced across the app, and instituted as part of the mental model/interaction paradigm.
The product reflects the exact architectural foundation.
Internal pod mates are very opinionated about the appropriate terminologies to be used in the UI. Some claim the tech terms are industry standards.
Internal pod mates claim to use tech terms as a means to teach users.
Our users are conversational designers.
Mission
To improve the communication of product functionality clearly and concisely to users, examine the user goals of the functionality and simplify terms to represent those user goals.
Process
We examined our backend infrastructure with our architectural and front end developers to get deep knowledge. We user tested and consulted with conversation designers. We ideated, role-played, integrated into our UI, had numerous work sessions and review cycles, and did industry and competitive landscape research.
Solutions
The Backend Infrastructure
The architectural framework represented environments (a location, phase, or state). Staging is where the bot building logic automation takes place and initial testing. The bot is limited at this point, since API's are not connected yet. When to bot is moved into Stable, APIs are now connected and the bot is fully functional to show our client's service data. Once the bot completes testing, it will be deployed to production, where it is live on the client's service, and consumers can interact with it.
Exploration 1
After further examination of the framework, the Stable environment was deemed unnecessary, so we eliminated it from the workflow and streamlined testing into Staging. We also decided to be more clear on what the different deployment phases meant to the user. We also moved towards a verb-action construct which can be easily understood by the user, providing objective to the button labels.
Exploration 2
The word 'test' traditionally conveyed more technical and rigorous examination, expecting proactive state, status, or result in return, running automated processes to check its health or condition. So we changed 'Test App' to 'Build App' since the expectation was only to view the bot and not actually to return testing info about it. We also changed 'Deploy App' to 'Go Live' since 'deploy' still conveyed a generalized term used even at the Staging phase, and was also technical term. 'Go Live' sounded more enthusiastic and provided a sense of excitement and accomplishment.
Final Design
After further usability testings and user consultations, it was deemed that 'Build App' still reflected what the system was doing and did not reflect the user's intention, so we changed it to 'Preview'. We also reduced the verb-noun construct to a single verb label for simplicity. We also changed 'Go Live' to 'Publish' to remain consistent with a single-word verb, and also inherited the term from industry-standards. Upon testing, this final design remained the most easily understood.
Result of user interface
Primary actions
Single action word attributes to clear, concise, and non-elongated button widths. The label represents that user's intention and goal:
"As a conversation designer, I want to preview my bot, so that I can see how the conversation flows and ensure the bot responses are reflected"
"As a conversation designer, I want to publish my bot, so that our customers can get their needs met."
Tab switcher and other components
Tabs are mapped to the primary action buttons so users understand what has taken place after an action is initiated and where to locate that bot version.
Additionally, the terms are used across multiple contexts in the system such as dialogs and notification banners.
Summary
Challenging the technical terminologies, testing with users, research, and design exploration helped to establish intuitive communications through simple and concise words. Taking your technical team along through journey helps them understand and empathize with our end-users, and will encourage optimization. Stay attentive to how users describe the actions, as ideas may come.
About the author
Sean Lazo is a Principal UX Designer at [24]7.ai who leads the inception, assembly, and design of [24]7.ai Conversations, an industry-leading omni-channel AI chatbot SAAS platform. His passions are DeignOps, detailed design, research, and human relations.
Comments