Keeping things simple

I questioned the need for a piece of functionality this week. It was a casual thought.

Do we really need that?
Perhaps we could have it in a later release?
Is that a must-have or a should-have?

This meant being willing to re-do a little of my work in the UI and being willing to say goodbye to many hours of thinking and designing. I was rocking a rare ego-free attitude. Admitting that I may be wrong to have given the feature so much thought.

The product owner I was speaking to immediately said, ‘Yes, do we really want to spend £X on this feature?’ The number he provided was eye-watering.

I knew that development could be expensive, but I never fail to be surprised by how much things cost to develop (and particularly to test) within financial services. In this case, I was really surprised. He may have been exaggerating for effect, but ultimately it gave me a good insight / reminder.

That UX Designers have a duty to keep things as simple as possible, to explore the MVP, to focus ruthlessly on things that hit the sweet spot between user delight, business value and technical feasibility. Only when we do that, are we supporting the right kinds of exploration and elaboration.

It’s easy to dream up lots of screens, fancy interactions. Simplicity is hard won. In large organisations, simplicity can require a work of genius!

Simplicity means, amongst other things, being confident enough to produce less output. To spend months and months on a project that only delivers one additional page, or a set of minor changes. The design time can be spent in:

– helping the business not to do things
– helping the tech practice to avoid edge case complexity
– helping with off-line processes that impact the experience far more than changes to the UI might (e.g. removing or reducing processing delays)
– reframing design problems (e.g a request to add cross-selling, might be better reframed as a new product that includes both feature sets)

I was reminded of one of my first UX gigs – where I ended up spending months and months designing a complex permission-based workflow. The product died a year after it launched. Mostly I think the client didn’t manage to sell the thing. As a product it wasn’t solving a genuine need. But it was also a beast to code – and was suffering performance issues when it launched.

I didn’t have the experience or the courage to recommend an MVP approach… but wish I had. Such wasted hours. So much stress to get it live – and for nothing. We could have learnt that the product wasn’t going to sell much much sooner – and no user group would have wanted the level of complexity that we had dreamed up.

It’s surprising that I still need reminding of all this. The pressures are hard to resist. Wrong thinking is everywhere (in me and outside):
– Thinking of projects (instead of products / services)
– Getting fixed on solutions (instead of exploring interests)
– Jumping to conclusions (instead of staying with uncertainty and thinking / researching / designing for a little longer!)
– Too little / too much collaboration (instead of a nice effective mix of collaboration with time working in pairs / solo)
– Following trends / competitors blindly
– Being drawn towards sexy / interesting solutions (everyone wants to build new shiny chat-bots, instead of the unglamorous boring bits of design)
– Too much time dreaming (instead of making things that go into people’s hands – even developers get over excited about the possibilities – and underestimate how long it’ll take to actually deliver things!