Why “make it work like Turbotax” is my least favorite request
How to set up a user experience design practice in a development-driven culture.
If you have heard this request over and over again you’re not alone…it has followed me from small financial startups to the largest government platforms.
It’s not a bad thing to work like Turbotax — it’s simple, usable software that makes it easy for folks to file their taxes — my issue with the request is it expects good UX to be effortless, as if it can be added on top of development rather than serve as the driving force behind development.
The Turbotax request is often a signal that project leadership expects UX designers to work within an existing agile practice without modifications, increased cost, or…god forbid…slowing the project down.
In my ideal world, I would turn projects like this down because they are fundamentally flawed (i.e. UX is an afterthought instead of the project’s backbone). But since we all have to eat, there are a few tactics I use to set up a user experience design practice in development-driven teams.
Step 1: Get a handle on what’s going on
As you onboard, the first thing to do is learn what has been done so far. Even if there are no designers on the project, chances are there are some folks advocating for the users. Find them and download their brains. Review any documentation about user needs and how the product will solve them. Familiarize yourself with business goals, the funding model, the products competitive advantage. Ask your new teammates why they made the decisions they did. Make sure you know your stuff so when you start working you can add to what has been done rather than reinventing the wheel.
Step 2: Start working within the existing structure
When on-boarding to a new project, designers typically want to run a “Sprint Zero” to understand user needs, validate assumptions, and test the software that has been built so far. This can be a tough sell when the project is already in motion — when I have suggested it in the past, the room gets quiet really quickly.
Stakeholders tend to have their reasons (budget, deadlines, promises, etc.) for resisting design sprints, so I accept that as a constraint to design my UX practice around.
I start by plugging gaps in the team. If a developer is struggling with a table pattern, redesign it based on best practices. If the color palette is not 508 compliant, suggest new colors and make it easy for them to be implemented. Small wins build buy-in for good design. When you demonstrate progress early, your stakeholders will be more open to taking a chance on larger asks later.
If you adopt this strategy, track the assumptions you are making, so you can test them later.
Step 3: Make space for design in agile sprints
The entire team is responsible for addressing both user and business needs; they need to believe in the necessity of user-centered design to deliver a useful product. When teams aren’t held to this standard, user stories are developed before their purpose is understood, features are accepted for production without usability testing or design QA, and unsuccessful products launch.
How can you hold your team responsible for user and business needs?
When designers are embedded on agile teams, I don’t think it’s useful for them to “sprint ahead” of the rest of the team. When they do, getting stories ready tends to fall squarely on the shoulders of the designer. Instead, development needs to get involved in the design process, and design needs to assist development.
You can ensure this happens with two scrum or kanban-style boards — one for getting stories ready, and one for developing them.
The ready board
You can assign columns that make sense for the team, but it’s important that:
- User value is defined up front.
- The team has time to explore both business objectives and user needs.
- Development reviews designs, user flows, business logic, integration needs, etc., before they start working on it.
Depending on the story, work can sit on this board for hours, days, or weeks. Often, backlog items start as an epic and get broken out into smaller pieces as they make their way to the right side of the board.
The work completed in the ready board will vary based on the needs of the particular feature. Activities within the “business and design” vertical can include everything from user research, business analysis and determining the logic or flow, to prototyping, content writing, and usability testing.
The “development review” vertical guarantees engineers are involved in the process. Engineers are the only team members who can move the story out of this column, once feasibility is discussed and outstanding questions are answered.
The development board
This is your more traditional scrum board, where developers spend most of their time. The only change I request is for the team to add a “design review” column. Like the “development review” vertical on the ready board, this gives designers space to work with the engineers before stories are accepted to production.
If the development and design review columns work as intended, the engineers and designers will start working together on a daily basis, recognizing the value each discipline provides, and collaborating on features to make exceptional products.
Step 4: Conduct research within an agile sprint structure
When moving work through the ready board, it’s important to figure out what features need in-depth research and extensive usability testing, and what can be completed by relying on existing knowledge.
Directional research = fast and actionable
Some design problems can be solved by conducting small experiments to validate product decisions. These are fast studies that can be completed within a sprint. Directional research answers specific usability questions and is turned into product improvements in quick, incremental cycles.
Directional research methods include guerrilla testing, usability sessions, A/B testing, and card sorting.
Outputs can be UI and copy recommendations that are ready to implement, prototypes and wireframes to guide development, user stories to go into the next sprint, or further questions to explore. While directional research is aimed at answering a specific question, sometimes that answer leads you to more unknowns.
Foundational research = ongoing and insightful
Larger discovery efforts should be conducted to understand users’ needs, goals, and motivations. Foundational research is vital when developing new features or reaching a new group of users. This type of research spans sprints and influences multiple stories or epics.
Foundational research methods include ethnographic research, contextual inquiry, user interviews, content audits, and competitive analyses.
Outputs can be archetypes, journey and scenario maps, ideas for new products or features, or early stage prototypes.
Share research with the team as much as possible
When you do research in development-focused environments, you may need to demonstrate its value over and over again. Without continual emphasis, it’s easy for the team and stakeholders to slip back into the habit of delaying user research in favor of meeting development deadlines.
There are a lot of ways to get your team excited about user research:
- Bring them with you! If developers or stakeholders can’t travel, set up a remote video connection so they can observe research sessions from the office.
- During sprint planning and demos, start each story by explaining the problem it solves and the specific user feedback received to date.
- Include relevant insights from research in user story tickets — you never know who will take the time to read it and learn more.
- Take 10–20 minutes out of regularly scheduled meetings to come up with solutions to usability issues. To do this, start with a quick overview of the problem and spend a few minutes individually brainstorming solutions. Next, share out ideas and discuss development viability. With additional time, dot-vote or use another design method to come to consensus on a solution.
To learn more about how to conducting user research in an agile sprint, read How to Stop UX Research From Being a Blocker by Ben Ralph or use the 18F method cards.
Step 5: rinse and repeat
After following these steps, the entire team should be more focused on delivering real user value. So what next? Keep doing it. Continue to advocate for the users and make more room for user experience design and research. To make a product like Turbotax, user experience needs to be everyone’s responsibility. If you can make this happen, you’ll see the culture start to shift from development-driven to driven by user needs.
