If I have a thousand ideas and only one turns out to be good, I am satisfied.
Alfred Nobel
A year and half ago I left the consulting world and began working at a product company.
It was an exciting move, and I was very quickly thrown into the world of software development, a world very different from the one I had left.
I was given a word of advice from another UX designer already working in the company early on.
'Just keep ahead of the developers, if you get behind with the wireframes you are dead'
The products were very technically complex and the interaction challenges considerable. I started creating some fairly hi-fidelity wireframes, presented them to the dev team then spent the next day having them explain to me why the technology would not allow me to do what I wanted.
It was at this point I realised this was never going to work. I needed something else.
As a person, I have always been someone that needs to talk and draw through ideas for them to make any sense to me.
Creativity and new ideas came from the the connections I made when I sketched or discussed the issue.
I went back to my colleague and asked about trying to work visually together with the developers.
I was quickly warned:
'Developers will never draw - they just want to code'.
Deep down, I didn't believe this, more over I didn’t want to believe this. This did not remind me of the developers I had worked with previously. I was determined to give this a try.
So I took baby steps. Things were rocky in the beginning, but once I started, enthusiasm grew very quickly. Now, developers come to me and ask when we are going to 'sketch and stuff'
Enter Design Studio
I first encountered a form of the Design Studio methodology in Architecture School.
The premise was we were given a design challenge, produced a set design alternatives, got feedback (sometimes harsh - it was called 'crit' a shortening of critique), then modified the design and repeating the process.
Using my Architecture School experience as a base, the method I use today has been inspired from the works of Will Evans, Todd Zaki Warfel and Jeff Gothelf . I could never have succeeded with out reading their ideas on this subject. Standing on the shoulders of giants.
I have used Design Studio method in any situation were I want to generate a number of ideas, get feedback, prioritise alternatives then converge on one solution (s).
I have found this method very effective within the Agile process when User Stories are employed to manage development work. User stories establish good boundaries that complements the Design Studio process well.
User Story -
All development work for product development is done using creating a backlog of User Stories, prioritising this backlog then working on each User Story using Kanban principles. Product releases occurred every month
Since I view the creation of the user stories as the first part of the design process, it is important that these are well developed and appropriately granular.
At the beginning of each User story I facility a Design Studio with the development team, Development Lead and Product Manager (not always possible) to kick the User Story off. This is the ideal group since Design, Product Management and Development are all represented.
From my experience this method as a number of key advantages:
Improved quality of ideas - by getting the technology issues up as soon as ideas are considered the overall quality of the design solutions is higher.
Communication - since the entire dev team does this together a common understanding is created through the process.
Insight into other persons processes - The points where everyone shares their work-in-progress are often inspiring. The participants see an idea spawn further ideas, which in turn, spawns additional ideas. By seeing how different people with different backgrounds attacked certain problems allows everyone to broaden their range of solutions.
Sketching
When I have done this with any new group I usually spend time talking about sketching. Sketching is not art. Sketching is getting your ideas out of your head and on to paper. Things dont have to be perfect. If you can draw some basic shapes anyone can sketch.
I usually like to have people sketch on A3 size papers divided into 6 panels. This works well for describing flows and the panels are big enough to comfortably draw most things.
I encourage people to use rather thick markers so as not to go into very many details. I have tried Sharpies, but prefer Pental Sigma pens instead as they are more common in Europe and don’t smell as much. I let people use regular pencils, highlighters and various colored Post-it notes to add the rough details they need.
Design Session
Total time: 2.5 hours
This is an approximate structure that has achieved the best results in the context or my organisation (your milage may vary).
1. Introduction to the user story and any related scenarios. I spend about 15 minutes setting the stage, reviewing the user story and background. I prepare the room by posting on the walls any relevant personas, user tasks maps and interaction patterns.
2. Iteration One - individual sketching. 5 min. Each person sketches as many solutions as possible in this time.
3. Critique/ Feedback - consolidation. 3 min per person. Each person posts their sketches and presents the designs. The rest of the group gives feedback.
4. Break - At this point about 90 minutes has passed. Time for some Swedish coffee and a break.
5. Iteration Two - group consolidation: at this point it is usually possible to consolidate things into 'design themes' that represent some major ways of thinking. Depending on how big the group is and the number of themes, I will break members up into smaller groups. Each group is tasked to work on a specific design theme. I have the group appoint one person to draw then give them a time to refine these designs into one (or as close as possible). 5 min
6. Group presentation. Each of the remaining group presents the refined design to the rest of the group. Usually after a discussion the two (rarely more then two) designs can be merged into one design
By now we have converged on one design that will address the User Story.
I find that letting things settle over night then meeting again the next allows people to reflect over things and any issues to bubble to the surface.
Design Studio - Task Break Down
Task Development - 1-2 hrs
Once the design is established we meed a second time within the group. Before this meeting I have documented the design in a lo-fi format (Balsamiq/Omnigraffle or clean sketch) and then meet the entire team once more. During this meeting the team then goes through the design and breaks it down in the necessary technical tasks.
1. I begin by posting the final design wireframes, user flows and personas on a wall. I then give the team 5 min to come up as many tasks and dependancies that they can.
2. Each member then begins to post the tasks they have identified next to the relevant area of the design or user flow on the wall.
3. Once everyone has posted their tasks then these can be discussed and consolidated to what will be implemented.
4. These final set of post-it notes is then transferred directly onto the Kanban board to be planned.
At the end of this process, the team has generated ideas, developed a design for the problem and broken it into technical tasks.
Design Studio repetition -
The first few sessions with the development team where tough. It was a new way of working with methods unfamiliar to most of them. As time went on, people became more at home with the techniques and I started to see the sessions themselves begin to develop with less input from me. Certain background information was no longer needed and the later session could tackle more difficult problems at greater detail. Once people are familiar with the process, it's fast and efficient to work through a design challenge and generate great solutions. The team was developing.
I realized I had achieved my goals when the team then started to automatically schedule multiple design studio workshops into every User Story - without me mentioning it !