As of today, I’ve been involved in Web and UX design for 12 years. The last three of them have been shared with my partners at Continuum, leading UX projects for a wide range of clients. It’s impossible not to notice certain patterns on how user experience projects wind up, regardless of the scope, the team size or even the deadline and the budget.
These patterns, and the continuous iteration on how to better deal with them, have led us to identify some principles that pave the way to a better experience design. We’ll talk about them in a future post. But first, let’s talk a bit about the most common problems we have faced when doing UX:
Feature creep
This is a well-known problem. Too many stakeholders with similar power positions trying to inject their own vision, insecurity and fear of being the poorest competitor and a lack of prioritization lead to products stacked with functionality that has not met real user needs.
The main assumption behind feature creep is that “if it’s in the product, users will find it”. If this were true, certainly we could make more useful products by simply adding more stuff (that’s the way Microsoft Office was conceived). A better understanding of our users’ limitations and lack of interest in our product makes the team feel the painful need of simplifying and prioritizing.
Google Docs understood this, and they basically offer fewer features but with the big differentiator of sharing and real-time editing. By replacing barely-used functionality with a game-changer offering (plus a free price tag), Google Docs has become the only real threat to Office in two decades.
Deadline creep
Products launching way past their original deadlines (and sometimes even becoming instantly obsolete when launched) is also a documented issue. Besides from feature-creep, the second most common cause we have observed is a constant back-and-forth between the team, where decisions are reversed/undone until the very end and noise is introduced as new stakeholders join late to the table.
The underlying assumption behind deadline creep is “this moment is as good as any other to pitch my idea.” We try to get past our original assumptions as early as possible. From then on, the driver for new changes and pivots should solely be user feedback.
Something that has worked for us is to start the project negotiating with the client deadlines for key decisions and mutually agreeing that these deadlines will be respected, regardless of who shows up later with ideas. Deferring changes until they can be balanced with user feedback is another good technique; get used to saying “that is a great idea, we can include it in Iteration Two, after we have launched.”
Products that solve no one’s needs
Pressure to meet budgets and deadlines already exhausted by theoretical discussions and power plays slowly disconnect the team from the users and their needs. Sometimes the connection was never made in first place, and entire products are built based on overconfident hunches or late-night inspirations that crash painfully and expensively.
We as humans have a tendency to live in denial of things. Sometimes the reality is too harsh, so we exclude ourselves from it to prevent it from spoiling our dreams. This might be ok for our personal realms, but it’s fatal when developing products that are intended for other people to use. That’s a pain that can be postponed, but never avoided. The earlier this pain is welcomed on the project, the more useful it is, and the less damage it causes.
Sometimes you have to be harsh, even at the cost of losing a client. Our role as UX leaders is to uncover value and create it where it doesn’t exist. But you will sooner or later face a lost case: a mix of a really bad idea (or a good idea with terrible timing) and a delusional team or founder. In these cases, saying “sorry, we believe there’s nothing we can do to make this product useful” will keep you honest to yourself and to your client. Sometimes this slap in the face earns you extra respect and even encourages the team to reconsider.
Incomplete or defective research
Sometimes we, as UX researchers, trust our gut too much and take shortcuts from meeting an appropriate number of real users and extracting the right insights.
In some cases, an excess of emphasis is put in validating an abstract idea instead of a real solution; in others, too much effort is put into polishing specific controls, losing perspective of the overall value. Our very experience can get in the way if we are not disciplined enough to contrast and challenge all of our assumptions with proper user feedback.
It is important not to work alone as UX practitioners. When there’s a team, it’s harder to keep a bias, because your teammates will remind you of where the project should be focusing. Even you will have a heightened need of objectvity. This is probably because it’s far easier to see biases in others than in ourselves.
Gap between design and development
Designers and developers often view themselves as separate entities: design “feeds” development with designs and specs, and development implements them mechanically, without questioning. But a UX professional cannot unbundle herself from what’s being implemented, because that’s where the actual experience for the end user is going to take place.
Handing the design to someone else and then forgetting about it causes the experience to break apart; value is not transmitted to the ones in charge to make it a reality. Designers and developers are equally responsible for the user experience. Doing it right takes a lot of communication and a willingness to be mutually influenced towards a unified mindset.
Embrace Agile UX at the development phase. Bring a chair, sit down next to the developer and work in pairs. Free the dev team from having to make user interface decisions; be ready to respond in real-time with graphics, new screens, error handling and copy. This is probably the most overlooked phase in a UX process, and it’s by far the one which produces the most tangible results for end users. All those “little big details” that make you fall in love with products exist because someone cared for them long enough to make them appear.
Tendency to Waterfall UX as a way of reducing uncertainty
An approach to UX too close to the academic, the bureaucratic and the theoretical is self-satisfactory: structured, thoroughly executed methodologies are rewarded, regardless of the results they produce or their impact on the end user.
Projects take forever to complete and the team is lost making reports and Gantts look pretty to the board, instead of being in the field, trying, failing and observing. The focus is diverted from effectiveness to mere compliance. Sometimes it’s the client, bound by regulations and standards, that pushes it this way; sometimes are the UX practitioners themselves, trying to validate their work with name-checking and blind following of established practice.
Whatever the cause, everyone —the users especially— will benefit from a flexible approach, rich in tools but always listening for what the project needs, and more reliant on direct feedback than processed and standardized reports.
Keep an obsessive focus on the end experience — don’t let the methodology blind you. Your end users will never see or appreciate your process, they will only see your results. Nobody says “wow, what I love most about this product is that the team got Agile values totally right.” That’s what you would say about it. Don’t lose sight of your users.
All of these are problems because they ultimately make the user experience suffer. A good UX management maintains the team focused on solving real needs and being effective, from the start to the end. It calls for a holistic involvement; as a UX lead, you can’t really disengage any stage of the project, as all of them involve being in touch with users and fine-tuning the output.
That’s why at Continuum we strive to keep our projects as close to Lean UX as they can be. This is not only for the sake of efficiency, but also because it’s the approach that makes the best use of our common sense and our flexibility as a team. In a future post, we’ll discuss the principles that guide us down that path.
This is a post by Sergio Nouvel, partner at Continuum, a UX, innovation and software boutique. He’s also co-founder of Get on Board, a job board for digital professionals in Latin America.
Give feedback about this article
Were sorry to hear about that, give us a chance to improve.
