Visual & Interaction Designer

KognitoUI Case Study

product-library.jpg

The Problem

Developing a bespoke User Interface for every product in the Kognito portfolio, in the age of responsive design was rapidly becoming prohibitively expensive and causing a fractured brand experience.

Solution

KognitoUI, a responsive, content agnostic UI framework that could be shared across all products and only required product teams to define content and a product color scheme.

Key Results

  • 85% time savings on UI dev work per project
  • Modern visual style and uniform brand consistency
  • Fully responsive implementation

Context and Challenge

Previous UI Variants

Whenever we created a new product at Kognito we were re-inventing the UI from scratch. There were certain interaction patterns that our products shared, but the branding and general visual design was custom made each project. This created a number of problems and limitations.

User’s often had access to more than one product as part of their subscription, but individual products didn’t provide the same experience as their siblings. This led to confusion for users and an inconsistent brand presentation for the company.

In addition to inconsistency, having 20+ UI designs across our portfolio of products added up to major support headaches. Our Customer Support and Quality Assurance teams had to keep all the variations in their heads in order to respond to support tickets and new feature rollout.

To top it off, Design & Development teams had to re-invent the UI layer from scratch for each project. This was an incredibly expensive way to build products in which the features were nearly identical. Typically with a new product it was only the content and branding that needed to be unique.

Our current practice had such clear downsides that the goals of the Kognito UI (KUI) project were apparent:

  • Reduce designer/developer time required to ship products.
  • Improve and make consistent user experience across range of products.
  • Create a unified visual style across our product portfolio. In addition to providing a more consistent brand experience, this would allow for more modular use of content in the future.

Process

In order to design a UI system that could accommodate our entire portfolio, we needed to know the full range of features and interactions our products supported. I created a screenshot and written survey of our entire product portfolio (20+ products). This became the bedrock of future feature discussions, since we could clearly see which products would be impacted by feature prioritization or cuts.

Porting our entire portfolio to this new system was a great opportunity to make improvements to the products that hadn't been updated in years. I met with nearly every team in order to gather institutional knowledge: feedback on the efficacy/pain points of current features from the Customer Support team, requests from the Marketing/Sales teams to help them promote the products and the Executive team to ensure the new system supported broader company strategy. This process also helped to spread the word throughout the company about the big change that was underway and get buy-in from teams that would be directly impacted.

While meeting with all our internal teams the amount of knowledge and variety of perspectives they had individually about our users made it clear to me that we needed a feedback mechanism that was broader than the CEO and the Design team. I started a weekly meeting called the “UX Committee” to provide that. Each internal team sent a single representative to provide feedback as well as take information back to their own team about the progress we were making.

With internal research complete, I began collecting demographic, technology and behavior research about our users from other sources. The range of Kognito’s users is very broad, so in the interest of keeping focused I restricted my research to our two largest user segments (based on sales): Educators (Kindergarten through University) and Healthcare Professionals. This additional research came from a variety of sources, including Google Analytics, Industry Market Research reports and informal surveys of friends & family who met the criteria.

With a solid base of information about the problems, goals and users, it was finally time to start putting some potential solutions down on paper. I started with wireframes and user flows, as a way to both work very rapidly and keep stakeholders focused on interactions and the overall experience.With wireframes I was able to validate information hierarchies, and user flows through remote user testing (UserTesting.com and InVision). They also served as a tool to gather concrete feedback from Stakeholders, via the UX committee, on whether the direction was achieving their goals.

Example Wireframe & User Flow Documentation

Example wireframe & behavior flowchart demonstrating the logic behind the KUI video controls

After several iterations, and a great deal of feedback on the wireframes, I had the outlines of a system we could start prototyping. In collaboration with the Dev team, we determined the technical requirements of the system. It was important that the Dev team start exploring some of the technical architecture while I began work on the visual design. If there were major roadblocks that would affect design decisions, I could make adjustments as I went.

The visual design of the new system presented a new set of challenges, it was an opportunity to consolidate the branding of our library into a single visual language. The visual design had to be built from a single library of components and allow enough customization to still show off the branding of individual products. This phase was also when I approached the motion design of the new system, ensuring that the UI Choreography reinforced signifiers and didn’t confuse or overwhelm. User testing continued throughout the visual design phase as a central form of feedback in conjunction with weekly reviews by the UX Committee. The user tests were conducted with increasingly complex prototypes as the dev team’s work and mine came together.

Once the new system had been completed, it was time to integrate into the Production workflow. As the dev team had been building the new system, they had used existing products as the base to build upon. This gave us an excellent foundation of experience with which to train the Production team. We provided an initial draft of documentation for the new system, and then several rounds of revision as production really started to use it and found the gaps we had missed.

Solution

Finished design for the UI during our simulated conversations

KognitoUI provides a unified UI layer that was abstracted from the content of our individual products, and could be implemented with a fraction of the effort previously required. It provides limited branding customization, primarily restricted to colors, to ensure that the design language stays on brand for our company. This also allows for future design updates to propagate seamlessly across the entire portfolio without one-off updates.

A few examples of product branding as applied to the KUI system

Once the product colors are established, all that is left for the product team to do is write the copy and prepare the image assets they need for the features they use. There is no “UI implementation” task anymore. All product specific content is connected to KognitoUI with a custom JSON based markup system, which makes it easy to version control and tiny to download.

KognitoUI also implements a number of responsive design best practices, including: dynamic content anchoring, content truncation, and global scale adjustments based on physical screen size to account for different view distances and overall proportional relationships.

Conclusion

Overall the KognitoUI project was a measurable success, UI implementation time has gone down 85% per project. We have the ability to continue refining our UI system incrementally and all products that implemented it will automatically benefit from those updates. The most interesting part of the project was the formation of the UX committee. It worked very well because we kept it small (4-5 people). With such a small team it was possible to build consensus, without too much risk of “design by committee”. There was enough representation from various teams that the rest of the company was kept in the know.