In the final year of my design education, I had to complete a 9-month long Final Year Project (FYP). Through this project, I was expected to demonstrate my conceptual and technical abilities honed over the last 4 years. In the midst of it, I made a huge blunder that sent me into panic mode: I only began to test my assumptions and hypotheses 6 months into the project. And they were all proven wrong.
With 6 months worth of hard work on my left hand, and research data that contradicted my hypotheses on my right, I had to throw away something.
I threw away my work.
Last week, I shared on what is essentially the Art of UX, covering key technical aspects of the practice as well as a simple conceptual model for understanding the entire process.
This week, we’ll explore the Heart of UX as I share my opinion on a few important traits that a UX practitioner should possess. I will then conclude with an interesting concept called Design Debt. It may all sound preachy, but I believe that this sort of conversation is necessary for professional growth and development in this industry. Are you ready? Let’s go!
In the story that I shared earlier on, I admit that I briefly considered the possibility of conducting more surveys and interviews with carefully tailored questions, so I can skew the results towards a more favorable direction — to justify not starting all over again. I’m glad that I didn’t - it was a lesson well worth learning the hard way.
If you have collected research findings and tried compiling them, you might have felt a sense of power knowing that your analyses can directly affect the design direction. Your interpretation of the insights gathered can also skew opinions. When you face temptation to downplay certain usability issues and elevate others using a deliberate choice of words, resist!
It does not matter if your analyses go into a disseminated medium like a formal report, or just a simple list that you use personally to track usability issues. If you’re not careful, you can end up deceiving yourself.
In an ideal world, we would save every finding, turn them into actionable items and pass them to the development team. Unfortunately, what actually happens is that we often find ourselves ranking them, based on scales that we design ourselves.
I hope you can see where I’m going with this; there is every opportunity for us to manipulate research data and sabotage the process. We need to wield this power responsibly so that people can have confidence in us, and this is especially important if you’re trying to evangelize UX in your organization.
There is a saying that goes:
“Don’t fall in love with your design.”
Sometimes a spark goes off in our head and we come up with an ingenious feature that could make the user’s life so much easier. We back it up with usability principles; create a perfect flow with our wireframes; ride on the magic of UX and finally convince the product manager to push it for the next release, because why not? The solution is so obvious.
Obvious. That’s a dangerous word.
“What is obvious to you
may not be obvious to others.”
I’ll be the first to confess that I struggled with humility during one of my first couple of testing sessions. One of the test participants could not locate the “Add Report” button that was screaming for attention at the top-right corner of the screen. I managed to resist all temptation to point my finger at it, and scribbled some notes to capture that observation. Phew.
As we gain more experience in this field, we become more capable of making good design decisions instinctively without the need for extensive testing. With the accumulation of design patterns into a pattern library, it may seem like we can take on any UX problem in the world.
Except that we can’t.
A heart of humility is required because at the end of the day, what we’re doing is learning about our users. Pride and arrogance will make us discount what our users say. Don’t get complacent!
The essence of UXD is to understand your target audience. If you ever walk away from an observation or interview feeling like you have not learned anything much about your user, something is terribly wrong.
And that’s why you need to be flexible. You are the conductor and you decide what, when and how you use various methodologies and strategies to orchestrate a successful UX schedule.
For example, you can make changes to many things halfway through conducting a usability testing session. Rewrite a task; add a task; remove a task; change your prototype on the fly, whatever. Remember, these are just tools that are meant to serve you. If your UX process is constrained by some rigid rules, you’re doing it wrong.
Finally, there is a concept called “technical debt” in software development:
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
The equivalent of Technical Debt in UX is taking shortcuts, like skimping on UX activities. You’re happy with getting just the low-hanging fruits with one or two usability testing sessions, and dive straight into development for the next few months. While this is okay for short and small projects as proof of concept, full-scale complex systems with thousands of users cannot afford to take this approach. Simply because of this truth,
“One design decision leads to another,
and then another.”
Of course, it’s not always possible to test everything. In most cases, teams run out of budget, and you have no choice but to make design decisions based on untested assumptions. When that happens, let every single person in your team know, from the bottom to the top. Yes, it should make you feel awfully uneasy going ahead with an implementation based on shaky grounds. However, making sure that everyone in the team is cognizant of it will help prevent your debt from spiralling out of control.
This ends the series on my reflection of UXD. It has been a wild ride ever since I stepped into Usability Week, and I hope some of my sharings have been helpful to you.
We talked about the Art of UX in Part 1, where we used a simple conceptual model to help us understand the entire UX process better. We also probed a little deeper into one of the most popular UX activities, prototyping, and how it could be used for more than just showing work done.
Then, we went into the Heart of UX in Part 2, dealing with some necessary traits that the UX practitioner ought to possess and nurture, and finally the concept of Design Debt that could trip us down the line if we’re not careful.
Here are some additional reading that explores the ethics of UX, a growing discussion around the practice that we all should participate in as the industry matures: