There are many buzzwords in today’s software development landscape — UX is one that comes to mind most when we think about the product experience customers get to feel.
Without a doubt, good design is more important than ever in the age of perfected, clean, beautiful interfaces, the age when customers expect nothing less than an intuitive and beautiful design.
Coupled with the right product and market segment, good design can, and often does help drive conversion.
Last year I was asked to join a new team tasked with using out-of-the-box thinking to grow our business. That kind of thinking meant a lot of development team-driven experiments and extremely rapid iterations.
A quick search on the internet on “UX design process” will reveal a series of steps — user research, user studies, interviews, persona creation, etc.
While the UX philosophy often helps businesses create the right thing at the right time — from my experience it’s not always the right answer.
A lot of my team’s projects are extremely small, iterative tests and enhancements, most of which can be implemented within a single sprint. The value of getting something out into market and learning from the metrics far exceeds the benefits reaped from the UX design process that is often preached.
Example Case Study
Problem: Customer has a hard time finding a way to navigate to a page with additional details about the product.
Hypothesis: Link to navigate to the additional page is located poorly, and is not visible to most customers.
The obvious solution from a developer standpoint: convert the link into a button and improve the placement. Such an enhancement can be hypothetically in production within a couple hours. By the next day, we can start observing the metrics to see if the change drives improvement in the customer experience.
From the UX design philosphy, such an implementation is not ideal. The UX design philosohphy tells us that we should first research our users and try to understand whether the reason they are not looking at the details page is due to the link. It’s a valid claim to make — that being said, doing the said research and user studies and deciding on the proper action would take more than a day. Reaslistically, it’s unlikely that the customer would benefit from that approach for at least a week.
So which should it be?
A) Quick iterations, bypassing “proper” design processes, allowing the team to fail fast and learn quickly?
Or B) taking the time to do research and contemplate on the best solution for our customers?
There’s no right or wrong answer. For “SWAT-type” teams tasked with ourside-of-the-box thinking and solving problems quickly, the answer is irrevocably A. For teams tasked with redesigns and creation of new products, I would almost always go with B.
Good design process, sometimes, is no process at all. And we must use the right process for the right type of project.