Five maladies that may plague your product and how to remedy them
What ails your product and what you can do about it
Regardless of how good you, your development team, or your designers are there are various maladies out there that may infect your product and bring its progress to a screeching halt. In this post, I am trying to articulate some of these problems I consider to be bad, impactful, and frequent together with possible remediation steps.
Minesweeper
This problem is exactly what it sounds like — your users literally are not sure what step to take to avoid blowing up. Typically, this will happen when the team rushed too much through implementation to make a date or did not put enough thought into the workflow. As a result, users have to be very cautious when using the application for the intended workflows and can only stay on a known path or otherwise face the risk of the app crashing and losing incomplete work. The “explosion” can take many forms: the application performance slows down to a crawl; loading the data on the page or in a control takes forever; the application becomes entirely unresponsive or you end up with a blue screen of death situation.
You may hear a more innocent variation when you or someone from the team is demoing an early version of the feature and you have to develop a script to follow to the letter so as to avoid any sort of landmines. While that is perfectly fine for an early iteration or a demonstration of progress, it is a sure way to a disaster for a released feature.
Possible remedies:
- Investigating how your users operate in their environment to understand different interaction points through contextual inquiry and customer journey mapping
- Keeping in mind that a task or a flow always exists in a larger context and relying on that larger context when designing a feature or a set of features
- Well-defined user workflows either in text-based scenario form or via charts together with an indication of related flows
- End-to-end testing from the beginning of a flow till its completion
- Exploratory testing that focuses on taking the unbeaten paths
Goldberg’s machine
Rube Goldberg’s machine is a very complicated way of getting a simple thing done. You can find more information here. The gist of this plague is over-complication or overengineering in UX design or system design. In system design, it may take shape of premature optimization for large-scale traffic and having a cache on top of the cache when there is no real need for that.
In the product I worked on for a few years, we ended up suffering from this plague because of a rather complex architecture that kept growing over time leading to performance issues and instability. Unfortunately, the product is still suffering from that even today.
In UX design, this plague may manifest itself through an incredibly cumbersome UX, a choice of inappropriate controls for a particular action, or an unnecessarily multi-step workflow.
Fabricio Teixeira speaks to the topic in this article (see an example of a bad control for the task below)
Possible remedies:
- Recognizing John Gall’s law that all complex systems that work have evolved from simple systems that work (nicely described by Jorge Arango in this post)
- Avoiding premature optimization in design and implementation until you really need to scale
- Understanding known and widely adopted practices in UX before jumping the gun on redesigning stuff in a bold new way
Little wonders you would rather avoid
Did you know that there is a term for a door that gives you the wrong signal of how to open it? If you did — you are a step ahead of me because I had no idea they are called Norman doors! If you want to learn more, this article does a pretty good job explaining the concept.
You have probably seen it plenty of times in various products including your own. It may take different forms with varying degrees of harm. The key indicator of this plague is that the system is giving you mixed signals about what you should do or what the system does in response to your action is surprising and definitely not in a pleasant way!
Possible remedies:
- Reading Don Norman’s “Design of everyday things” and Alan Cooper’s “Inmates running the asylum” hehe :)
- Conducting usability testing on features as you are building them or concept testing before you are building them to avoid confused feedback after the release
- Investing time in understanding best practices for UX writing (especially in dialogs, prompts, etc.)
Leap of faith
If you grew up in the 90s like me, Speed might have been on your top movies list. One of the most epic moments is when the driver, the bus, and all of the passengers have to take a leap of faith to cross a 50 feet gap due to incomplete construction work. They make it of course and no one dies (which is obviously good).
When it comes to products, the driver making the leap of faith is your user. A typical example is when the user has to jump between two or more different forms/screens in order to complete a single task and what is worse, there is no obvious connection or navigation between them.
Possible remedies:
- Investing time into the business process and user workflow analysis
- Documenting identified workflows at least in some fashion and making sure those artifacts are known to the entire team (dialog map could be a good technique when it comes down to UI in case you have already defined some sort of a process-based flow)
- Researching and getting familiar with the concept of information architecture helps to organize things more logically (following Jorge Arango could be a good first step here)
Not all that glitters is gold
Somewhere I heard that many of us in the product space are sick with a dangerous disease and its name is “featuritis”. I was surprised to find out it is in fact a recognized term
Some of the worst cases have become world-known anecdotes
In a nutshell, this problem stems from the idea that addressing a market issue, competition or dwindling demand requires adding new features (and the more the better). Another possible root cause is a belief that the number of features is the fundamental evaluation criterion that drives sales. An associated belief is that if a feature is requested it will be used hence all features in the product will be used as all have been requested. Often enough, featuritis will be showing its ugly face in sales-led organizations where features represent checkboxes that need to be ticked to be considered in a bidding process.
This becomes most challenging when providing a new product in an established market where “feature parity” with competitors or legacy products being replaced is the ultimate goal.
A lot has already been said on the topic (Melissa Perry’s “Escaping the build trap” is probably one of the finest reads) regarding the what, the why, and the how. To me, the key reasons why featuritis exists are fear and indifference. On one hand, as a product person, you are afraid to say no or challenge a request to do something very specific that lacks justifying evidence. On another hand, you do not care to challenge something or you don’t care to dig deep enough to have your own Eureka moment regarding the problem or the solution.
I really recommend reading 37signals’ “Getting Real” (my visual notes on the book are available here) which speaks to underdoing competition as a strategic approach to product development that allows for keeping the product simple and maintainable.
Possible remedies:
- If you suffer from indifference, your best bet may be to consider changing companies or professions. If it is fear, a good approach can be to talk to others and ask for advice. Developing a good relationship with your manager and being discreet is a step in the right direction too
- If there is no way to measure the usage of functionality available in your product across customers, you will almost never be able to get pickier about things to build or not to build. You can invest time into collecting empirical feedback by engaging customers as a starting point but that is likely to stop being scalable past a certain point.
- If you can present any stats on the share of features in the product that have been used once or never together with financials on what it took to build them and the opportunity cost of what got dropped to get those done you may have the attention of your stakeholders
- If you do proceed with adding more features then the dimension you can play with is the depth of the feature aka the number of supported scenarios and performance targets. If you do not have evidence of the feature’s need then a good rule of thumb could be to make it shallow so as to avoid significant investment and have a guardrail mechanism to hide/expose it. This practice however can lead to another serious plague of having a zillion of configurations and the insane testing effort related to that but that is a story for another day
- Improving interviewing and problem-framing skills to ensure that a fundamental need behind feature requests is clear before choosing to build a feature
If you made it this far in the post, please clap, leave a comment or follow my blog.
