Product design: building a product with understanding — part 2

In the first blog (which you should read if you still haven’t), we went over 4 key aspects for starting a project with a clear horizon. Those aspects were:

• Product design mindset
• Core problem
• The scope
• Prediscovery sprints

Those 4 factors are more oriented towards the mindset and the first steps we needed to handle for gathering the insights for good decision-making later in the project. This part two will be more oriented toward the “hard process” and good practices once the agile sprints start. So in this blog, we’ll cover:

• Practicing double diamond
• UX research
• Design collaboration
• The project team shared understanding

Practicing double diamond

The core of the double diamond framework is to diverge and converge, so if we are not following that process, we are basically resisting the natural way of how the brain is capable of producing a better understanding of a specific problem. For this, we need to respect both Ds — Discovery (discover, define) and Development (develop, deliver). First impressions are often wrong because they are made automatically with a small amount of information — it is the brain bug/feature that, in most cases, helps us make decisions quicker. But it doesn’t help us when we need to take a better look at a problem.

Once we get our thoughts out, digest them and talk about them, we can start thinking more critically. By doing this, we will get more ideas, each educated by the one that comes before. As I mentioned, most of the design problems are wicked ones, so we need to put out as many impressions to see where the booby traps are.

As we moved from sprint to sprint on our project, we got a more informed idea of the problem, so if we felt that we must have done something wrong before, we needed to ask ourselves were we able to validate that thing before or did it even cross our mind to do so.

Everything we do is a learning point for moving forward and as we are evolving our knowledge, we change our minds.

This is the inevitable part of the process, so we shouldn’t try to avoid it — rather make the best use of it to practice a critical mindset while making the decisions, even if some bigger changes appear, those might be valuable for producing the right product.

UX research

As I already mentioned, if we take double diamond as a good framework of work (and we should), we can see that it suggests repeating two actions — discovery and development. As a part of our process, we are repeating those two actions so that we can feed the current sprint, but also to feed the next sprint and inform the overall product strategy (a fancy term for “what are we doing here and why”). So, there’s no way we know enough without taking a closer look at each phase/meaningful chunk, diverge in ideas, converge to one that makes sense, design it, develop it and then test it to change it again or apply new thinking to the next sprint.

In choosing the right UX research method for the discovery or testing, three factors are important:

• the budget
• the reasoning
• researcher’s expertise

If we are being realistic about the budgets and timelines, designers do need to get creative with the approach to their UX research and see how to get as much information with the humble resources. This is not always a bad thing, as it teaches us to respect the process because the budget will always be a constraint. But it also challenges us to work within the boundaries, which is actually where creativity comes to play.

If I were to put this into the context of our current sports streaming platform — for a project this big and unknown, we needed to stay real in terms of the resources we have for the research, but also advocate UX research strongly when it matters the most. Those wicked problems are still here and without the experience of dealing with them, we won’t recognize what “wicked” means.

Also, if we manage the problem by avoiding it or by pretending that there’s no problem, it will eventually swim to the surface, and fixing it will then cost us much, much more.

Regarding the method, we first needed to know what we wanted to research in order to be able to decide on a method that might help us. So, once again, we need reasoning to get a good sense of the context and what would be our goals. Some methods are great for the problem space, some are great for the solution space, sometimes we have a product to start with, sometimes we don’t and we are building from scratch — we need to raise the awareness of what we wish to know and what resources we have or could have to decide on a UX research method.

If we can find out something from other research work, why would we invest the time in conducting our own research? If we have the budget for only one or two research opportunities, maybe we only want to conduct the usability testing as a major usability improvement tool and also use it for prior research. Maybe there’s no way to use the best practices because the product you are working on is so unique that we will just need to push UX research onto every phase.

The method we choose should be based on understanding.

This leads me to the third factor — UX designers’ researching skills. Making UX research something that will pay off depends a lot on how well the researcher understands the method. It is important to take in as much know-how as we can in order to get meaningful insights. We can look at picking a research method like picking our first car as a new driver — we might want our first car to be good enough to drive us to different places, but also something we feel OK with wrecking if it happens to be so (with a good intention not to actually wreck it).

If we jump back to the project, we gave ourselves the following advice — let’s use the method that won’t fry our budget and leave us with nothing if something goes wrong. So when we planned the usability test, we went with a smaller number of participants (but relevant ones), we designed and tested the study before we got to the real users as a means of understanding what “expectations vs reality” means in the context of implementing the UX research.

This approach allowed us to quickly start noticing easier ways to get to the relevant insights.

Design collaboration

Having two minds is better than one and three is just as awesome. There’s a lot of work to do when it comes to building a single product, and when you spill your focus across everything that works, the quality of it gets compromised. Our design team recently went through the list of skills we think we should have and gave names to multiple design roles we need to fit in one designer for a project.

A lot of knowledge and experience are needed to make sure you covered all of the components of a project with the focus that they deserve. To tackle this, we practiced having multiple designers in the product team — working towards the same goal, but with different focuses.

We divided the project’s design team into three roles, where two are active in the project and the third is a supervising role. We have one designer that is focused on the UX strategy, research, and high-level architecture, while the other designer is focused on design production, visual design, interaction, and style guide. All of this is supervised by the design lead that was heavily active during the workshop phase and who is “QA-ing” the design production and process.

This allowed us to have a much stronger focus on each part of the process that needs to be properly taken care of, but it also gave us a richer understanding of the product since we all need to know the same thing for a different reason. This approach enables everyone to chip in with their perspective or a better idea — and it leads to a better environment for critical thinking and empowers talking about the problem we are solving.

The project team shared understanding

This aspect comes down to the quality of cross-team communication. Having everyone on the same page is the most important and the most difficult part of delivering a good product. We can use tools like Jira or Trello (we use Jira), but those are only tools — so if you put the wrong information in it or if the information in it is interpreted differently by each team member, then we have a situation.

If you didn’t already watch this, here is the lecture by Jeff Patton on the importance of user story mapping (USM) — what is the real purpose of practicing USM and how to do it properly. This revealed to us that forcing tools without prioritizing real communication leads to a lack of understanding — you find yourselves with a bunch of written words that lack context and shared understanding.

As much as development needs technical specification and documentation, the tool shouldn’t be the focus. For humans, there’s no better tool for understanding each other than a common language, so it seems to me we should practice this as much as we can. We need this practice to start recognizing that we lack the skill of understanding others' perspectives and handling biases as a team.

If we use simple language and explain what needs to be done successfully, this means we understand it enough and, as a consequence, we can talk about it in a much simpler way.

If we can’t say it in a simple way, we might need to understand it better. For us, this manifested as over-engineering the process or the specifications to replace this understanding — with respect to both because those are very important factors.

To sum it all up

Here are a few key takeaways:

• there’s a way we think better about these types of problems and the double diamond process is wired to allow this thinking to happen, so we can help ourselves by using it as a framework
• as a part of that framework, using UX research wisely will help us get to meaningful insight, so we shouldn’t avoid it, but we should be smart and focused while choosing the methodology
• having a wider design team helps with keeping up with the fast pace and delivering better ideas
• if we are forcing tools without prioritizing real communication, that can lead to having just a bunch of written words that are lacking context and shared understanding

Choosing good practices and a reliable process can help a lot when it comes to moving through the project. Remember, we are working on “wicked problems”, and the frameworks we use will either be good for dealing with those or not. To make sure we can feel confident as we are building a product, we can help ourselves by implementing reliable frameworks like a double diamond, but we also need the focus on understanding those and why they are helping us. For this, we need to share a high level of understanding based on solving problems together as a team.

For the end, here are some sources that can give you more valuable insights:

• Beyond the Double Diamond: thinking about a better design process model
• UX Research Cheat Sheet
• User Story Mapping with Jeff Patton (video walkthrough of the USM point)