Vision

Our company had decided to upgrade our products due to lagging performance. After 6 months, a demoable build of our flagship product was ready. Management was very happy with the evolution of the product. They asked me to lead an effort in bringing the other applications up to speed: or as I interpreted their request for them -- develop a standard design language for the next generation of Mirth products.

I took their request, and embedded my own user centered agenda in the middle of it. I wanted to push the company out of the “UX Dark Ages” and towards the UX tipping point. I dreamed of a Mirth where designers, developers, and management all understood and empathized for their users. Zest was my quest to achieve that goal.

Strategy

NextGen (Mirth’s parent company) had previously attempted a top-down approach to spreading human-centered design through a new VP of Design. She started at the top, working with the CTO and high level product management. Ultimately, a difference in beliefs left the endeavor fruitless.

Our NextGen Go project proved to be a semi-successful attempt at bottom-up design evangelism. By conducting user research first, we were able to understand actual users and how they conduct their work. Early prototypes gained support from clients, marketing, and management. We had created a desirable new product that the sales team was drooling over. Teams from all over the company wanted to get their hands on our magic process for creating useful and desirable products. In the end, we learned that closer engagement with both development and upper management was crucial for success.

I led Zest through a hybrid approach to design-thinking evangelism: rooting the design team in both upper management and individual development teams.

The design team gained support of upper management by proving the usefulness of usability testing and user research. Testing uncovered costly mistakes in existing products that were easily avoidable with proper. Testing also proved useful in providing clear direction for short term improvement. As traction gained, the design team will encouraged upper management to question and understand the “why” behind user feedback through the use of user research. I treaded lightly, trying to get the management team to challenge their own assumptions instead of directly challenging them head on.

“Make them think it was their idea.”

I led the Zest team to also embed themselves in individual Mirth products to help spread “Zestful” design principles. Designers worked with developers, encouraging them to think about the “who,” “what”, and the “why” behind their projects. From there, designers and developers applied the Zest UI Framework to their respective projects. I knew we had achieved some level of success when the developers argued about the preferences of their persona amongst themselves.

UX Team Structure

Our small design team had to cover a lot of ground with 7 applications looking to the Zest framework, as well as concurrently working on the flagship application. I chose a matrix structure to cover the most ground with the fewest resources. A single designer would work with a different product team and guide that team through their process. Some eager teams were led to create their own wireframes. The designer would review those mockups with them weekly.

Designers also belonged to the greater design team. I organized a weekly meeting where we collectively discussed the current designs of each project and the needs of which that fell outside of existing Zest guidelines.

Iteration

As with any process design process, we would iterate on components, collecting feedback from product and development teams. I ran usability tests on components, convenience sampling when core usability was the focus. Clients were recruited when the focus was on validating intent.

Design

I contributed to the generation of hi-fidelity comps for some of the components, layouts, and features that existed outside the standard guidelines.

Documentation

Lastly, the UI Kit was documented in a style guide for developers. I organized the style guide, initially opting for a shared Google Doc in the early stages of the framework to rapidly increase visibility. The style guide was eventually implemented as a living style on an internal server. The design team would work with each development team to make sure they understood the components and how they should be used.