DesignOps

Uno Health
Senior Product Designer (Independent Contract)
Nov 2022 - Feb 2023
As a Product Design team of one, I set out to create a design system that can be used for all product initiatives. As Uno hires new designers, it is important for there to be a baseline process along with defined design components and patterns.

Goals Overview

The top 3 goals of this project are:
real_estate_agent
Creating a Solid Foundation for Growing a Design System
We set out to create the first precedent for a design process and system that can be updated as needed. This is especially valuable for future Product Designer hires.
verified
Increase consistency and expectation in the design process
Product Managers had different ideas of what a to expect from a Product Designer. This slowed down the speed of output for design and often led to misunderstandings.
emoji_objects
Opportunity to educate on the value and purpose of Product Design
Creating a better understanding of Product Design and how it brings value creates a more confident working environment for stakeholders who work directly with designers.

Priority

The prioritized deliverables break-down into 3 categories:
Since this is Uno's first step into building DesignOps, we decided to focus on 3 assets that will benefit the team immediately: Creating an MVP design process, defining design guidelines, and building current and ideal user flows​.

An assets we decided not to focus on with the first phase was building a component and pattern library since Uno does not have a desktop or mobile product that is end-user facing.

Solutions & Process

Here is a peek into how this project is coming along. It is important to note that building these assets are still in progress + I am learning as I go :)
Use tabs to see the process and result of all the priority areas.
Why Now?
foundation

No Precedent

There's was no defined process before we kicked-off this new initiative. Since there was a plan to hire more Product Designers in the future, it was important to start creating the foundation that a design team can build on.

show_chart

Team Scaling Quickly

Since the company was hiring more product leaders, there was an increased need for cross-team consistency, clear boundaries between roles, and to set expectations for how design will show up for each initiative.

school

Education

There was a general lack of knowledge of the Product Design discipline on the team, leading to miscommunication of what what a Product Designer is meant to do.

Known Limitations
cognition

Lack of product design knowledge

As mentioned before, any design process is new this company, so it's important for the first phase of it to be simplified and easily digestible.

sprint

Design sprints move quickly

Since the company was hiring more product leaders, there was an increased need for cross-team consistency, clear boundaries between roles, and to set expectations for how design will show up for each initiative.

The Process for Making a Design Process
Like any project, I proposed that we use a simple design process that can help us execute on this deliverable.

The goal of this process was to make this project feel loose and easy to customize to our needs. In general, this process was a guide and not a hard-rule for us. We often deviated from it or make decisions on next best steps based on the current needs of the team.
travel_explore
Gather real-world examples
trending_flat
question_answer
Learn from internal stakeholders
trending_flat
south_west
view_list
Gather Feedback
repeat
travel_explore
Iteration
trending_flat
travel_explore
Finalize Design
trending_flat
rocket
Soft Launch
The "Final" Process
Note: This project was still in progress when I transitioned out of this role.

The first version of the design process is very similar to a standard design process, but with a few tweaks that considered our needs:
  • Defined which steps are required vs. skippable. "Skippable” steps take into consideration the fast-paced nature of product releases since it's not always realistic to go through each step when delivering in as little as 1 week cycles.
  • Prototypes do not need to always be high-fidelity. For smaller features, it is enough to have a wireframe or quick description of what to change.
  • As the Product Designer, I advocated to keep "Defining the problem" and "Reviews" as required because it was common for the Product Managers to release features that the leaders did not fully understand, resulting in a lot of rework. Reviewing at every step is a way to avoid confusion and help others understand why specific decisions were made.
We expanded on each step in the process by answering 3 questions:
  • When is this step is needed?
  • What questions do designers need answered during this step for them to move forward?
  • What design activities can help us execute on this step?
We also specify which internal stakeholders were necessary for each step.

In general, we decided it would be best to think of it as a "bucket of things" rather than something that is linear. Whenever we asked ourselves, "What should we do next?", this should be a guide we pull out. We may jump around, move backwards, or even alter some steps for a specific project. All in all, this process is served to be a guide and not law.

Why Now?
psychology_alt

Inconsistencies

Designs that serve similar purposes have different look-and-feel or design pattern​, which results users being confused or they lose trust in the reliability of the service.

sprint

High, Fast-Paced Output

The designer is often expected to create anywhere from 1 day to 1 week delivery cycles. Having guidelines will help the designer save time and mental capacity when creating new designs, especially when there are multiple projects happening at once.

Process
view_list
Gather Guideline Needs
trending_flat
123
Prioritize
trending_flat
lightbulb
Ideation for Each Need
repeat
rocket
Record Final Decision
(Design if needed)
repeat
design_services
Iterate as much as needed
Solution (Work In Progress)

We were still in the beginning stages of creating design guidelines when I transitioned into a new role, so this is focused on how I helped kickstart the process and I left off for the team to run with.

We gathered requests for anything that needs a guideline from the team. I made it a habit to add any needs as I hear them throughout my internal conversations. In addition to logging our needs, this serves as a great way to get buy-in from leadership when asking for time and resources to devote to this initiative.

​🚀 Some next steps I would have taken if I continued on the project:

  • Prioritize each request into top, middle, and low priority buckets.
  • Schedule a weekly or bi-weekly meeting to pick 1 or 2 guideline needs and define them as a group. Ideally, this meeting should include Founders, Product Managers, Engineers, and Product Designers.
  • Record and communicate the new guideline in weekly all-team meetings for visibility and feedback.
Why Now?
foundation

Internal Knowledge

Many internal stakeholders, including myself, cannot tell you the current user flow

sick

Many Pain Points

The current process was too convoluted and confusing for customers. Additionally, internal customer service and sales struggle to communicate expectations to customers. Identifying where in the current process has a pain is easier when it is visualized.

Known Limitations
cognition

We cannot identify every way the flow can split off

Each split has a process that is inside of likely one person's head. The process of identifying all the stakeholders who can be a resource and recording what they know can take time. ​

sprint

Our end-user (members) is broken down into multiple personas

Something very different happens for every member, therefore some personas probably do not have a specific flow they follow today. This creates the need for the team to prioritize which personas need to be outlined and addressed first.

Process
account_tree
Diagram what we know
trending_flat
question_answer
Connect with stakeholders to fill gaps
trending_flat
account_tree
Iterate using new knowledge
repeat
question_answer
Get feedback
trending_flat
design_services
Clean up final flows
Solution (In Progress)

Future Considerations

Component and Pattern System

​As mentioned, Uno currently does not have an end-user facing web or mobile product, but we have an internal product that our enrollment team uses. This product is used to determine health service eligibility for our members. This first step into building our own web products opens the discussion of whether we need to create a component and pattern library. Although it is not currently top priority, it is a great next step once we establish the immediate design guidelines through the efforts outlined in this project.