I don’t need your design process

Sometimes, you question whether you’ve just been winging it for the last ten years. That’s usually when you’re surrounded by people you’re supposed to have an affinity with, but they’re all talking about something you think you should probably understand but quite obviously don’t. Worse than that, perhaps you’re supposed to actually be doing it, since, well, surely that’s what you do. That’s what I felt like a couple of hours ago.

I once applied for a senior user experience designer position for a software company in Cambridge. The only sticking point, in their mind, was that I didn’t have any Agile experience. I won’t labour that point, because I have already, suffice to say, despite my protestations that it really wouldn’t be an issue, because I’ll still be able to function if for some reason we have to stand up on a Tuesday morning, it was the one thing I couldn’t honestly say I could tick off their list. I couldn’t adopt their process. I didn’t get the job.

This is ridiculous to me. As a designer, I tend to go through a process. I tend to take a problem, try to understand it, and try to solve it. By design. There’s usually more to it than that, but, really, not much. I’ll put my hand up right now. I could not articulate the difference between waterfall and agile, if questioned. I’m not even sure if those things stand up to comparison on common criteria. I’ve seen the lean UX manifesto and been talked through it a few times, but it’s still just the good bits of UX, without the bad bits. If you want to throw in kano, keynote, kelloggs, that’s fine, but it won’t change the way I approach a problem. I might find that some of the tactical methods are useful, helpful, more efficient. I might loosely adopt some strategies and roll them into a framework suitable for the task at hand. I might find that faced with a hill, just skiing down it is the most appropriate thing to do.

But I won’t pick a process. I’m fine with the one I’ve got. It’s not wilful. I don’t doubt your process is appropriate, effective and successful. I just don’t need it. But thanks for sharing.

4 Responses

  1. To me methodologies are not about solving the problems, they are about ensuring our solutions actually see the light of day. It's about communicating / managing the build team.

    You haven't solved anything if it doesn't get shipped…

  2. I totally get that. I just don't feel a need to prescribe a particular methodology to achieve that. Blind adherence doesn't necessarily solve anything either (thanks for providing that phrase).

Leave a Reply to Tim Caynes Cancel reply

Your email address will not be published. Required fields are marked *

Make somebody else read this

Archives
Categories