What is a quick fix?

Let’s say a user has trouble understanding an affordance, icon, or some copy in an interface. The team decides to remove it or tweak it with the intention to improve the experience immediately for that user.

Sometimes there’s than meets the eye with a straightforward change that looks like it shouldn’t take more than 1-2 hours:

  • It makes a lot of money
  • An underlying technical foundation thing
  • It is part of a marketing strategy
  • Support has been relying on it to help customers
  • It was shipped too quickly to document
  • Policies, laws, or more capricious client-based constraints

The designer must assess several facets of a handful of pixels, and likely reach out to multiple people (or teams) in order to make an acceptable decision. Being a diplomat is just part of the empathy work for colleagues in a large organization. Then they will iterate, get the design team’s blessing later that week because we hate being left out, and then they will ship it.

Your quick fix now took one week! Time to plan the next sprint!

Quick fixes usually get prioritized higher than bigger issues because they promise accomplishment, satisfaction, and the idea of incremental progress. But once you factor in the communication and collaboration tax–which varies across organizations–tackling the big stuff might not end up taking much longer. What remains is the uncertainty of big ideas stalling or crashing–which could still happen with a quick fix. I wonder if bargaining for and maintaining a balance between the two types of work can happen more easily if a quick fix’s full effort is acknowledged? Or if the bigger work was taxed at the same rate as the quick fix?

By Desiree Zamora Garcia

I like to eat, think, and take things apart.