top of page
Component Team Ticket Flow Journey Map - 02_edited_edited.png
Improving Team Performance using UX

Using UX practices to improve workplace efficiency and happiness


The Problem
 

Our UI Components team was new, our component library was incomplete, and we didn't yet have a set of processes in place to efficiently respond to developer requests or designer needs.

 

We had a dedicated component developer and a UI designer for our new team.  We had 3 product teams to support, and an incomplete, new UI component library we'd pulled off the shelf, and no plan.

 

We had a lot of work to do. 

​

In a hurry?  Jump to the solution.

​

 

Role​

​

  • Team Lead

  • Lead UX Designer

  • User Research

  • Prototyping

  • Testing

​


My Contributions
 

I was a component designer on the team, and I facilitated the creation of an improved software development workflow that included better communication, better scheduling and estimation, and better overall satisfaction.

​

First Workflow

Our initial workflow was extremely chaotic, unreliable, and frustrating to everyone involved (and to several people that weren't involved, but should have been).

​

The reality was that our team started getting work before we'd had a chance to determine any workflow.  What I've diagrammed is the cobbled-together process that we ran in the early days while we handled the most critical tasks and took stock of what we really needed.

​

As the diagram shows, there was a lot of room for improvement.  Our team used the early results of interviews with developers, product owners, and designers, and made several changes to our team and to our workflow.

Pros

Cons

  • Quick!

​

  • Unpredictable

  • Lots of rework

  • Missed requirements

  • No work estimates

  • Poor quality

  • Developer stress

​

Component Team Ticket Flow Journey Map- 01.jpg

The first iteration of our company's UI component development Journey map.

Feedback and action items on our first workflow

After the interviews and analysis a few realities became apparent:

​

  1. We needed steps added to the JIRA workflow so our team could integrate into the existing software development flow.  This would enable better developer communication, allow automatic referencing of user stories and other critical documentation.

  2. We needed coding experts in charge of the component development and the components library codebase.  

  3. We needed designers to address the myriad complexities of component UI design (i.e. consistency, usability)

  4. The process needed additional workflow steps to allow for proper communication, validation, and review.

  5. We needed component documentation so developers knew how to properly implement and use the components.

Second Workflow

We instituted a number of immediate changes as a result of our initial efforts:

​

  • We integrated into the company's JIRA workflow.  This allowed our team to better communicate and schedule with the product team and their developers.

  • JIRA integration also allowed our team to begin tracking our work on a Kanban board.

  • We swapped our junior developer for a pair of architects.  They would own the UI framework's codebase and ensure the code quality remained high.

  • We formally put our product designers in charge of the component designs.  Before, developers were sometimes creating their own solutions due to deadlines or bottlenecks.

  • We added multiple workflow steps, including a requirements-gathering phase, a component design phase, a product integration phase, and more rigorous testing and code quality improvements.

  • We started a bi-monthly meeting with the component team, the designers, and the developers to ensure we were catching all of the feedback from the developers.

  • We created an Component API reference using Storybook.

Pros
 

Cons
 

  • Higher output quality

  • More predictable timelines

​

  • Longer turnaround time

  • QA department could not participate due to resource constraints

  • Designers had trouble ensuring design consistency with other components

​

Component Team Ticket Flow Journey Map - 02.jpg

The second iteration of our company's UI component development Journey map.

BIG_Component_Team_Workflow_Diagram_11.png

Diagram I made while devising the updated workflow.


Feedback and action items on our second workflow
 

We had much better success with our second workflow.  On the components team, we were better able to schedule work, provide estimates, and communicate status to the product teams.  Project managers got the peace of mind that came with increased visibility into the process.  

​

After a few months we re-evaluated where we were with our second process.  After a few discussions during our coordination meetings, and some one-on-one interviews, we came away with the following action items:

​

  • We needed more comprehensive design documentation so designers could make informed decisions about whether or not a new solution was required.

  • Product owners complained that the process added too much time to their already tight schedules.

  • The component testing process was slow and iterative, and took a lot of product developer time and involvement.

​


Final solution
 

The second workflow served our team well for over a year.  However, we still ran into the occasional schedule issue related to the duration of our component development cycle.  We also discovered that relying on product developer involvement for testing caused delays internally while they juggled the asks of their product teams and the components team.

​

Our solution was the following:

​

  • Build a content inventory of our UI components to identify gaps between our needs and capabilities.

  • Invest the time and effort to build UI components to close UX gaps.

  • Invest more time and effort into socializing design standards and capturing them in documentation.

  • Restrict new UI component development to critical needs only.  

​

This allowed us to eliminate most unscheduled delays caused by component needs at the expense of some up-front development.  The added emphasis on documentation also allowed our designers to have a complete design reference for each component, including how to use it, what it's for, platform varieties, and more.  We were still missing a QA resource, but we worked around that by utilizing their time when they were testing the products with our components integrated.

​

We still kept our longer workflow for bug fixes, improvements and for sporadic component development.  But investing the time to close those remaining gaps not only ended up largely solving the issues on the team, solutions like the expanded API and design documentation generated lasting benefits to productivity and happiness across the organization.

​

bottom of page