How do we deal with “Framework Fatigue”?

Naroth Murali
DBS Design
Published in
5 min readDec 31, 2019
“I’m looking for something that spreads butter on toast well…”

If you’re reading this, chances are you know that exasperating feeling when your teammate or boss tells you the following;

Hey check this out, it’s called the “Multi-Facet Idea Canvas” and Company X uses it for their workshops. I’d like you to try this out next week with the team!”

Depending on how many frameworks, processes and toolkits you have at your disposal, and how effective you are with them, you’ll feel like either framing this one up or torching it. There is an obsession with trying out new tools that standout companies use (Google is using this, let’s use it too!) or creating templates that have very niche application (cheesecake life cycle mapping anyone?)

Framework fatigue occurs when tools have control over how you work, rather than the other way around.

Simplify.

“The simplest explanation is most often the most correct”, is the principle behind Occam’s Razor, credited to William of Ockham, a 14th-century philosopher and theologian. His way of making deductions by selecting those that make the least assumptions, inspired other writers to coin this term.

In the context of this article, tools, processes or frameworks that are the least complex or make the least assumptions, are likely to be the most effective.

My research team conducts periodic off-sites to get away from our daily routine and work together on processes, to build on our overall proficiencies. On my first off-site, my enthusiasm led me to pitch a couple of new tools for us to start using, one of which was the Jobs to be Done (JTBD) Forces diagram. I wrote up a word document on how to apply it, and we plugged it into our growing list of research tools. Fast forward a year, and it hasn’t been used once. Not even by myself. Why is that so?

“Maybe I forgot about it?”
“It depends on the type of project and stage in design process…”
“I’ve used it during synthesis, but not in a report…”
“I frame it in a different way most of the time..”

Responses from my colleagues gave me some sense of what was going on. The complexity of the tool was prohibiting them from using it in its intended form, so they were modifying it to fit their needs.

Figure 2: JTBD Forces Diagram (jobstobedone.org), what I thought my team needed
Figure 3: JTBD (intercom.com), what my team actually needed

The difference between Figure 2 and 3 is typically the struggle I face as a researcher when I read up on new frameworks. They sound amazing in theory, but sometimes perform clunky in practice.

What I’ve learned is that simple concepts allow us the room to creatively express our research findings, in the way and form that we want to. They also give us space to communicate them in a way that we deem appropriate; just like how my teammates ended up modifying the framework to fit their own needs.

Experiment.

It’s a blessing and a curse to have so many individuals and organisations contribute to the growing list of “ways to think about design”. Where do you start when you have so many to choose from?

IBM: LOOP framework
IDEO: HCD Framework
British Design Council: Double Diamond Framework
McKinsey: 7S Framework
Eric Ries: The Lean Startup Framework

If you read through this list, you might observe notable differences in approach. When put into practice however, the differences become more subtle. “Make” and “Build” start to look very similar, and so does “Test” and “Validate”. Are these just semantics, or is there something deeper?

The fact is that companies have created them to address their own set of challenges, and they are not cookie-cutter solutions to the work that you and I do in our own industries. We also need to acknowledge that they are marketing their processes to increase their legitimacy in the field, and secure future work.

This is where framework fatigue starts to set in for me; my mind starts to seize at the variety of options available. So where do we start if we are befuddled? Pick one and experiment!

In the initial stages of formulating UX metrics for our team, we used a modified SUS (System Usability Scale) to focus on nailing basic usability aspects of our products. After a period of time, we realised that this method was not benefitting us because our usability scores were consistently high.

How do we measure the impact of UX?

We then experimented with a modified version of the Google HEART framework to expand the scope, and mapped it onto our bank’s internal KPIs after noticing some neat overlaps. It was risky because we didn’t immediately have access to some metrics, but it gave us an opportunity to witness both the usefulness and shortcomings of these processes.

Adapt.

“It is not the strongest of the species nor the most intelligent that survives. It is the one that is most adaptable to change”, said the venerable Charles Darwin.

While I’m not advocating that we try every new process that our favourite Medium writers suggest, I’m a firm believer in figuring out how to make some of them your own.

“I’m still looking for something that spreads butter on toast well…”

Looking at the list of research tools that my team has at our disposal, sometimes makes me feel like being in that store with all those knives on display. I feel somewhat daunted by the variety of ways to approach the work that I do.

But what’s great about being in a team is being able to share and discuss the work that we do. A practice that we have is tagging our tools according to the stages in the design process we feel it’s most applicable, and documenting how they were used on a report-level, for the reference of everyone.

We also run our research plans by each other to get feedback on the intent, method and tools before executing, and share our findings with one another after, for a second round of feedback. This culture is invaluable in building confidence and showcasing how we adapt tools to each of our unique research studies.

The Way Forward

What I’ve come to understand is that framework fatigue is a necessary evil, and one that will faze even the most seasoned researchers as they are confronted with new and creative ways to seek truth.

Being a competent researcher means being able to pick the right tool for the right job, and that is something that can’t happen without experience and skin in the game. I do feel like when all else fails, taking my time to simplify, experiment and adapt methods to the research I need to do will work in the long run, and I sincerely hope it does for you too.

--

--