UX Design Strategy
Wells Fargo
How I worked with Wells Fargo leadership to update the Experience Design department’s design process
Wells Fargo was ignoring the fact that Designers in the Experience Design group (XD) needed time to check what engineers built and call out places that didn’t follow the design documentation provided. We wanted to make sure that those checks were completed before the code rolled out to production.
Goals
Results
I worked with my Product Designer colleague, Steven Steiner, to perform a standard UX design process on our own process. We researched, defined, ideated, and tested a new process that was eventually adopted by our design leadership as the standard process that everyone in XD would follow.
XD and partners reaped multiple benefits
The standard end-to-end process for delivering XD assets from inception to acceptance created greater alignment on who was responsible for what and when
New Product Designers ramped up faster with a shared understanding of what was expected
Agreement from business partners and scrum team members on the design process to help set and manage delivery expectations
More productive Product Designers empowered with the ability to own their craft and design impactful customer experiences
Research
We started by looking at the process diagram as documented in Jira. It was the resource that all scrum teams used as their guide for when to engage Design on a project.
Assumptions
Design was mentioned once. If Design was ready, the work went into construction. If the design was not ready, it went back into design.
The Reality
Responsibilities
Doers
Product Owner
Scrum Master
Business Analyst
Product Designer
Front-end Development lead
Back-end Development lead
Quality Assurance lead
Data Analyst
XD Value Stream resources
Approvers
Front-end Development lead
Back-end Development lead
Line of Business contact(s)
Legal representative
Risk representative
Compliance representative
Accessibility SME
XD UI Framework contact
XD Art director
XD Content strategist
Product Designers were responsible for support and UAT while design assets were in development, but there was no guidance or structure provided by XD leadership.
The chart to the right groups responsibilities (owner and involved) by job title.
How the XD process was documented in Jira
In interviewing our fellow Designers, we discovered that countless hours were spent in circular conversations that occurred when SMEs were consulted independently for review and approval of upstream changes.
Over 20 Subject Matter Experts were involved from inception to approval of XD assets. This process generally occurred before development efforts could start.
How Product Designers actually performed QA during UAT
When a design was in construction, Product Designers needed to be available to answer questions and address unexpected issues. Once all issues were fixed, XD would validate the development work and the work would move into product acceptance.
Definition
Product Design needs
Product Design at Wells Fargo had evolved to the point at which the documentation in the form of mockups, prototypes, redline documentation, copy decks, and Jira tickets, groomed in cooperation with each cross-functional scrum team, created such clarity for our developers to build our product to functional visual specifications that the QA team could perform those checks during QA, without the help of Product Design. Product Design felt that performing a final functional and visual check during UAT, would be sufficient for ensuring the product was ready to go to production.
Ideation
New End-to-end (E2E) Process Workflow
To avoid the endless meetings spent discussing minutia, we drafted a new end-to-end workflow with 10 primary tasks, split into 3 phases (Define, Design, Development), distributed across 4+ Sprints and 5 SME lanes.
Notice that Design & Functional UAT was removed from Product Designer’s responsibilities and timeline. It was up to QA to validate that the product in the QA environment was built to design specifications.
Design approvals occur in Sprint 1, 2, 3, and 4+
All other approvals occur at Sprint 3 and 4+
Accountability of Subject Matter Experts (SMEs)
We reassigned responsibilities for each role, broken down by owners and involved. By Sprint 4+, Product Designers were only responsible for demo and final approval. The idea was that design issues would already have been recorded in Jira by then and it was simply a matter of approving what had already been discussed.
Process Options
We devised three options for how Product Designers and Engineers could handle reviewing the built product.
Grooming Huddles
Asynchronous
Groom Huddles and Review Office
New process features
To achieve the benefits of each process option across new sub-processes and/or documentation (features) would need to be initiated, created, tested, and iterated on.
Pros and Cons of Each Process Option
Each process option presents different possible limitations or disadvantages that could result in longer durations, less time on craft, or increased confusion.
Recommendation
We presented our new end-to-end workflow to XD leadership and they quickly adopted the Grooming Sessions with Review Office, with a desire to gradually move towards the Asynchronous option, as the new process for all Product Design done by XD.
Rationale
Increased time on craft
Get real-time alignment across all Subject Matter Experts
Move design UAT responsibilities to QA
What’s missing?
Some standard design processes used at other companies weren’t included because they were regularly “out-of-scope” as part of the Wells Fargo Agile scrum delivery process.
