Designer’s thoughts:

Leading a design workshop
Leading a design workshop

The pattern library is dear to me in a number of ways. I often call it “my baby.” I designed this tool to alleviate pain experienced by my own coworkers, many who I consider close friends, and in doing so was rewarded with a different kind of fulfillment than the satisfaction I feel when meeting the needs of business clients or retail consumers. It’s simple: this solution was designed to help the junior designers I manage and mentor, and the dev teams I work with on a daily basis. Doing something for your own people feels so good. 

Product vision:

The UI pattern library will serve designers, developers, quality assurance engineers, and corporate trainers by existing as a living representation of the Order Management user interface style guidelines. It will also serve end users (merchants and consumers) by making user applications more intuitive, homogenized, and familiar. It will feature the design principles that standardize and optimize UI patterns and explain when to use each element, and when not to. The pattern library will be a home for user personas, so designers can easily reference audience types. It will host and document the global CSS, HTML, and Javascript used in all web applications, so developers can quickly reference and implement any UI component. The product will be consistent with live releases, so the QA team can automate testing. It will be interactive and behave just like any other application, so pattern library users will gain experience with the actual workflows and interaction design present throughout the Order Management ecosystem.

Business goals:

A wide variety of buttons in use before the pattern library unified styles
A wide variety of buttons in use before the pattern library unified styles
  • Reduce need for UI-related user training
  • Reduce time spent creating wireframes and prototypes
  • Reduce time spent developing user interfaces
  • Simplify and reduce UI maintenance
  • Establish design standards for automated UI testing by QA team
  • Document design principles for new hires to learn

What problem does this product solve?

When I joined the Shopatron product team in 2013 as the second UX designer, there were many disparate user interfaces throughout the organization. At the time, most features were “designed by engineer” and the impact on usability, learning curve, and brand identity was devastating. Internal tools were in the worst shape, having received the least investment in the company’s 10-year history, but client-facing applications were nearly as bad. There were at least five different color schemes and navigation structures, with search and browse patterns behaving differently from tool to tool. More time was spent writing user guides that explain how to use the complex variety of interfaces than was actually spent creating cohesive user experiences. The QA team didn’t even try to test for accessibility or consistent visual standards.

A pattern library does three things for enterprise software organizations:

  1. Establishes consistent visual and interactive standards
  2. Provides referenceable, reusable UI elements
  3. Hosts maintainable code components

What did I contribute?

Whiteboard sketch of personas in the pattern library
Whiteboard sketch of personas in the pattern library
  • user research
  • product requirements
  • project management
  • information architecture
  • wireframe
  • prototype
  • usability test
  • visual design
  • design quality assurance

I saw an opportunity to optimize business practice and save money for the design and development teams. After writing the product vision, evangelizing the idea for a UI pattern library to executives was my first job. I demonstrated the way I’d configured my wireframe tools with pre-made UI objects, allowing me to create wireframes more quickly than other designers, and explained how the pattern library would become an equivalent time-saving, cost-reducing framework for front-end developers.

After receiving buy-in from the VP’s of product and engineering, I hosted a design workshop including myself, a junior designer, a senior product manager, the lead front-end developer, and a QA engineer. These stakeholders helped me develop profiles of people whose processes were improved by using the pattern library: fellow employees who would refer to a UI framework to add quality to their projects. I took notes during the workshop and uncovered use cases that answered who, when, where, and why the pattern library would be required. Next, I wrote copy for each UI component, including design principles, in-use examples, when and where to use each element, and documented exceptions to the rules. I reviewed the copy with each stakeholder and received feedback regarding the content.

Pattern library wireframe, version 1
Pattern library wireframe, version 1

I used UxPin to create a full set of interactive wireframes to test on my workshop team. I drafted a usability test and observed the results, adjusting the wireframes when tasks were not completed easily or quickly enough. Finally, once I was sure that designers could recite the style guidelines, sure that developers could find the source code for each element, and sure that the QA team knew what they should test for, I used JIRA to create a pattern library epic and tickets for each screen. It was with great joy that I handed the project off to front-end development and watched it come to life.

Version 1:

The initial release of the UI pattern library was true to the vision statement. Because of my design process – observing users with a problem, engaging them in a design workshop, validating the design through usability testing and further observation, the pattern library is now a released product within the Order Management ecosystem used by multiple audience types. It provides a consistent look and feel to a dozen different applications. “Designed by engineers” is no longer a phrase I fear, because as long as developers have the right content, the pattern library will guide them. The product meets several business goals, including employee process changes:

  • Decreased time spent wireframing (average estimate down from 6 days in 2014 to 2 days in 2016)
  • Increased time spent researching user behavior and validating solutions through usability testing and data analysis
  • Decreased time to develop user interfaces (average estimate down from 8 hours in 2014 to 3 hours in 2016)
  • Increased time for front-end development team to participate in architecting UI solutions
  • Decreased time to implement third-party, partner and system integrated interfaces while adhering to brand guidelines (down from 6 months in 2014 to 3 months in 2016)
  • Improved usability, learning curve, and consistent interactions and visual hierarchy
  • Order management user interface training guides have not been created since 2015

 

Viewing charts and design principles in the version 1 release

Process improvements

sprint-planning
Participating in sprint planning with the UI kanban board.

I didn’t stop with the pattern library. While researching process improvements for the UX and front-end teams, I uncovered much more than the need for a UI component host-and-reference service. Over the course of two weeks, I met with department directors from engineering, quality assurance, product management, and professional services. I asked a series of questions:

  1. When do you need to know the UX team’s availability and capacity?
  2. What information do you expect to be available regarding the UX team’s current projects?
  3. When do you need to know the front-end development team’s capacity?
  4. What information do you expect to be available regarding the front-end development team’s current projects?
  5. How would you use this information if you had it?
  6. Tell me how greater transparency from the UX team would positively affect your process.

The directors told me things like, “I would know how far ahead in advance I need to give you a heads-up when I want a wireframe”, “I want to know the results of the research you’re currently doing”, and “I want to know when senior designers are available to advise on client calls.”

In order to meet these needs, I created a kanban board in JIRA and called it “User Interface.” As long as a task is scheduled for a sprint, any ticket with the label “ui-board” or “wireframes” appears on this board in one of the following states: to-do, in-progress, review, or done.

Want a new user interface? Follow this process.

I also documented the sprint planning process for the user experience and front-end development teams in a swim lane diagram. There are lanes for teams: product management, user experience, engineering, and quality assurance. There are also process lanes: JIRA task tracking and review time. My diagram makes it crystal clear who should be doing what at any given time, and where to look to see the status of a design or development item.

Of all the utilities I’ve designed, this one flowchart is probably the most widely shared and the best received. One client called me an “angelic unicorn” for shedding light on the ticket lifecycle. I’m stunned at the effectiveness of this single visual to communicate best practices for getting new user interfaces developed. There was definitely a process vacuum before I began managing the UX team in 2016.

If I could spend more time assisting department leads in clarifying, optimizing, and documenting their team’s business processes, I would be a satisfied and happy lady indeed.

 

Want to know more about the UI pattern library? Read about the effort to rebrand it and many other user interfaces when Shopatron merged with Marketlive and Fiverun to form Kibo Software, Inc.

UI Pattern Library