Delivering Outcomes
Changing the way UX is engaged
Brief
Shifting focus from outputs to outcomes requires an entirely new perspective on work. It requires each individual to have a sense of ownership and understand the “Why” around the project rather than the “When” it’s due.
Simple changes in engagement can change how cross functional teams work together. Moving from a culture of outputs to outcomes is the 1st step in moving from a service model to an innovation model.
The enterprise problem
An enterprise software team builds a product based on a list of customer request. Requirements are written, and development teams build against requirements. Surprise, the customer hates the product. The software team rushes to add a UX team “to make the screens pretty.”
The enterprise problem is 2-fold:
Poor understanding of how to effectively utilize a UX team
Misunderstanding customer pain points
Phase 1:
Product teams send requirements directly to Development. The product is often left with bad reviews by customers. The “waterfall” model.
Phase 2:
Software companies realize they need a UX team. Due to poor understanding of UX value, the teams are often placed under the Development org.
Phase 3:
In an attempt to “move UX upstream” the communication model is reformed in a new order. We now have “2 week waterfalls.”
Phase 4:
UX is given an equal voice. Communication has transformed from a linear 2D model to a 3D collaborative one. We can finally put the customer in the center of everything we do.
1 – Poor understanding of how to effectively utilize a UX team
A common misplacement of UX teams is often downstream in the hopes that a front-end developer and a UX designer can work hand-in-hand to pump out screens per sprint. As designers, we all know that layouts are built on more than just aesthetics, but heavily rely on context. Context, which is revealed by designers asking questions, research, competitive analysis, product vision, sprint planning, etc. All artifacts that may seem unrelated to the handfuls of jpgs the designer is being pressured to deliver.
My first steps in addressing this specific problem are to document the time & effort required to create the invisible artifacts of design deliverables, the value of each artifact, and who else outside of design can benefit from it. The methods in how I socialize these issues is covered in my Scaling article.
In order for this message to gain traction, the immediate actions are to socialize this message upwards, downwards, and sideways. Having awareness within the organization is a huge step to pushing UX teams up the workstream. The long play is to ensure that design teams are tacking their time accurately. It is imperative that contingent efforts are represented clearly in Power BI (or any tool) reports.
2 - Misunderstanding customer pain points
Design, as a tool, is exceptional at finding solutions to problems. Design is proficient at finding solutions because a designer brain asks the right questions. Consequently, that makes design the perfect tool to identify the right problem.
In a service model, all too often product teams will listen to customer feedback and turn those into requirements. This puts the customer in an unfair position. The burden is now placed on the customer to be able to articulate why the tool is bad. The customer is not an SME and we should not expect them to have the answers. The customer is simply aware of the inconveniences a tool imposes on daily activities.
The new engagement
Bringing representatives of UX & Dev upstream enables those functions to make contextual (and better) decisions around execution. The representatives who are informed of the objectives are now able to plan independently from product owners, thus leading to efficiency.
The following is 1 example of many engagement guides I had put together for my collogues as an interim step for the cross-functional team towards focusing fully on outcomes. It outlines who is involved at each stage, and what the expected takeaways are.
This guide put into practice is documented in the Design Sprint.
Kick-Off
A kick-off meeting is an exercise to ensure a level understanding of the Problem Statement amongst the team, and for the team to collaborate on the solution. The success metric for a kick-off is for the team to unanimously agree on the solution, scope, and timing. The outcome of this agreement is what will become an FE.
Step 1 - Identify the problem
A kick-off should start with the BPM inviting a group of stakeholders to present and discuss a Problem Statement. This presentation must be able to clarify to the audience the following:
Problem to be solved
How was this problem brought to our attention
Are there existing work-arounds to this problem
Who are we solving for
Are there potential overlaps with existing features
Objectives & Key results
The audience is expected to have read the documentation prior to the presentation.
Step 2 - Get on the same page
Team members will explain back to the group their understanding of the problem and proposed solution. This exercise is best done on a white board or paper to ensure low fidelity and abstraction of the solution. This allows UX to focus on screen & task flow, while Dev to focus on feasibility and architecture.
Step 3 - Reach an agreement
The outcome of Step 2 should be an agreed solution and scope amongst the group. This agreement can be treated like a contract, which will inform how the FE should be written. Based on the solution and scope, the TPM is able to project a deadline for the team.
The FE should contain all the notes and assets that came out of the kick-off so that they can be referenced at a later time.
Design
With a better grasp on the context, the design phase can take place with less disruption. The designer will create stories against the FE, ideally connecting them with the Dev stories being written by TPMs. A large part of the designer's responsibility is to attend stand-ups with dev teams, as well as stay in sync with the larger components system.
Step 4 - Break the FE into UX stories, create your own backlog
At this point, the FE should have captured the high level flows and objectives. As a rule of thumb, the designer should discuss the breakdown of stories with the TPM. The designer should keep in mind that they are serving 2 audiences. The visionary work serves the BPMs and users, while the informative work serves the Development team.
Daily practice
The designer is expected to attend Dev stand-ups on a regular basis. The designer should know which Developer will be working on the front & back end portions of the design solution. Any discovery, progress, setbacks should be communicated to the Developer.
This regular practice of communication is meant to manage the expectation of the Developer up front. This will help with making the Dev grooming sessions easier and efficient.
Step 5 - Grooming / Hand off
At this point, the Dev team should have access the following to conduct a constructive grooming session:
High level business objectives
Task & screen flows (low fidelity assets)
Mock ups (high fidelity assets)
Component library
Design stories that the Dev stories are dependent on
Question handling
It is very likely that there will be questions during Dev grooming sessions. Not every question needs to be treated as a blocker. Have the larger team decide if the question simply needs a decision, or if it's a true blocker which needs a new story (which means new design sprint).
Development
Step 6 - Tackling stories / Dev stories
Not all questions are going to come up during the grooming sessions. There will always be questions, discoveries, progress, and set backs for developers. When these questions come up, the Developer is encouraged to speak to Design or BPM directly. Any new information should be documented in the story. If the discovery reveals the need for a spike, this needs to be communicated to the larger team.