What’s Christmas without a Christmas tree? The smell of pine. The twinkling lights. The proud focal point of any festive living room.
But – if your house is anything like ours – look beyond the glitter and you’ve probably got a mish-mash of ropey old tinsel and baubles in every possible colour, shape, and texture, that you picked up at multiple Christmas markets.
(You’ll probably also have at least one ugly ping-pong ball bauble made by your kids or left over from your childhood. Is it a snowman? A snowball? An elf? Who knows).
Ultimately – it’s an aesthetic freakshow.
And your product may be the same.
It may have a heavyweight dev team. It may have thousands of paying users. It might be a commercial success. But most products grow over time in an unstructured way with features added like baubles to a tree.
Ultimately, they end up looking – and feeling – out of control.
Does that sound familiar?
Here’s how feature baubles find their way onto the tree and how to avoid it.
Senior management said we had to have it
If you’ve ever worked for someone who’s been to a conference and got over-excited by something new and shiny (that has nothing to do with what your users actually need) you probably know how common it is for that highest-paid person to decorate the tree with their totally unsuitable baubles.
In fact, they may not even know they’re doing it, as de-railing products can be inadvertently embedded deep into the fabric of how your company operates.
It’s a pervasive problem, but we’ve shared some of the hippo-taming techniques that have worked for other product professionals.
User research has suggested a need
You may have done some user research, but still not really know what a worthwhile sample group of people want. There’s a danger of adding something on one user’s whim.
Conducting good research – in the right way – really is the most important part of keeping your product on track.
We talked about it in the context of the beginning of product development recently over on our Product Leadership Podcast, but good research is a skill you’ll use throughout the entire life of your product – it should be the backbone of every decision you make about the features you add.
No business gets worse because it learns how to listen to its customers well
Sales staff have said ‘everyone wants this!’
As long-term readers will know, we’re all about your frontline staff being the ones to generate your best ideas because, let’s face it, they’re the ones who know your users better than anyone else in your organisation.
However, ‘users keep asking for it’ doesn’t necessarily mean you should rush to add a feature. Remember the cautionary tale of Twitter and the edit function.
Users may make a big clamor for something, but it’s important for you to consider the potential for adding huge amounts of complexity without the corresponding value.
It’s also about assessing whether the users’ solution is the right one. There may be a genuine problem but there might be an even better solution that your users wouldn’t be aware of or are even capable of thinking of.
(By the way, if you’re struggling to steer things in the right direction, our podcast on juggling product priorities will give you some useful ideas about finding your focus and keeping to your roadmap.)
But, how the heck do you redecorate a product?
All of this feature creep will have left you with a pretty ugly tree. A product that’s grown organically like this will rarely have had a good UX / UI plan in place.
Obviously, a redesign can’t fix every problem but it can certainly start to make sense of the mess for the users and bring some consistency to your tree.
So, how do you go about doing this?
Just as a good development team will use a research-based, agile approach to manage their product roadmap, you can take the same approach to your product’s UX and UI.
Breaking down your application into components will allow you to create common design patterns that can be rolled out across the platform, section by section.
It can’t all be done at once, so don’t risk taking on that monster.
By gradually building a consistent design language that sits underneath everything your development team will have a toolkit they can use to push out beautiful, functional new templates and features time and time again.
Over the next few months, we’re going to be exploring this agile UX approach in more depth, sharing case studies and demonstrating how it can help you derisk any redesign.