My previous post was about balancing problem definition against design and implementation. The balancing act doesn’t end there, though. Even after defining the problem, there are usually multiple solutions to choose from and each of those can be considered complete with varying levels of functionality.
The goal is to deliver a well-balanced solution that offers just the right amount of functionality. There are easily dozens of decisions about the design and implementation that can throw the balance off. I’ve seen and fallen into a few patterns where these design and implementation tradeoffs didn’t quite balance.
Too Much Left on the Punch List
Some teams (engineering, design, or product) push back on basic functionality to cut down on initial effort. For example, the design requires the user can create an object but, to save a few hours of work, we’ll defer implementing rename, delete, or edit until later. They argue that these are easy to add later and the engineering team can always make these changes manually, especially early on when there are few customers.
No matter your role, it’s tempting to accept this argument. As a product manager, you can fit in an additional feature. As a designer, you are freed up from considering some design details. As an engineer, less code means fewer tests and fewer bugs. (OK, maybe it just means different bugs. 😉 )
Don’t fall for the argument. Returning to “completed” features later after the product has grown is harder than it seems. Eventually, what would have been fairly quick to add before becomes difficult as the team loses familiarity with that area of the code or, worse, changes are made only to uncover surprising dependencies and new bugs (“What? That name could never change before!”).
Omitting such basic functionality, even if you expect people will rarely need it, can lead to your users:
- feeling they have an unfinished product
- frustrated by attempting to find something that’s not there
- frustrated by the need to contact support
- abandoning that functionality or the entire product
Teams often cut corners when they doubt that the functionality is here to stay. Perhaps the product vision is unclear or there has been a recent pivot that undercut trust in the vision. In that case, you either need to convince the team that this work is going to stick around or you need to do the researching, testing, or experimentation needed to convince everyone (including yourself) you’re on the right track.
It’s easy to overcompensate in the other direction and build unnecessary or low-value functionality. Obviously, doing unnecessary work consumes development time better used elsewhere. Gold plating also risks:
- complicating the user experience
- additional documentation or training effort
- creating a maintenance burden
- additional customer support
Finding the Balance
The performer finds balance through feedback, practice, and experience. Designers achieve balance the same way. The tightrope walker knows when they’ve fallen off the tight rope but it’s harder to know when a design is off balance.
Trying out design ideas with users is critical to get early feedback. As they use the design prototype to complete realistic tasks, are they using all the functionality? Are they missing functionality? What can be removed? What must be added?
As useful as usability testing is, it can’t replicate reality. It’s important to monitor how the design performs in real life. Luckily, we have a many tools at our disposal:
- Usage analytics tools like Heap and Pendo
- Customer support feedback
- User research – interviews, observation, surveys, etc
How much time you put into collecting and analyzing data depends on the size and importance of the feature. However, in order to improve your experience, you need to do something. Learning from each balancing attempt will help you get the balance right earlier in the process and spend more time finding new problems to solve.