On delivering

One of the things I struggle with the most in my day to day development work is to deliver early and often. I consider it one of my biggest handicaps that I want to make everything look pixel perfect before I deliver it for review. My former boss used to call it "putting gilded domes on" - meaning everything looked way better than it needed to get the job done.

From a UI perspective, delivering pixel perfect makes sense - the design is the deliverable, so it must look perfect else it’s not finished, right? The weird thing is I don’t really identify as a UI designer. I mean, I dabble, but I’m first to admit loads of people are way better than I am. So I tell people I’m a UX person - which I really feel I am. UX - the process, the experience, the user journey - it has my heart. Funny, then, that my natural urge is to deliver in one big bang, for that’s definitely not “the UX way”. Because in UX, the deliverable is not a design, or a piece of code. The deliverable is the user experience, and the only way to work on a piece of user experience is to let users experience it. And that means getting your work in front of them as soon and often as possible.

And by the way, that goes not just for UX related matters, but for design and development work too. Because more feedback results in a better product. It’s safer to hide behind your screen and try to dazzle everyone with a finished end result, but that’s just being scared.

Focusing on delivering early and often also helps you to always have something to deliver - even if it’s not as polished as you’d like. Consider the following image:

Three sketches of spiderman: one done in 12 seconds, a rough sketch, one done in a minute, a decent drawing, one done in ten minutes, a fleshed out image.

If the product owner / scrum master / team lead decides you should work on another task when you’re halfway done, what option is better: to deliver something rough but working, or to deliver something goodlooking but nowhere near usable? This is real life. It happens. And also: show your stakeholders your work at 12 seconds and one minute, instead of just the end result at 10 minutes. Involve them.

Stakeholders bond less with a result they haven’t contributed to in the process. They are more likely to reject it than if they thought it through themselves. Allowing stakeholders to contribute during the process makes for happy stakeholders when it’s time to deliver.

And it’s not just your end users that are the stakeholders. The product owner, sales reps, devops - everyone that’s involved with the end result would like to have a say in the process. In most cases, for me that means I (sadly) don’t even talk to the end user. The product owner manages that with support and sales teams. For me that means the product owner is the one I should involve in my process - and maybe the support and sales teams too. I have to get their feedback early and often. That’s what makes my work better (and also saves me a lot of commit reviews).

It’s kind of ironic I struggle with delivering incrementally, since I truly see its positive impact on the end result. Maybe its like a bad habit I’m trying to quit. Maybe (probably) it’s me holding on to my ego a bit too much and not being vulnerable enough. I try to change that. Because that’s what UX is, in the end: knowing that, no matter how smart you are, you are not your user. So get them to provide feedback on your work, and they will love you(r work) for it.