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:
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?
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.
What do you think?
Comments
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:-)
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.
This person would be well placed to explain which suggestions make the cut and why, with specific reference to the impact on the experience.