Cristian Tituleasa, UX/UI Designer at METRO.digital shares some valuable insights in the following article about Product Design, stating that building products and doing UX work is never a linear or static process.
Enjoy the article and we are happy to announce that METRO.digital will join us at DevTalks Reimagined 2021!
Speed will always reach a point at which UX work cannot be completed any faster while still maintaining quality. That takes into account people’s skills and the maturity of the organisation’s product development processes.
The aim for optimal results shouldn’t be an excuse to put processes in place before thinking of the benefits a suboptimal practice can bring. Tradeoffs need to be considered all the time.
At any point in a product’s journey, look for that balance. Maybe in the beginning you sacrifice some quality by engaging in discovery with less users of your product than needed. Perhaps you will not ask all the right questions or do it with the rigour it deserves.
To that I say consider where you are and where you want to go.
Is this a good moment to get your foot in the door, plant your “research flag” and establish a good practice? Be mindful of the risks, then do it as good as you can.
Experience is the best teacher.
Your users will understand that you care about them. They will feel part of the process. The stakeholders will value the collaborative approach. Getting buy-in for the process goes a long way towards that quality you crave.
My latest experience with this approach comes from the M|Transport solution. The software helps employees from METRO.digital plan and deliver orders for the shop’s customers in the best possible way.
For enterprise software with legacy development practices, UX work can be slow at the beginning. We started with baby steps: two users for a field study and a couple of remote sessions for user testing and feedback.
The approach and initial results got us buy-in from stakeholders. That led to an improved process, increased understanding of how people use our product and even remarks like:
M|TRANSPORT is one of the most beneficial tools, has positive impact on our processes and customer satisfaction. Mitja Kroschinsky, Head of Delivery Business, METRO.digital Germany
We really like the new timeline and map overview, it is refreshing and rescaling automatically so we can always track our drivers without manually adjusting the view. Delivery team, Store Wateringen, Makro Netherlands
From middle ages we jumped directly into future. Easy to use by all stakeholders (including drivers). Madalina Iancu, Head of Delivery, METRO.digital Romania
As the fruits of your labor ripen, a gradual switch can be made towards better processes. Our goal should never be disposable research or UX work. Methodologies such as “Lean” and “Agile” when implemented fully, incorporate users at the core of a collaborative and iterative development process.
Once processes are in place and the ball is rolling, don’t forget to also include the team. The desired experience of using a product is not the sole responsibility of a couple of people. It doesn’t matter if the job label is UX designer, product owner, tech lead or whatever else. It’s a prime example of the saying “The whole is greater than the sum of its parts.”
It’s easy to miss something as an individual. There are sadly, examples of tragic product design where the balance should have tipped towards quality. Healthcare or the aviation have some stories that makes you shudder.
Imagine a patient’s life depending on proper health monitoring software. In one case a chemo patient died because the warning on the screen signalling dehydration was barely visible. The nurses were too busy trying to figure out the software they were using, so they completely missed it. The result? She died of toxicity and dehydration.
To reach the needed level of quality, the aim is to have a cross-functional product team, responsible for both discovery and delivery. Even if some team members like the product owner and product designer spend most of their time on discovery, and the engineers spend most of their time on delivery, all should engage in both activities.
How do we tell the product development processes have matured?
Once the balance is found we don’t have a speed vs quality problem anymore.
To get to that stage a team needs to go through the journey, see the benefits and internalise the value. That is done best by measuring the impact. Let’s look at that part next time.