Making use of Lean UX methodology at Boiler Room Product
This is the third in a series of articles written by the Product team here at Boiler Room. In this edition, we’re going to cover how we have started to breakdown our design sprints using the Lean UX methodology.
Written by Ricky Burgess, Design Director
✅ Validate ✅ validate ✅ validate
In the first article from this series, we explained how difficult it was for us to prioritise the problems we should be concentrating on at any given time. This article will attempt to explain the design processes that the Boiler Room Product team now use to pinpoint and validate the right problems to concentrate on.
A lot of what we’ll be going through is based around the Lean UX methodology. One of the key problems that you will see raised in any article around Lean UX is validation of an idea.
For too long, I have personally worked in team after team that believe in themselves way too much. Don’t get me wrong, self belief is all good but we here at Boiler Room have previously wasted weeks and months working on new features that just haven’t gained the traction we initially expected.
🔬 Step 01: Setting up an experiment
This time last year, a lot of what we developed as a team would be built based on hunches, where new features would be worked up in high-fidelity and a tonne of detail. This was before the team gained the additions of a full-time Head of Product and Product Designer well versed in user research (but let’s not blow their trumpets too much! 🎉) Since then, we’ve been following processes that have helped us to learn quickly and reduce the wasted time developing unnecessary features.
To put this all into context here’s a recent problem we were faced with that where this methodology cam is really useful:
How will we continue to feature brand collaboration projects across our suite of products once we move into Native and TV applications?
This question came about while sharing our future product plans with our existing brand partners. They had concerns about the landscape shifting and wanted to know what our plans were commercially.
Firstly, we used the well-known Experiment Report format taken from leanstack.com to set out:
- What we were trying to achieve?
Understand the metrics/KPIs set by our clients, so that we can find a solution that matches these targets.
- Our expected outcome (falsifiable hypotheses)
50% of our clients’ targets can easily be met without the use of a microsite (our current main solution)
- How we’d set up the experiment
Qual: Interview the Commercial team
Here’s the format regularly used for this type of Experiment Report:
👌 Step 02: The validation plan
Once we had roughly planned out the experiment, the next step was to make sure we knew how we would validate the experiment. This followed the format of:
We don’t currently know anything about what ‘success means in terms of a sponsored campaign
- Current condition
Banner ads are used to help increase traffic
Microsites are a big part of our online execution
We need to know the metrics that clients deem as successful
Qual: A sharing of experiences with current clients
Qual: Reports on past campaign performances
With all of this in place, we were able to crack on with our research interview knowing full well what we were looking to find out the whole time. The experiment would have been a clear failure if that one key question wasn’t answered:
What are the KPIs our clients look to during our brand partnerships and why?
The main things we found that our clients were after included:
• Brand visibility
• Clear communication of brand campaign messaging
• Sharing of branded content
• Lengthy dwell times
📈 Step 03: The Experience Map
What to do with this new found knowledge…
So with the information we were looking for, we could start to map out where we could possibly meet these client needs. We could do this without having to worry that we had guessed incorrectly or that there would be a new unknown need from the commercial team; they had been involved in the experiment from the very beginning.
Something we had been inspired to do after reading ‘The Sprint book’ by the Google Ventures team, was to create Experience Map. This would help us find the most important pain points throughout the entire campaign for both our clients and the end user.
How we used an Experience Map
Before we could come up with any ideas on how to solve the problem we had set ourselves, we needed to see the entire journey that both a client and the user is taken on during an average campaign.
This ended up being split into 5 key stages (as shown horizontally). We followed The Google Venture advice at this stage to ‘Ask The Experts’ and brought in members of the Commercial team to check over our understanding of the entire process. This gave us extra clarity at each of the stages.
😱 Getting emotional 😌
The squiggly lines you see above is our visualisation of the emotional ups and downs both fans and clients go through during an average campaign. This was mapped with the help of the commercial department and could then be used to pinpoint the moments where we needed to concentrate on most.
⚡️How might we…
To make sure we were still focussing directly on the original goal we had set ourselves, the ‘How might we..’ question format was used at each of the points we chose to concentrate on. This gives you a mini-brief for each problem you notice during the experience mapping. Here are some examples we came out with:
✏️ Scamp, sketch and doodle
We now had a clear question to answer during when it came to concepting. Discussing the questions one-by-one as a group and jotting all ideas down in sketch form as quick as possible keeps the whole process as efficient and productive as possible.
👓 We still haven’t had enough of experts
At this stage we grabbed 10 more minutes with the commercial team to get them to vote on our ideas and prioritise which would be most effective, most urgent and the easiest to actually implement.
Doing all of this in the space of pretty much 2 days meant that we were shaving off weeks of sketching, prototyping, discussions and development based on nothing more than a hunch. With the validation of what we were trying to find out, the input from outside experts on things we had no idea about and the structure of having a direct goal to focus on the entire time, this is a way of working that we’ve found hugely beneficial so far.