In the previous article on Product Vision we discussed spending time understanding the problem, designing your experiments and mapping out your high level product roadmap. Now it’s time to start implementation.

The biggest challenge that teams face when moving from Vision to Execution is to ensure they don’t revert back from the outcome driven approach, which enabled the team to come up with innovative solutions, to feature driven development, which limits creativity. Feature driven development comes from the Waterfall methodology where a team is handed a full specification for a feature and just told to go and build it. The challenge is that the team don’t fully understand why they are building the feature and incorrect assumptions can be made. On top of this, because the feature has been specified in full, there is no opportunity to learn through incremental delivery. As Clay Shirky puts it

“The waterfall method amounts to a pledge by all parties not to learn anything while doing the actual work.”

In fact the counter point is true as well - it’s hard to stick to a plan if you’re learning. While you might think you know what the customer wants, when you start delivering it you will learn that some of your assumptions are wrong and your plans need to be adjusted.

“It’s hard to stick to a plan if you’re learning”

The goal, therefore, is to keep learning the entire way through the development cycle. This is achieved by delivering incrementally, staying focused on the outcome to be achieved and remaining flexible in our solutions. Another key point is that we need to recognise that creativity exists everywhere in the delivery team - it’s not just the responsibility of the product department. The challenge that teams face is not knowing how to tap into that creativity. This is where the UXDX model comes in. By incorporating UX into the product delivery lifecycle it ensures that teams are constantly experimenting and updating assumptions about customers so that course corrections can be adopted quickly.

UX

Team Engagement

Tuomas Saarela, UX Designer, and Noe Falzon, Scrum Master, at Yousician gave a great talk on the approaches that they have taken to integrating UX into the product cycle. At Yousician they started with a separate UX process which was isolated from the development phase. This approach is very common in a lot of companies as the UX team are often in a different department to development teams and therefore the work happens in silos. However, as we have learned from years of agile adoption, silos lead to poor handovers, misunderstandings, lack of ownership and ultimately incomplete follow through.

The second approach was to do staggered UX -> Dev cycles. In essence this was an attempt to align the work of each team more closely but it didn’t address the fact that it was still a waterfall approach with handovers between teams. So while the UX research was more fresh, having just been completed in the previous sprint, the challenges of handovers still remained.

The current approach that the team use is a dual track agile approach. In this process there are representatives from the dev team taking part throughout the discovery process as well as UX team members taking part in the development phase. One great side effect of this approach is that the product owner is able to start working with outcomes for the whole team. Previously the UX team were given outcomes but the development teams were given features. Now that the development team are involved in the discovery process they understand the outcomes to be achieved and this is the driver for the development rather than feature specifications.

Research

There were a number of great talks about doing high quality research, but the question that came up most frequently was “how much research is enough?”. Consensus from attendees was that the time allocated is always shorter than what is needed. While not the answer that most people will be looking for Paul Adams from Intercom gave a great response to this question: “A product now is worth more to a company than a better product in a few months”. His point is that companies need to trade off doing the perfect amount of research with doing enough to get the product to market and get revenue coming in. Once the product is out there, you can keep iterating on it and continuously improve it. To be celar, Paul was making this point about developing a feature that the competition already had in place. There are clear arguments for more upfront research when the market and solution are uncertain but the key point is that there is no ‘one-size-fits-all’ answer for the question of how much research is enough. You will likely have less time than you would like so the challenge is to make the time you do have as efficient as possible.

“A product now is worth more to a company than a better product in a few months”

Agnieszka Balcer-Thinlay, Director of Product Research at Codility, gave a talk directly on this topic titled Efficient Research. If you only have one day for research try running a UX lab with the whole team. Schedule four interviews in the morning with alternating interviewers and have the rest of the team watching the live video. In the afternoon run a Hypotheses session to collate all of the amazing insights that the team have uncovered. If you are even more time constrained Agnieszka has had great success with a Pizza Party. In one hour over lunch you can talk through two options that you have for solving a problem and get valuable insights from your customers, all for less than €50.

Segmentation

Jasmin Dahnke, UX Designer at Next Games, gave a talk on uncovering hidden insights through segmentation. In her game, The Walking Dead: No Man’s Land, Jasmin segmented customers into either a sleeper, story, challenge, grind or player v player segment. The original intent of the research was to see how she could convert the sleepers into story players. What was surprising is that she found out the sleepers and story players had the same churn. In digging in she found out that the progression in the stories was too challenging and people were dropping out. This insight led to specific ways of helping story players progress into challenge players which dramatically improved the game KPIs. This mirrors the insights from Catherine Descure’s talk on Qualitative Research. Catherine is the Head of Experience Design at Genie Belt and in her talk she advocated for exploring manual and automated pattern recognition in your research results so that you can identify previously unknown needs and business opportunities for your products.

Personas

Personas were divisive across the UXDX community sessions with some people swearing by their effectiveness and others being set against them. Michael Mazur, Senior UX Design at El Passion, gave a talk specifically on the Strategic Tools for Personas and User Stories. The arguments for personas are that they enable people to quickly form an image of different types of customers, understand their needs more clearly and develop empathy for the customer. The arguments against personas stem from the tendency for demographics to be central in personas, which some argue have mask the real groupings of customers who cross demographic divides. Those who argued against personas prefer to focus on the problem being solved rather than the person solving the problem. LIke most things, this is a case of using the best tool for the job - if you believe that personas make sense for your product then use them but don’t feel like you have to use personas if you believe that they don’t accurately represent your customer segments.

Finding Customers

Another challenge that people discussed was where to find customers for their research interviews. The general advice is to find out where your customers are, and be there. This advice was very dependent on the product being discussed. Pedro Marques, Product Designer at Booking.com, would just walk to the nearest square in Amsterdam because he was virtually guaranteed to bump into numerous vacationers. However, Rasmus Landgreen, Senior UX Specialist at Nordea Markets, works on products used by CFO’s who are harder to get time with. Regardless of your customer type there is likely to be one or more friendly contacts. Talk to your sales or customer services team and try to identify these friendly contacts or reach out to those who are feeling the pain of a missing feature more acutely. Even though there you may have a more limited number of people their insights are still very valuable.

Freshness

The benefit of fresh research is clear. The quicker development teams can act on the insights from research the better the results. Research goes stale over time as customer demands change and the market shifts. Another benefit of quicker releases is that the team can more effectively isolate individual changes and assess their impact in isolation. Linked with an effective A/B testing strategy the team can gain valuable insights into their customers and really optimise for learning.

Hypothesis

The hypothesis session is at the core of outcome driven development. Research at Bing shows that as little as 20-30% of product ideas have the desired effect and up to 33% of ideas can have a negative effect on your product. Unfortunately there is no way of knowing, definitively, which features will work ahead of time, and product teams need to accept this in order to deliver great products. The first step in product development is admitting that you don’t know the answers.

“The first step in product development is admitting that you don’t know the answers”

This is where the hypothesis session comes in. In these sessions the full team come together to tackle an outcome that the business is trying to achieve. The team ideate on potential solutions to deliver on the highlighted outcome using the research that has been conducted. The assumptions document should be referenced and updated in these sessions so that the team can take advantage of previous learnings and track the new assumptions and experiments that they will be conducting. The final step of the hypothesis session is to rank the ideas on an impact versus cost basis and select the top ideas for implementation.

As Tuomas and Noe highlighted in their team structure talk if the development team are excluded from the discovery process it will lead to handover problems like miscommunication, invalid assumptions and ultimately invalid decisions made in good faith. By including the full team you also get to tap into the insights and creativity of a larger group of people. The key thing here to remember is that you do not need to achieve consensus on ideas. The Product Owner is ultimately responsible for deciding on the experiments that will be run but by gathering feedback from the entire team people are more likely to buy into the decisions and understand the reasoning behind their selection.

Prototype

“You can use an eraser on the drafting table or a sledge hammer on the construction site.”

The quicker you can validate, or invalidate, an idea the better. This is where the prototype phase comes in. Matias Pietila, Head of Design at Qwik, gave a talk on effective prototyping. While originally a fan of high quality prototypes Matias says his biggest lessons have come from having to throw a lot of them in the bin. Always one to look for the silver lining Matias likes presentations because he can show his prototypes again - otherwise they are useless’. You need to focus on the requirements of a prototype to ensure that you invest your time appropriately. Prototypes should evolve over time as you define a new feature so balance the effort being input into the prototype with the intended outcome.

Validate the concept

When a concept is still intangible, interviews can deliver qualitative results. Alternatively you can use fake doors on your product to see how much interest there is in a concept. During this phase you are trying to understand the problem more than the solution. This is easier said than done, though, as we all like to jump to solutions.

Validate the usability

Having validated the concept you can now focus on solutions. Start with quick, low fidelity mockups to test what works and what doesn’t. These should be so quick that you have no concern throwing them away and starting again. The key is to keep iterating until you are happy with the outcome or you run out of time.

Optimise the UX

Once usability has been validated it is time to put the icing on top. Animations and complex graphics can be added if appropriate but you need to be careful not to add too much “polish”. These items are the first area to get cut when time is tight so it may be wasted effort and, at times, polish can be added without having a clear purpose. Matias’ view on animations, for example, is that they either direct a users attention to a particular area, highlight the separation of areas in a product or they form a part of the emotional design. Knowing the intent of your polish will help you argue for keeping it in the final product.

Live Prototypes

Prototypes are great for validating concepts quickly but the work often needs to be replicated by the development teams. If you have a large and long lived product investing in the creation of a live style guide with standardised components can return dividends. The prototypes that you build can be picked up directly by the development team reducing the time to market considerably.

From Design to Delivery

Having done the due diligence in defining the best solution for the outcome that you are trying to achieve it is now time to start building it. Continue reading at Execution: DX

UXDX Community

UXDX has a mission to help teams accelerate product success. We believe that this is done by incorporating UX into the product lifecycle and breaking down the silos within teams. Throughout May and June 2018 UXDX ran community events in 8 different cities across Europe. The core concept was the same; bring together different speakers, from UXers, designers, product managers and developers, to give insights across the whole product life-cycle. This series of blogs will go through the trends uncovered during the events.

• Agile Transformation
• Product Vision
• Execution: UX
• Execution: DX