How to Build Solutions That Don’t SUCK!

A lazy man’s approach to doing the bare minimum when it comes to design

There’s nothing quite as soul destroying – as you grind in the corporate machine, powering the capitalist engines of modern life – than having to do so with systems that seemingly were designed and implemented by barely sentient sacks of potatoes. Whilst consumer technology constantly iterates and seeks to make the user experience intuitive and interesting; as soon as you put your TikTok down, and logon to your work laptop, it’s like stepping back 20 years.

It’s a fun exercise sometimes to imagine yourself as a thrice-divorced, chain-smoking, deadbeat IT teacher whose own children have started referring to your ex-wife’s new boyfriend as “The dad they never had” – and then to critique the information systems you have to use every day as if they’re half-arsed GCSE group projects. Let’s be fair – that’s what it feels like sometimes. I saw an electronic patient record system once that would denote deceased patients with a tombstone emoji… Hey, at least it wasn’t in comic sans…

We need to be kinder to ourselves and expect more out of life. So many digital solutions SUCK – and we deserve better!

‘The Method’

I should really be packaging this up into a video tutorial series and companion self-help book – that could be yours for the small price of $99.99 – but you’ve caught me in a charitable mood so I’m giving away the secrets for free. For this one time only. All it will cost you is a like on LinkedIn. Maybe a follow. Maybe a cheque. Whatever feels good.

My method is quite simple and follows these 3 Golden Rules for success:

1. Do the bare minimum you can get away with
2. Assume everyone is an absolute idiot
3. Don’t say anything about rules 1 and 2 and pretend you’re a genius who works harder than everyone else (see also ‘How I Built My Career on Lies’, the new best-seller from Matt Heys, available to purchase soon for the small price of $99.99)

I split my methodology into two main sections – design and development. Ok I guess there’s also implementation but to expand this blog to cover user-training and change management would breach Golden Rule 1 and I pride myself on being an annoying pedant rather than a hypocrite.

Design

There are 3 things you need to consider here:

• •What actually is it that you’re building?
  • This sounds so basic – but well – you’d be surprised how many projects don’t actually have a proper definition. Let’s build a ‘Resource Mapping and Allocation Management system’ – great, sounds cool…what the hell is it?
  • Forget about ego – ask the stupid questions – look clueless – make everyone question your intelligence and professional credentials – it’s better than nodding your head and keeping face, only to realise you’ve got no idea what you’re doing later on whilst rocking back and forth in the corner questioning your life choices.
  • Can you define what you’re building in a sentence? If you can’t, you’re overcomplicating it at this stage.

• Who are your users?
  • You can make this section seem fancier by calling them personas. Whenever you get chance, say the word persona. It doesn’t really matter if it personas in the right place, as long as personas think you’re personaing the personas and persona your way to the visage of persona greatness.
  • Avoid detailed backstories and creating your own lore. I don’t care that this persona is Jessica, a marketing executive who lives in Dover and is afraid of rabbits. The only thing that will come out of that is a subconscious drive to make everything in the solution as ‘rabbity’ as possible.
  • The exception to this rule is if you base personas on your colleagues. Then it is your right – no – your duty – to make up as much foul stuff as possible. “This is Steve, hated by everyone, with an unshakeable odour of rotten cabbage – oh and he does HR or something, that’s not important.”
  • Please. No. More. Superheroes. Thanks. Bye.
  • The most important thing here goes back to Golden Rule 2 – Assume everyone is an idiot. If you meet someone who says “I’m a massive geek too, I love all this computer stuff” – this is a huge red flag; this person has never used a computer in their life. Side note, I find these people the most fun to make up words around. “Well, it’s gonna take a while – we need to jump-start the CPU crank shaft, and add some more teraflops into the RAM – as well as the EWE and maybe the LAM(B) too – you don’t happen to have a can of teraflops on you, do you…?”
  • Just write out a short list of the different roles who will be using the solution, and how technically capable you expect them to be.

• What do they want to do?
  • Call these user stories and bag yourself another reason to list yourself as a ‘Product Design Specialist’ on your CV
  • Again, as little detail as possible. I take issue with user stories that explain why a user wants to be able to ‘create milestones’ in a project management app – I’m fairly sure that user wants to be anywhere in the world but work. Probably laid in bed, doing their best to dissociate from the absolute garbage-fire that is global politics and cursing the unending plethora of bile that is existence. Just me…?
  • Capture the essentials of what your users need to do.

Summary

Ok, so I did say there’s two parts to ‘The Method’ – design and development – however, I think this is a good time to refer back to Golden Rule 1, and to be honest, I’ve written over 1,000 words so I think I’m good for now. If you want to see my insights on ‘Development’, and heck, maybe even ‘Implementation’, smash that like button and leave a nice message about how I’ve inspired you. Flattery works very well as a carrot for me.

It may seem like I’m just being glib and droll with my golden rules but actually they are things to live by. Doing as little as possible doesn’t mean doing nothing – in fact, it usually means doing more than what we normally do. So many projects get going without a proper direction. The principle of doing as little as possible means surpassing this to get to a point where everyone’s pulling the same way. Likewise, assuming everyone is an idiot may seem mean and elitist, but you shouldn’t assume people will understand what you intended with system design. Sure, you’re going to hit that small button hidden in the header that looks like a pencil sharpener when you want to create a new request but how is anyone else going to know to do that.

See, I can package some interesting insights into what seems like incoherent and unprofessional ramblings. Either that or I’ve just wasted your time reading this and pretended to round it off into a sensible message (see also ‘Plausible Deniability: How to Get Away with Being a Jerk at Work’, the new best-seller from Matt Heys, available to purchase soon for the small price of $99.99).