designsprint.jpg

Process Improvement

Because no process is ever perfect, how do we keep evolving the way we do our jobs?

Process improvement is part and parcel of working at Mitchell. We’re always looking for opportunities to iterate on how we operate so we can work more efficiently, foster relationships with other departments, and improve quality.

Philosophies for process improvement

  • The process for coming up with solutions for our own team is not that different from coming up with solutions for our users. A lot of these steps will look familiar.

  • Establish scope and enforce it! These types of exercises can get out of hand easily

  • Talk to the people whose lives you're going to be affecting

    • Don't be afraid to revise scope and goals based on your research

  • When working with a group of people, start first by allowing everyone to get their opinions out, and then narrow down collaboratively

    • More important to get the ideas out without constraints. Things can always be cleaned up later.

  • Focus less on what you want other people to be doing differently and focus more on what you can do

    • Or better yet, focus on what you can do to encourage change in others without demanding it of them

  • Ensure that takeaways are concrete and action oriented, and that there is a system in place to re-evaluate if they are still working after a period of time

Case Study: Improve dev support processes

Context

This initiative involved re-examining the parts of the process where designers interact with the developers, and identifying any opportunities to provide them more support without adding too much additional work for designers. The goal is to ensure that developers get the clarity they need in order to implement the designs as intended, and saving rework for designers and developers later.

 

Process

Phase 1: Understand the problem space

  • Why are we having to improve on this process in the first place? What are the pain points?

  • What is the scope of the problem? What needs to be addressed and what won't be addressed?

  • What is our definition of success? What does the happy state look like? How do we know when we're done working?

 

Phase 2: Gather Data

  • Come up with a list of what you want to learn and then write questions around it

    • What are people's pain points?

    • Do they have any suggestions or where to start?

  • Go talk to the people who will be affected by the process change

    • In this case, a total of 22 developers, delivery managers, and PMs

 

Phase 3: Enumerate the problems and prioritize them

  • Although there was an original grasp of the problem space that guided the discovery question creation, ultimately the problems we sought to solve had to come from the discovery research

  • Aggregate notes, identify themes, rank and prioritize

    • The group voted to assign effort, impact, and interest numbers for each problem

    • Plugged the numbers into a Prioritization tool and saw what rose to the top

 

Phase 4: Solve the problems

  • (The phase title oversimplifies the process a bit - this took two months)

  • We started by creating a grid with a row for each of the problem we planned on solving, and a column called Raw Solutions for everyone to asynchronously write down their solutions

  • The group focused each problem, proposed our solutions, then transformed our combined ideas into a Distilled Solutions column

  • From there, we got it reviewed by managers and stakeholders and incorporated their feedback

  • We iterated throughout this phase until we met our definition of done

solutioning.png
 

Phase 5: Roll it out

  • Distill process and recommendations into a digestible presentation

    • Guide the audience through the goals, research, thought process, outcomes

  • Be clear about what the ask of the audience is

    • What changes they are expected to make

    • What they look like

    • What benefits they're meant to create

 
 

Results

Revised Purpose

Improve the quality of our products by reducing the delta between what XD delivers and what gets built in the product

Key Takeaways

  1. Begin every design with a whiteboard sketch, then increase fidelity as needed

  2. Document who the XD points of contact are in TFS

  3. Document design assets in TFS - URLs, images, date, who signed off

  4. Explicitly state what should and should not be built in design deliverables

  5. Capture new design decisions in locations where devs will see them

  6. Review dev work before each sprint demo

Next Steps

  1. Dev support team members to present deck to delivery and offshore managers, PMs, POs, and Dev Leads

  2. XD team members to start practicing Key Takeaways

  3. XD will regroup for retrospective at the end of 20.1