Wednesday, 19 September 2007

Open source experience design

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.
This is pretty simplistic stuff, but this is only a blog posting and not a book. I'm encouraging my team members past and present to join the debate via response to this blog posting.

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.

What do you think?


Dug said...

Well yeah... absolutely.

I am currently trying to figure out the best way to overlay the JJG abstract-to-concrete experience model onto a big telco's waterfall process.

One of the hardest things to explain to the armies of middle managers who ultimately make or break this type of process is that the IA (or EA if you work at LBi or heck, why not UEA while we're at it...) needs to be involved from the inception of the product right through to ultimate delivery and beyond.

The challenge I'm struggling with now it that in a large organisation you are often working with people who have little or no knowledge of what the IA does. Co-workers need to find a box to put you in and in the current thinking, none of the available boxes spans the whole product lifecycle (well, sort of)

Anyhow, I'm a big follower of the value co-creation teachings of CK Pralahad and V Ramaswami and find open source methodologies to be a good support for productive relationships based openness, dialogue and transparency.

Sounds a bit bollocksy but open source is the only culture I can think of where transparency is built in to the core (in that we all publish our work to a cvs for all to see)

Curious to see what responses you get:-)

JayFresh said...

Ok, so for me the best bit is that you really encourage the communication bit in as many channels as possible. That's something that in my experience people don't often get done very well. I've found people pick one or two channels and then stick with those, even if they don't provide sufficient coverage.

FND said...

One of the major issues with user/community feedback, especially in open-source projects, is to make sure that it's actually harnessed effectively.

There needs to be a transparent system of receiving, collecting, processing/evaluating and ultimately implementing these suggestions.

If that is not in place, valuable input will likely get buried and people are discouraged from contributing ideas.

Phil Whitehouse said...

@FND: Perhaps the best person to gather and process feedback in a transparent fashion would be the person responsible for designing the experience in the first place.

This person would be well placed to explain which suggestions make the cut and why, with specific reference to the impact on the experience.

Andy said...

I think there's a lot of value in having your developers understand the value of a design - why it has value as a product, why the experience is relevant to the user. Communication not only needs to happen early and often between design and build people, it also needs to happen in a way that can enhance the quality of the end product and the happiness of the team.

James said...

Phil - This is an excellent topic that you've brought up. With my role as an application delivery manager the past couple of years, I've had ample opportunity to set development priorities. Unfortunately, I've never placed that high of priority on the actual experience design, versus core functionality that always seemed to have a moving target given the ambiguous nature of requirements that are the norm in my job of intranet web apps. With at least one example of an application failing its goal because of lack of user take-up, I have a much better appreciation of experience design now then ever. How to push the UE on deliveries managers like myself will not be easy, but we have to start somewhere, and the earlier the better!