About 15 years ago, when the internet was new, I worked directly with the newly appointed CIO of a large Swedish organisation. My role was to facilitate the development of a ‘Internet Strategy’ for the company. No small task, but it was just the internet, how hard could it be ? To assist me, we had enlisted the help of a very large consulting company.
The project was one of my most successful, but not really for the end product but more for the process that was we used. The process comprised of a great deal of interviews with stakeholders, but also with a number of end users. We conducted collaborative sessions with the team to discuss and prioritise outcomes, develop the strategies and make a number of ’Straw Man Proposals’ to discuss and modify. I was particularly struck with the value of 'Straw man proposals ' in that encouraged the team to think in terms of 'unfinished' that could be iterated upon.
I remember thinking at the time:
The results we are developing are so much better and robust then I, or any single person could have developed on their own.
When I reflect more on this I realise that we were ‘Designing the Business’ around the strategy for the internet. The project ended the discussions and workshops ended. Sadly. We delivered a slide deck and a report, and then nothing happened. Without the continued discussions the new Strategy we created stayed in the slides wilted and eventually died.
I was reminded of this a recently, when Josh Seiden mentioned something during a presentation at the Lean Event
Fast forward a few years to today
I left the CIO group and transitioned from Strategy to User Experience. That shift for me was to move to an area where I could have a greater impact on the end-user.
The organisation I work with recently expanded. Up until know, I only had to worry about how to manage the UX across product teams that were co located in Europe. In the future this would include two product teams in the US as well. After the first few meetings between the individual teams the inevitable questions popped up:
How do you want the dev team and UX to work together…?
First, I was happy the wanted to work with UX as this isn't always the case, but further on I felt I had a hard time answering this question completely. Things progressed even further and soon terms like like ‘process diagrams slides’ were being used.
This is when I began to panic (sort of).
I have been very careful to not really document ‘a UX process’ since I dont believe one process or method will work for solving all problems. I also feel that documenting like this implies to some people that it has to be done this way I have tried to keep things general by discussing Discovery and Delivery in a previous post. So far this has served us well, but I could see that for that the discussions with the new team would require something more.
In the end I describe things this way:
The product UX process will need to include a few key conversations between team members (PM, UX and Technology). These conversations need to happen, it is just a question of when and how. In my experiences workshops are effective ways to facilitate these conversations and deliver valuable artefacts. The artefact is not the important part of the creative process. Shared understanding of the product needs is the real deliverable.
I explained that we have a ‘tool box’ of methods that we use to facilitate these conversations, depending on the goal.
We conducted a number of very productive sessions with the new team that resulted in a common view of the solution and very good interaction designs. No one ever mentioned a 'UX process diagrams' again.
In both of these situations -one designing a business strategy and the other a complex interface - the problem space was very complicated and conversations were key to collaboration.
Without continued conversation, the artefacts of our designs slowly loose their value as time progresses.
Lets not let this happen and keep on communicating.