My very first attempt at incorporating a user-centered design approach in my software development project was, in many ways – an important start for me, career-wise. It’s because of that project that I am where I am now – I would certainly not have been accepted into the MSc, which subsequently opened a lot of doors for me in the UX industry here in London.
But, despite all that, that project was a failure from a UCD and “business” perspective. Firstly, the interface felt too much like Flickr. Then, our team was fairly novice so our interview data wasn’t very promising. This caused the personas to feel sort of half put together. The end result was somewhat lacklustre – in some ways, we could’ve delivered the same thing by getting inspiration from other websites and not having to use Cooper’s Goal-Directed Design.
However, to stop there would be to completely miss the point.
Introducing UCD – the first round might not count
I insisted on using a UCD process not because I wanted to deliver something spectacular, but because I wanted the team members to see the value of a UCD process. Or, perhaps more accurately, it was mainly just me who was keen on seeing the value of a UCD process (and to see if I could do it).
This is where I think a lot of projects tend to reject UCD – when they can’t see any results.
It’s easy to run a company with an “efficiency” mindset – it’s sort of built into the status quo. Everyone is reluctant to change – not just management. So, I didn’t just have problems with my line manager – I had problems with my team members. (thankfully, my interviewees were really helpful). No one except for myself was really looking to see this succeed.
So, of course – how could I expect it to succeed?
The process reveals not so much results, but opportunities
The effort of building applications is often a team effort – not just one UX person calling the shots. But valuable lessons can still be gleaned from UX failures, much more than they can from plain old technical failures – mainly because that additional perspective from the user is so raw and tangible that it almost creates some kind of “why haven’t we done this earlier” response?
When team members get thrown into a UCD process – they don’t realize the potential “failure” of the outcome, they look at the process and the value of that access to users they finally get – something they never used to have in the past. Suddenly, they realize it is possible to build applications based on user research, user feedback, and purposeful design.
Developers and designers all need to realize that there are many ways to build an application, and sometimes it makes sense to learn a new tool so that the right one can be used for the right job. Introducing UCD to a conventional software team can sometimes help them gain ideas to make things better.
I took those lessons I learnt from the failure with me, because you never unlearn an experience like this. You just get better. And now I realize just how much more UCD is like craft than science.
1 Comment