Most UX designers deal in the art of what’s possible by imagining new and compelling experiences. By contrast, downstream developers tend to be more comfortable with what is – balancing what works against the uncertainties of pushing boundaries. These differing mindsets can cause friction, resulting in suboptimal designs, especially when teams work under time pressures of an Agile or DevOps culture.
Time pressure is the new norm, and with the creation of new development platforms and practices, it’s possible to drive products to market faster than ever. Some resulting products are novel, but many others are undifferentiated and don’t keep customers satisfied for long. We’ve seen too many valuable and differentiating features left out of products due to sprint cycle timing.
The wrong product – fast – is not a great solution: understand the need and the user by incorporating worthwhile user-centered design methods into Agile development.
Time is the currency of Agile development practices – specifically, time-to-market. User-centered methods can be perceived to come at a cost to that time, as well as other resources. However, uncertain or evolving requirements create confusion (and stress) for design teams. For a few reasons, reduced opportunity for user input means suboptimal solutions find their way to market. But enhanced customer/market intelligence, that ultimately more than pays for itself, is well worth any investment and can be done in ways that sidestep ‘the critical path.’
A common solution is to stagger UX design sprints ahead of development sprints, achieving approved design specs before the development team needs them. Some UX teams are able to build in enough lead-time to answer key research questions. But that can be a hard sell to business stakeholders salivating for that minimum viable product or quick beta launch. In other cases, UX tasks can be interleaved with development tasks to achieve successful outcomes. Workflows can be tested and revised while business rules are translated into technical architecture; or, visual design can evolve during early front-end development.
Efficient, iterative research sprints can and do enable better processes without the Gantt-chart-overhead that product owners may reflexively fear. Below are some considerations that may help teams be user-centered and Agile. Some may seem like compromises at first, but they can lead to better outcomes for you and your team – and your users.
-
1. Be autonomous but collaborative
-
Whether UX tasks are interleaved with development sprints (the product backlog), or exist as a discrete series of tasks, research goals should have a dedicated product owner working in close coordination with other UX/development team leaders. It is too easy for important user research questions – and the steps required to answer them effectively – to be short-circuited when the pressure of product deadlines increases. -
2. Create situational awareness
-
Accessibility to the user base often dictates the duration and frequency of research sprints. Separate studies, focused on answering one research question at a time like screen layout or iconography, may better support the overall Agile timeline. However, specialized users who are difficult to access may need to be engaged on a range of topics ultimately spanning several design or development sprints. Cost-effective user access, balanced with program requirements, will dictate piecemeal versus broad-based research methods. -
3. Schedule larger research efforts across several sprints
-
Whether 2, 4, or 6 weeks long, sprint durations may not fit neatly within the cadence of the Scrum timeline. Seek progress over perfection through interim milestones as simple as completed discussion guides or top-line findings, if final reports with recommendations are not achievable during a given sprint. The main thing is that project stakeholders know what to expect, and when. After all, transparency is a key process goal of Agile. -
4. Use a RACI decision framework
-
At Essential, we recently completed a series of communication workshops. Even though it seems self-evident, deciding who is Responsible, who’s Accountable, and whom to Consult or just Inform on project matters is good practice, with or without Agile. Tying back to ‘autonomous but collaborative,’ this agreement among team members according to project tasks helps prevent senior personnel from pulling rank on contributors in cases where they are Accountable or Responsible for project dependencies. -
5. Embrace a little ambiguity
-
Create opportunities for quick-and-dirty user studies. A simple online usability test may not be ideal when bigger, more strategic questions linger unanswered. However, something is better than nothing, and sideways is sometimes better than head-on. Even inconclusive, documented evidence of less-than-ideal product impressions on users will help to make future studies (such as rigorous qualitative ones) a bigger priority. This can also illustrate for the project team/product owner the important difference between getting the right design (more complicated) and getting a design right (less complicated). Usability does not equal desirability or viability. -
6. Invent your own methods
-
Agile teams composed of research, UX, business, and software development may shy away from incorporating much research into UX tasks if researchers are overly pedantic. Rather than holding fast to “proven” methods, and potentially losing the war, researchers demonstrating some flexibility with time and scope can win a lot of battles. For teams who are quick to say that they are ‘data-driven’, you might develop a series of paid search ads, leading ‘shoppers’ to microsites promoting hypothetical products. While you will need a modest SEM budget, there will be no recruiting or incentive costs. You’ll get real-world data but, importantly, you will miss a lot of the Whys. This can be a good thing: the extended team’s desire to know “why” can then translate into more latitude and trust (i.e., time and resources) with future studies. -
7. Convert challenges into opportunities
-
As a researcher, working with a capable development team eager to build something means you can test believable prototypes sooner. Rather than challenging assumptions that are baked into accepted requirements, use early iterations to test the value proposition, in addition to its functionality. Or consider how one code base may be used to test multiple solutions/variations. Fast and cheap methods like online testing may make this difficult – try to balance un-moderated sessions with a handful of moderated ones, enabling one to inform the other. Or ask permission to follow up automated tests with a 10-minute phone call. -
8. Speak your constituents’ language
-
Stated earlier, most UXers transact in the currency of what’s possible. Developers are more comfortable dealing with what is. Manage expectations by introducing confidence levels into your plans. Whether the need is characterizing the problem space, or assessing usability across a range of user types, you can characterize alternative plans to achieve a 60% confidence level versus one with 90%. And although effort and confidence levels are not always linearly coordinated, something is still better than nothing. -
9. Above all, offer critique over criticism
-
A client once told me, “We are Agile, but try to be flexible…we call it FrAgile.” An incomplete, hurried, or otherwise grudging implementation of Agile is what we call bad process. This client’s term is funny, but if resistance to process ends up breaking the process, it’s time to rethink and realign the team (and maybe the company) around better process that works for everyone. Development resources can’t turn on a dime, which is why preceding (UX) deadlines are so hawkishly managed. When strategy and structure of the UX (‘nice-to-have’) drive the bottom line more than development rigor (‘must have’), successful implementation of some of the practices above will lead to more favorable research and UX integration within Agile environments.
It’s dangerous to drive every project using any fixed methodology, but many do lend themselves to an Agile approach. Appropriately aligning UX design and research with development teams reduces friction, leads toward preferable outcomes, and builds stronger institutional appetites for user-centered design.
The pundits say that politicians reach stalemates because they have lost the willingness to compromise, to listen earnestly to contradictory views. At Essential, we’ve encountered client teams in conflict and it’s rare that we see the right answer being on either end of the spectrum. One position doesn’t necessarily have to lose in order for the other to win…the answer is usually somewhere in the middle. We believe that when the user wins, the business wins. Facilitated dialog during our engagements leads to consensus: a final design that is not only sensitive to a team’s time-to-market objective, but also results in a desirable and viable product enabling the business to be more competitive.
Bill Hartman is the Director of Innovation Strategy at Essential Design.
Essential Design is a leading Innovation Strategy & Design consultancy. We work across the healthcare, consumer, and commercial industries, helping our clients conceive and drive to market comprehensive digital, physical, and service experiences.
