Open Source UX – part 1

Since my new world of open source collided with my old world of experience design, I’ve been giving a lot of thought as to how the principles of both can co-exist. I used to be surrounded by what my former employer LBi refers to as Experience Architects, and now I’m surrounded almost exclusively by open source developers.

As a starting point, I thought it would make sense to try and state the problem.

Good experience design revolves around a few key principles, in my humble opinion. One person or a small number of people should take responsibility for the experience. The experience should be designed independent of the underlying software, as far as possible. End users need to be incorporated into the design process, through effective use of personas, timely user testing, validation of any assumptions, and an effective iterative process (as far as is practical). And the responsibility for the experience should last until the release of the final product – the buck shouldn’t be passed to developers when coding starts.

Then there’s open source. For the purposes of this discussion, let’s assume that we’re not talking about a traditional development process, with a closely bound, established team, who just happens to be publishing their code under an open source license at the end of the project. Instead, let’s suppose that the open source developers are outside the enterprise, possibly in more than one country. They could even be working on a pre-existing product (such as TiddlyWiki or Ubuntu).

Put in these simplistic terms, the problem isn’t a particularly new one. The pitfalls of a traditional waterfall methodology are there to be fallen into. If a solution is designed by one group and then thrown over the wall at the developers, it doesn’t matter whether they’re in the same room or on the other side of the world. I believe it’s essential to build software incrementally in an agile fashion to minimise risk and allow users to provide ongoing input throughout the build.

I think there are three keys to success in this situation:

• Ensure that those designing the experience remain responsible for overall delivery right up to the end.
• Ensure that those responsible for the experience have an open dialogue with the developers throughout the build. Use WebEx, use video conferencing (Skype, iChat, MSN, whatever) use Instant Messaging, use VNC, pick up the phone, send screen grabs, send screen casts, whatever it takes. Both developers and experience designers need to fight hard for a common cause; building the best possible experience in spite of the geographical separation. There are loads of communication tools available and there is simply no excuse for not trying.
• Ensure that those responsible for the experience maintain their open dialogue with the end users throughout the build. The experience guy or gal must bridge the gap between the user and the developer.

I mentioned in a previous post how the innovation process can be stopped dead in it’s tracks if the user experience is too tightly defined. The distinction that needs to be made is that TiddlyWiki is an evolving product, but when a specific need is identified for an evolving product then the experience design process should and must kick in.