Looking for lean UX processes? Change your environment!
Learning what slows us down to help speed us up.
Imagine a football coach talking to one of his players: “It’s time to hit the training pitch and prepare for our next game. Think of all the scenarios that might occur and come up with creative ways to master them. Oh, and don’t forget to think of some strategies to beat our rival next Sunday.” To top it off, the player has to do this while his teammates are in the middle of playing another game.
Sounds ridiculous? Of course it does!
If you were this football player, you’d immediately think this is a crazy way to prepare for your next game. But in our game, the creation of digital products, we still tend to act in that exact way.
When creating our digital products, we’re challenged by the constant struggle between implementing features as quickly as possible and coming up with a compelling plan for what to do next. And all of this while pursuing a winning strategy: focus on making an impact with our users, and deliver outcomes to grow the business.
In recent decades we’ve all learned that change is the only constant in our business. This is why we started following agile principles and deprecated the waterfall approach of working. A logical solution to the challenges we faced, it has proven to be the path to success. But today, when we look at WHY corporations choose to adopt agile principles, you often see a different picture. It’s less about change but more about ‘accelerating software delivery’ (see stateofagile.com; 14th annual state of agile report). It’s stands to reason that in highly competitive markets, ‘time to market’ is crucial. It’s all about speed, and as long as we deliver solutions that meet user needs and create value, we’ve nothing to worry about, right?
If there’s nothing to worry about, how come many teams that focus on outcomes and impact still complain they don’t get much done and that initiatives feel like they take forever? Is this just a feeling or are those teams actually slow?
To investigate and arrive at an answer to these questions, let’s look at why many cross-functional teams try to optimise their processes. What are they introducing to their processes from retrospective to retrospective? And what does this all lead to?
Remove uncertainty
The first area for optimisation is the tendency to remove uncertainty as quickly and thoroughly as possible from any initiative to be worked on. Humans hate uncertainty and in most organisations itʼs not regarded favourably. When a product manager is uncertain how an initiative will turn out, she’s seen to be not doing her job. When a designer is uncertain what the ideal user experience should be, he’s seen to be not doing his job. If a developer is uncertain whether she can pull off a feature or how long it might take, she’s seen to be not doing her job. What’s even worse is the fact that it’s not only how others perceive our work, but how often we tell ourselves “we haven’t done our job if we don’t answer all the questions”. As a result, processes are designed to eliminate as much uncertainty as possible beforehand. This makes us feel like:
We can’t fail with this!
But we all know that sometimes we’re going to fail and not everything is going to turn out as we planned. There has always been something we weren’t certain about and, as a consequence, we engage in a retrospective and decide on a logical measure to take: Let’s invest more time in upfront investigation and planning, i.e. let’s remove more uncertainty. You might have already spotted the issue here — the more initiatives we have, the slower we become.
100% predictability
The second area for optimisation, which is closely related to the first one, is the pursuit of 100% predictability. We humans hate uncertainty, and we’re not very good at handling surprises. Sure, some of us enjoy a nice birthday surprise, but when it comes to business, we want to know what will happen if we do X, Y or Z. This is why we invest time and effort to predict as accurately as possible what might happen. Unfortunately, this is a misconception. Instead of seizing an opportunity to experiment and learn, we focus on being sure of a certain outcome, looking at data in the quest for proof of success in advance. However, more data means more uncertainty and, ultimately, more and more investment. This is known as paralysis by analysis, meaning we end up losing sight of WHY we wanted to invest in an initiative in the first place.
Getting ahead of work
The third area for optimisation is preparation. Preparing as much as we can so delivery is just a matter of execution sounds like the most logical thing in the world. We think that ‘getting ahead of work and investing more in planning’ will make us faster. Sorry to spoil things for you but this is a battle you can’t win. Here’s an example: Most of the time a group of people is sent out to work ahead. They try to investigate and answer as many questions as possible. Designers create all the visuals needed for a feature, often with multiple variations per platform (web, iOS, Android) and viewport sizes. Lead engineers are sent out to prepare all the details on how to implement the feature. Sometimes they go so far as to walk through the code in their head, documenting it in Jira tickets. Product managers work ahead on expectation management, covering release announcements or visualising development roadmaps to be communicated when their teams are busy delivering planned features. This approach presents two major problems. First, it assumes that implementation will lead to everything turning out as planned. Second, and much more significant, is that by preparing all the details, we define the scope of an initiative. Here, the human perception is we answered all the questions and designed the desired solution. This is how it has to be done. It’s just a matter of time. Right!?
All these optimisations to our processes sound reasonable and smart. We think they make us faster. Sometimes, though, we have to adopt new or different approaches that actually make us faster and more lean when it comes to product development. By knowing what makes us slow, we can look at the way we work as a problem we can design for. As designers we have the tools we need to design our environment for a lean, agile, fast and collaborative goal-driven process.
In the following articles I want to talk about three areas for optimisation that foster a different environment leading to initiatives being faster, more focused and in a lean mindset.
Please use the comments section to send me your thoughts and stories about what you try to optimise your processes for.
… follow me and read all the parts in this series:
