Ramblings about Design, UX, Process, Code... basically where my thoughts go when nobody else is listening. Est. 2009.

Decision Fatigue and the Retrofit Mentality

Decision Fatigue is the concept of a person attempting to make a decision between more options than their brain can process – resulting in no decision at all. I wrote a bit about this earlier, but I've been ruminating more on the topic.

UX Myths has a great article on the relationship between features and options and usability. I recommend anyone interested in the topic to give it a read. My biggest takeaway is learning about Hick's Law. Hick’s law states that the time it takes to make a decision increases with the number and complexity of choices. And as the decision time increases, the user experience suffers. This can be used to design menus or entire workflows.

Any UXer can agree that optimizing for this is a good thing... but there's another layer to preventing excess cognitive load and forcing design fatigue on users: desiging with iteration in mind.

Designing with Iteration in Mind

Are you Agile? Are you Waterfall? Doesn't really matter, because design has to happen all along the way - whether you're designing everything up-front for Waterfall or you're desiging changes as you go with Agile, the effort for careful design consideration throughout the feature build lifecycle is important.

I'm currently working in the travel and booking eCommerce space. Complex booking workflows, redeemable points systems, managing timeshare exchanges, multiple levels of user privelidge, and integrations with 3rd party sites like Orbitz or cruise lines. Every conversation around enhancements of the current products generally revolves around addition of new features or adding additional functionality. It's never 'let's take this feature out since there's already a lot going on'.

The biggest role anyone can play at a company is to be an advocate for your users. There are excellent reasons why one would want to add a feature to a workflow. One of the core principles of Agile methodologies is to launch with your MVP and then enhance it as you go... so don't get me wrong, I'm not against iterative design. Based on my experience inside large companies, however, relying on future releases to be flexible is dangerous.

Planning and Roadmaps and Iterations

In an ideal world, everything on the backend would be modular, every step along the way would have designs, and releases happen regularly. Let's get real for a minute, especially with waterfall methodologies. Rarely, waterfall companies have a clearly defined roadmap for all features they want to add over the next year or two. Usually, there are large blocks of time for a project name and we'll figure out the requirements document when we can. Even more rarely is the roadmap accompanied by interim design solutions, whether wireframes or full-on designs, that match up with the staged release schedule. This is assuming you release features to production more often than twice per year. Let's call this tendancy to just add another button or item to the end of the menu a 'retrofit mentality'.

In reality, backend work, service calls, or APIs are built with a certain understanding of how the website / software needs to work. Architectural choices are made every project weighing between what is so robust and abstracted that it's a waste of time and what is good enough for this release and doesn't break. A UX professional needs to be OK advocating for redesigning a page, moving items from one step to the next, or even even creating new steps in the workflow. It's easy to be bullied by development teams that will have to refactor existing functionality to move things around "just to keep the user happy".

In defence of development teams everywhere, their poor backend architectural choices may very well have stemmed from poorly defined feature roadmaps. If they knew features in a hotel booking workflow may need to change as the product matures, they would have written their services and APIs to be more flexible in the payloads they deliver to the page.

Avoiding the Retrofit Mentality

My biggest recommendations are: Have a plan. Be transparent with the plan. Design for every step of the plan. Be ok with timelines changing so that features can be done correctly. Use tools for getting out of this horrible loop. It doesn't matter whether its charts in a Microsoft product that live in a shared Sharepoint environment and links to wireframes in InVision, whether its in your due dates in JIRA and Gantt plugins, or whether it means you have a collaborative feature planning platform like Aha, Mavenlink, or ProductPlan. The best plan is a plan that everyone knows about, is on board with, and can easily reference.

Hey There!
What Is This?