November 2nd marks the twentieth anniversary of my debut into the professional world of work. Back then, I was only a few months out of university, driving a library van of all things, when I met a guy at an IT recruitment fair. He’d just taken on an large IT consultancy project with a used car retailer and was using this to kickstart a business. Having got nowhere with recruitment agencies and other graduate schemes I decided being his first employee was worth a punt. It was my big break.
Over the years I’ve worked in five different roles, spread in a mix of IT and digital and in different industries. I’ve had a think about what are my main learnings, and if I had the chance to meet my younger self before it all began here are some of things I’d share.
IT is like Shrek; it has layers
The cornerstone of my early days was an ability to write code. I was self-taught, not really learning a great deal at University strangely, while working with Visual Basic 6.0 in my spare time. That helped win my job and then Classic ASP, SQL Server and latterly .NET programming followed.
Over time, these skills served me well but the delivery route today for an app or system is quite different nowadays. The low level skills once used to build or deploy and application are now automated; indeed, many job roles in software development have disappeared altogether. More precisely, that detail work we used to have to depend upon has been abstracted into new mostly-automated processes.
I’ve learnt that it’s vital to keep your hand in the tech as much as possible. Take nothing for granted, but take it with you. What you knew yesterday will build upon tomorrow.
Users are fickle, crazy and lazy
In all aspects of digital and IT, there is an end user. Someone for whom a system, product or service will support. I’ve learnt that there is a direct relationship between the effort spent with users during a project, and the quality and acceptance of the finished result.
There are always challenges; users will take any shortcut imaginable, jump ship when the latest shiny thing comes along and try and break anything they can. They will do things to an application you’d never even have thought of in a month of Sundays.
Also important is that as a rule, when a user contacts you to say “it’s broken”, with no other detail or explanation, they’re no longer engaged and thus more effort is needed to bring them back. Don’t leave them out in the cold.
Software developers are (mostly) rubbish at UX
Well, most of them are. I worked in one team where we used to produce a lot of user interfaces for other colleagues in our business to use. But we never had any training, most of us taking our cues from Windows dialog and tabbed settings screens. These had typical techie elements such as frames, tabs and dull grey backgrounds.
What I came to realise is that we were developing user interfaces that we, as developers, would either want or need to use. The early 2000s Windows design language provided a structure that seemed logical and more suited to those used to advanced server management. It didn’t cater to regular, less experienced users, and we never spoke to them either.
As the internet grew in pace I began to experiment with Windows interfaces that mimicked web pages. This was quite a good tactic, deploying white backgrounds and images for controls on the forms, giving way to handsome displays that were reasonably usable. But it was years before I worked with any front-end creative designers, and once I did, realised how valuable they are and how much I’d missed out.
The moral of the story is to talk to your end users early. Workshop your product with them and consider carefully at every stage what their ideal user experience should be. The user interface, or UI, should simply fall out of this process.
The importance of time in creativity
At many points in my career, I’ve had to work to deadlines. They’re not easy to meet mainly because your capacity to work fills all the time available. A month, a couple of weeks – it didn’t matter. As a developer, even if you weren’t coding up to the last minute, you’d be testing as much as possible.
Deadlines aren’t necessarily bad things. You can’t work on something forever, even if budget isn’t the issue. In my first job, my boss used to do a clever pitch where he’d promise a 4-week delivery time to clients. This was often met with surprise, yet did help win a lot of business – we even received calls from competitors once or twice I recall, roundly criticising this seemingly unworkable approach – but we would base ourselves on-site with the client with two weeks to go. This meant we could, if needed, blur the deadline but work with the end users to tune the system and bring them with us on the journey. It was highly effective. Even now, at the point of delivery, I find myself just hanging out with the users.
However, I’ve been in different scenarios where we’ve had that “need a website in 2 weeks” phone call from a client. Your time is so limited, there’s no room for creativity let alone thinking about the end user. These products would always be disappointing, full of bugs and invariably we’d still be fixing things after go-live. Give your digital teams the time they deserve.
Business change is everything
My Computer Science teacher at Secondary School once said that IT is nothing to do with computers. It’s about people; you’re either assisting someone in what they are doing, or, more soberingly, replacing them.
Even if your UX is spot on, you still need to bring the people with you. The go-live day is when the real work starts. I think back over some of the key projects I’ve worked on across the years and the sheer effort expended after a project has gone live is incredible, particularly where a system or product has dramatically changed what users have to do. Plan the end at the beginning.
I don’t like HTML emails
I’ve also considered what I’ve disliked in my 20 years, and there was one period where I was working on HTML branded emails for clients. I’d take a layered image and convert it to a HTML web page – quite good fun sometimes in fact – before writing code to loop through a long list of recipients and email it to them. Bulk email campaigns are easily achieved with code, but as I come to learn, it was dead easy to make mistakes.
Once, before sending a small branded campaign – while already bruised from a previous one that hadn’t gone well – I did some extra testing with Mac users at the last minute. I made some changes to get it to work on the Mac, not knowing that, following the change, I’d made the Windows/Outlook version unreadable. And then boom, one upset client with a miniscule number of happy Mac users. How about forgetting to clear down a previous distribution database and send a newer mailer to the old list? Check.
Thankfully, GDPR and data protection controls make things a little easier to manage, but I got fed up of explaining why they’d always appear in Spam or Junk folders to account handlers. Adding links to manage unsubscribes then made the emails appear like phishing attacks. No, there’s nothing good about the HTML email; it’s a lazy, ineffective and horribly old fashioned way of “trying” to reach people. I’ve long hoped Apple would introduce a ban on them but actually, they are a big proponent of HTML mailers…
Thanks for reading. Here’s to twenty years more!
Digital Is Not Rocket Science 