The Comparison Paradox
This is a concept I’ve had kicking around in my head and finally gave a name to. if you’ve watched my Podcast with UX Banter, you’ll have heard reference to it there too. Figured I should explain in more detail, in case you wanted to use it too.
the paradox is this:
Comparative research Is the most sensible place to start when solving problems, and simultaneously the worst.
We probably need to unpack that a little.
Let’s start here.
The Natural Planning method.
If you google that, make sure to add the word “project” somewhere. IYKYK.
Natural planning goes something like this:
Define purpose and principles.
Visualize the outcome.
Brainstorm.
Organize the outcome of the brainstorming.
Identify next actions to be taken.
This method works because its how our brains typically try to make sense of problems and rationally solve them. Feels natural... so a pretty apropos name.
The Tech Planning method
The way we plan in Tech and games is… not like that.
It usually goes something like:
Build something awesome.
Build more awesome stuff to accompany it.
Remember that you need to monetize the tech.
Throw in some ham-fisted UI so you can sell it as a product made with users’ needs in mind.
Wonder why no one buys your product, as you go bankrupt.
Yes, yes I’m being facetious I know, but if you’ve been in games and tech, you’ve seen this too.
Comparison
When developers start to feel the pressure of needing to turn their experiments into actual products that can be marketed and sold, that’s when you see them (and the frazzles designers they hire at the 11th hour to contribute years worth of impact overnight, while requesting absolutely NO changes to code) running towards other examples of how similar problems have been solved before.
We’ve arrived at Comparison.
When Call of Duty: Modern Warfare (2019) debuted the Battle-Pass my team and I worked on, we saw a rash of products jumping on the bandwagon, mimicking the design, hoping to replicate its success. I recently played a Game of Thrones mobile game… yup, Battle-Pass in there too.
Same thing happened with Apex Legends and its ping system. Enter a host of projects asking for an “Apex like ping thing”.
They never seem able to mimic the results, no matter how faithfully they mimic the design.
Compromise
Raise your hand if you’ve never had to compromise when taking an idea from conception to implementation.
If your hand is raised, I’d love to talk with you. Even the slightly unhinged Steve Jobs had to compromise to bring his visions to life. That’s why macbooks keep getting lighter and thinner. Why Chipsets get more and more powerful.
We compromise constantly.
Cost of materials (manufacturing) or software/services (licenses, web hosting, backups).
Engines - Content must be built to suit the engine, which will have specific guidelines and requirements.
Timelines (either internal, from publishers or codevs. marketing windows etc).
Manpower - Staffing, layoffs.
Testing - gathering research groups, running tests and compiling results.
Platforms (systems have to be adapted for. PC, console and mobile require unique UX solutions and builds have to be tested on each platform).
You get the idea.
every design or solution you see, is the result of an innumerable number of compromises and accommodations.
The solution you see may not even be the best idea; It was just the one that got shipped.
To reference a design solution and mimic it means you inherit all those compromises along with whatever design you observe.
I’ve seen this play out countless times; teams make the user’s needs, expectations and preferences an afterthought, and prioritize their clever new systems. When they finally remember far too late that games are a customer facing economic product, it’s usually beyond the point of trying to hamstring something heavily referential and compromised.
I often wonder what fear is so crippling that devs prefer this alternative instead of building experiences that respect and cater to players, who are keen to Invest time and attention (money too of course) where they feel heard and valued.
The Right Way
There are no shortcuts. You HAVE to put in the work. Sorry.
Observing a solution (comparative research / competitive analysis) is a great way to understand how its been solved in the past. There may be cautionary information in there to discover.
At best you take away patterns that are generally successful / commonplace yet dreadfully unoriginal.
The most consistent way to get value from this type of analysis is to deconstruct the design you observe. Working backwards, find the actual problems they tried to solve and pick where it was successful etc.
As with natural planning, the sequence looks like this:
Clearly define the correct problem to solve.
Observe similar solutions in various product categories.
Deconstruct implementation. What did they intend to create and did they adequately solve their problem. Define the problem they attempted to solve.
Determine if the solution is relevant to your needs. What parts of it work. What parts are pedestrian and can be improved / discarded.
Based on previous steps, build set guiding principles. E.g. no list should carousel. Skipping cinematics should only require a single interaction. Etc.
Use these principles to begin design exploration.
As it’s probably clear now, this isn’t the easy quick and dirty way of getting a great result. You can certainly get A result, but they often feel derivative and incomplete, seldom consistently great or innovative.
While results may vary, my experience working on over 30 games with various teams has shown me this is how high performance teams work. That’s why they make the big bucks I guess. It’s a great lesson in going slow to go smooth and going smooth to go fast.
Happy travels.
