The Impact of Rushing on UX teams: Dealing with the Need for Speed

Create and use time efficiently, in order to inject the ‘why’ into pre-planning and delivery

As UX practitioners, how do we innovate and pivot to the best of our ability, in order to increase the likelihood of the right time, right context solutions to our customers and consumers, within an “agile” workflow?

Slack (verb) decrease or reduce in intensity, quantity, or speed.

More often than not, User Experience Designers perceive a friction between the business perception of UX in the creation of product strategy and effective research and design implementation. The causation of this is simply that many businesses, including software and technology houses, are confused about how to deliver consumer value to the market effectively and support this in their delivery processes.

A symptom of this problem is the conflation of design with UI asset delivery within UX in agile software development, or a finite, sprint-based timeframe omitting core user-centred methods such as research or user testing. A similar pain point for user experience designers might be the omission of discovery, validation and behavioural feedback prioritisation within pseudo-agile or lean work systems, but less so if applied to Continuous Delivery in its purest form, incorporating validation cycles.

Other work system solutions might include processes such as dual track agile, advocated for by industry greats such as Marty Cagan and other models of process based on team and product maturity suggested by Jeff Patton. However without cross-functional and organisational alignment, UX delivery teams cannot achieve change easily, on their own.

Additionally, due to the nature of the way a value proposition and the way an MVP is defined, there may be limited time to execute synthesis that might help the team best define horizons of execution and slice features which can also impact on the effectiveness of UX delivery teams. This imposed restricted bandwidth can cause UX teams, even if gunning for continuous improvement ideals, to be forced into mini-waterfall cycles, throwing assets as needed ‘over the wall’ to engineering teams, without due diligence in testing or risk mitigation in research. Hardly ideal for the end-user or the teams/individuals involved.

A very real scenario is this. Imagine teams like this shifting gears rapidly from one feature MVP deploy to another pre-planning kickoff, on to something completely new, without the understanding of how well the prior release performed or could be improved. This organisational need for speed can impact even on the most seasoned agile UX delivery teams, without the right bandwidth to understand what is better or worse, particularly if prioritisation isn’t user-centred.

The mind shift and stretch for UX delivery teams in this case is to still identify the feedback for a future feature backlog with the product team in parallel, whilst working ahead for the next epic or initiative in order to obtain the user needs to justify the shift to backlog grooming, as dictated by the product roadmap. The risk, however is that feedback will be lost and ignored, in the urgency to seek the next piece of ‘gold’.

The question is, in these cases, how do we, as UX delivery teams and risk mitigators, slow down speed and accelerate effective research and design in limited time frames to improve user experiences?

In order to successfully combine agile methodologies with creativity and innovation, user experience designers and technology teams require room for more divergent thinking in the appropriate rhythm before, during, after and in parallel to software development workflows.

The risk in rushing or a brim-full roadmap, is that, despite best intentions, workshops or activities such as sketch sessions might become the avenue for agenda-ed synthesis, and execution opportunities could be lost without clear and considered thinking. Additionally, without time and preparation, we may lose the benefit of including the right team members and users in truly valuable sessions created to induct thought or validate our ideas and interpretations.

We need to enforce the need for appropriate space for thinking and slack in our working sprints to allow for the flex into the spaces of synthesis, to avoid forced interpretation of ideas, even if meaningfully gathered, into execution that may increase dissonance between our users, our products and ourselves.

Evidence preceeds itself. The use and re-use of Design Thinking methods and the Double Diamond model (2006), and, increasingly, experimentally combining this approach with Lean UX and Lean Startup methods, I’ve found to be fruitful for rapid discovery, problem definition and collaborative problem solving. These methods are now considered by many to be important catalysts for any innovation and/or agile workflow.

Saying this, when we are rushing, or uncertain, perhaps our best next guess is small and basic needs driven.

What are the current, low hanging fruit?

Firstly, let’s step back to the KANO model, a product strategy priorisation model created by Noriaki Kano (1984). Kano’s model addresses satisfaction drivers and has been used successfully by myself and colleagues in industry to pre-prioritise issues in the product backlog.

Perhaps this is where the origin, in product-speak, of ‘Delighters’ comes from, as Kano’s measurement criteria measures the following attributes against issues in the product backlog:

• Basic Needs
• Performance Indicators
• Delighters

One of the interesting aspects that Noriaki Kano considered in his model is that the cadence of ‘Delighters’ changes over time. What might be considered and validated as a ‘Delighter’ with users can become hygiene, or ‘Basic’ needs, eventually.

What was shiny is the new normal

Consider the example of the ‘typeahead’ or ‘autocomplete’ feature in search. The autocomplete feature was created by ex-Googler Kevin Gibbs and originally named Google Suggest. This feature was developed over a decade ago by Kevin, then a Junior Software developer. This, at the time, would have been considered an innovation and ‘Delighter’, at feature level.

Now, however, it is an expected paradigm in a search experience that most users are used to interacting with. This pattern is mimicked in patterns on other sites from Amazon to AirBnb and the UX of these product search experiences might be considered lacking these days if this interaction prompt was excluded from the product’s usable features. Therefore, now, according to Kano, this would be a ‘Performance’ or even ‘Basic’ consideration in a robust and reliable search experience.

For similar examples check out the Microinteractions website.

The impact of change and other loop models on iterative design

The impact of the Kano model is paralleled by the simulation of ‘loop cycles’ in many human centred and iterative models that have been created to show technology design and delivery workflows. In Continuous Delivery, agile designers must be able to adjust to change. Lean Startup methodologies assist with this with the Build, Measure, Learn Cycle. User Centred Design processes are also cyclical and support this approach.

As designers in agile workflows, we, our colleagues and the businesses we work for, are required to be nimble, in order to serve and assist our users.

Pre-planning Discovery when engineering teams are waiting

In order to even touch the surface of understanding human needs in product development, UX delivery teams need relative time to the scale of the problems we are trying to solve.

The estimation of this time is usually reliant on an idea of what might be needed based on the validity of existing data and, ideally, before our engineering team’s hands are empty.

If the well of ideas or initiatives is dry, this can create natural slack and become an opportunity to look at urgent or neglected persistent consumer feedback. An opportunity backlog that truly reflects very real, current and pressing problems that users would appreciate a solution for in the nearer rather than far future. This might be the low hanging fruit or it could simply be a persistent problem that is emergent.

Based on a cross-functional team’s confidence in what it knows, with reliable and valid data and sizing cards down to utilise engineering quickly, UX designers can start building real value into released experiences rather than large but somewhat desperate and invalidated improvements. Bolstering this behaviour with a robust discovery session over the course of an hour, a day (eg. Lean UX) or week (eg. Google Ventures Design Sprint) can only benefit ourselves and our colleagues who are invested in what we design.

We can help each other in our agile, cross-functional teams to enable and champion authentic findings and insights that might become valuable attempts at solving the very real problems of our consumers and customers. If our hypotheses are wrong and consequently disproven, the ultimate value is learning and improvement, something that all of us can benefit from with the luxury of time.