The development of internal tools have accumulated over the years within the company, to service strenuous and labor-intensive jobs. As the company shifted to productizing and making our tools available to external customers, the need to make them presentable and usable became vital, especially when paid for. This would require the UX team to help improve these tool experiences, ensuring we deliver value through our products and align in brand, experience, and design.
Preface
At the start of this project, none of the UX designers were familiar with any of the company's internal tools. These tools were primarily developed to perform jobs within the operations for bot building automation, sales calculations, live agent management, data analytics, and others within the company. Mostly, our team had been focused on customer-facing products like chat interface experiences for web desktop, native mobile, web mobile, and messaging channels. When the company pivoted its strategy to externalize its internal development tools, our team received the mandate to ensure they were in great form to be used by our clients. This required a surveying of all of our products. Here's what we found.
Identifying the problems
Dispersed tools in different business organizations within the same company for various needs: technical, business, sales, QA, etc.
Isolated development teams that built and designed tools to best serve their job needs: automated processes, communications, and workflows.
Each tool was developed in different code languages and web frameworks. In most instances, there was also duplicated code.
No UX or UI design support or resources for these tools.
Developers creating these tools have none to moderate competency and understanding of interface design; at the bare minimum, utilizing the appropriate components, but no holistic strategy.
Redundant tools, redundant functions, and too many tools are built, due to dispersed teams and no communication.
Interaction paradigms, patterns, components, and visual style, all vary in look and feel and are inconsistent, making all the products look different, off-brand, and not from the same company.
These tools are made available to external users and clients as self-serve apps, some of which will ultimately be productized and purchased as part of the company's public tool suite offering.
Our mission
To ensure unification and uniformity in our products, build a singular cohesive design system.
Implementing a shared component repository will streamline code and tools, make our products usable, and improve acquisition, adoption, and retention that leads to improved business.
Our methodologies driving action
This wasn't going to be a quick and easy task. We knew we had to instill a methodical approach to get to the finish line. It will require synergy and executing with multiple teams, expertise, and processes. Here's what we did.
Evaluate all tools: inventory all the patterns, controls, micro-interactions, user, and workflows.
Designate design resources to own each tool and ensure knowledge gathering of tool purpose, evaluation of interface, redesign, and execution.
Create a design system, ensuring parity support for all required components and workflows in the tools.
Choose technical framework to support and align with the tools.
Create a foundational research deck and story that outlines our activities, findings, goals, and courses of actions. Socialize our story to stakeholders and all product owners.
Work with the PMs and developers of each tool on an implementation plan. Ensure they understand the product strategy, impacts, and outcomes, and get their moral support to execute within their product ownership.
Prioritize, execute strategy, and implement into our products.
Product philosophies delivered by unified design
When clients use our products, we want them to have the best user experience. Our product philosophies needed to reflect our company's brand values through our products. A consistent and cohesive design system will deliver on the following philosophies below.
Integrity, professional, and trust: as an enterprise and professional services company, we position and pride ourselves on providing value and positive results, so our products need to reflect that through great design and tool performance.
Familiarity, consistency, and alignment: components and workflows look and feel the same from one tool to another and wouldn't require the user to relearn them.
Usable and intuitive: users don't need to second-guess how to do things, the system is easy and straightforward to use.
Streamlined, minimized, and integrated: eliminating redundancies and complexities will not require the user to use multiple tools, we will keep them in context and help them achieve their goals faster.
Technical considerations
The development team led the evaluations of tech opportunities that would best serve our design systems strategy. They researched and executed proof of concepts (POCs) to see which libraries were robust enough to handle our requirements. They explored CSS-based libraries like ReactStrap, Semantic UI React, and Grommet. They also looked at tech stack packages like: Radium, React Table, Babel, WebPack, Jest, and Storybook. They ultimately concluded that React Storybook was the clear winner, best suited for our needs. Here are the tech benefits.
Ease of using components in applications for users, and easy for developers to implement.
Shared-community and open-source library makes it easy for developers to contribute, use, and manage.
Granular self-contained components streamlines code, reduces redundancies, and prevents CSS collisions.
Changing in one place will automatically reflect in all the tools making maintenance and rolling out fast and easy.
Easy to enforce same look and feel across tools.
A bird's eye view into our tools
Evaluating all of our tools presented a lot of inconsistencies, usability issues, brand misalignment, and broken workflows. Below is a snapshot of some of our tools. As you can see, there are various treatments for: app headers, logo treatments, navigation, menus, text styles, buttons and icons, visual style, colors, etc. At a high-level, the tools don't appear to be from the same company as the look and feel is differentiated. Transitioning from one tool to another within a single workflow would only attribute to a disjointed experience for our users. You can click on each thumbnail to expand.
Defining our design language system
We created a Design Language System (DLS) XD document with usage rules, variable states, and interaction behaviors for each component. The DLS also included specs, properties, and assets, provided to the development team for implementation. The DLS was also shared with all of the designers, so they can use it as they are designing their system interfaces. Below are screenshots of some components from our DLS document. You can click on each thumbnail to expand.
React storybook becomes our single source of truth
Once we defined our design system, we begin to populate the React Storybook, working with the development team to define configuration options, responsiveness, and interaction behaviors.
Shared open-source and community-based component library
A list of our components is displayed, with an interactive preview of the component, and a properties panel that allows configuration options, automated testing, and other information about the component.
Component variables
The various states and permutations of a single component is encapsulated within each component folder, making it clear to the user the multiple options that would best be tailored to the contextual use case and designer needs. In this example, a dialog has many different permutations and states.
Accessibility automation
The storybook is able to automate accessibility checks for the individual component, giving designers guidance on how to optimize and ensure ADA compliancy. At times, a component may be configured, so this functionality helps to ensure appropriate guidelines are followed and met. The screenshot below displays how this particular component violates and passes accessibility compliance.
Testing automation
There are integrated criteria the development team will build into the storybook to ensure components comply with the interaction behaviors and heuristic rules. The screenshot below displays how this particular component passes the criteria.
How it all came together
There is now a sense of harmony and brand consistency in all of the tools in our product offering. We were able to provide a central hub to access the tools and ensure uniformity in all of the interfaces. As displayed in the screenshots below, there are now shared components like: navigation bar, logo, text, buttons, links, colors, menus and lists, tables, and icons. Just observing some of our products from a high-level displays an apparent improvement and professionalism. You can click on each thumbnail to expand.
Summary
Some tools were deemed redundant and were eliminated. Some functions were duplicative and eliminated or streamlined. Features were positioned appropriately in the right places. Some tools were integrated as functions of another tool. We did quite a major overhaul to simplify, minimize, and unify. We transitioned all varying code languages to React, eliminating duplicate code, and ensuring ease in maintenance and reuse across all tools for our developers. Designers now have templates to build their design from. Creating and updating tools will be efficient. One company, one brand, one voice, and one style.
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 DesignOps, detailed design, research, and human relations.
Comments