This post is a continuation to my previous post Thoughts from a UX mentor (part 1). This will list will likely grow.

Critique: Give and accept

Critique is a integral part of the design process.

As a UX designer you will need to effectively give and receive critique. This can be tough, especially if you are on the receiving end of things.

When I was in Architecture school the ‘unofficial’ objective of students in the class was to deliver such harsh critique that other students would eventually drop out. The logic was this led to less competition that way. Yeah, we were young.

Looking back this was all wrong and we really didn’t understand the role of critique in design.

Today, I view Critique as a type of critical thinking. It is a way of determining the direction of a design and how well the design meets the goals. Critique is tricky to do well and there are a bunch of things we should keep in mind to make it effective:

Focus on the design goal

Highlight strengths and weaknesses

People will take it personally (including you)

Remember that this should lead to a discussion

Be constructive.

Resource Tips: Discussing Design, Structured UX Design Critique (Lane Halley),  How to run a design critique 

It is never going to be perfect – get used to it.

As much as you want, many of your designs wont be perfect. There wont be enough time, or budget, or the stakeholders are difficult and want it their way. This is hard for someone that has invested a lot of time in solving a problem, only for the solution to not be fully appreciated.

The navy seal Adm. William H. McRaven sums this well when he describes the ‘sugar cookie’ part of Navy SEAL training.

For failing the uniform inspection, the student had to run, fully clothed into the surfzone and then, wet from head to toe, roll around on the beach until every part of your body was covered with sand.

The effect was known as a “sugar cookie.” You stayed in that uniform the rest of the day—cold, wet and sandy.

There were many a students who just couldn’t accept the fact that all their effort was in vain. That no matter how hard they tried to get the uniform right it never happened—it was unappreciated.’

 

Sometimes your designs will be a ‘sugar cookie’ .

For me mentoring has been a great way to see things from a new (and younger) perspective and reflect over what I have learned in my career.

Mentoring allows me, through the explanation of concepts to another person, discover gaps in my own knowledge (which turns out to be many) and a way of filling them.

Some years ago I discovered the work of Richard Feynman. Feynman had a gift for explaining science that was extremely effective. Feynman also developed a way of teaching yourself new concepts the I have found myself coming back to during mentoring.

Feynman’s method has 4 basic steps :

Step 1. Choose the concept you want to understand. In the case of mentoring this is usually a question from an adept

Step 2. Pretend you’re teaching the idea to someone else. To do this, I need to take the perspective of teaching a new adept.  When you explain the idea this way you get a better idea of what you understand and where you might have some gaps.

Step 3. If you get stuck, go back to the book or source. Whenever you get stuck, go back to the source material and re-learn that part of the material until you get it enough that you can explain in a way and adept would understand. Often times this a book but frequently this also includes conversations with other UX persons.

Step 4. Simplify your language. The goal is to use your words, not the words of the source material. Generally if I find myself using large words I probably dont know it well enough and need to go back  - simple language is the key .

By encouraging adepts to pass on what the know they are are developing themselves and helping others on their on UX journey.

Resource Tips: A great demo for the Feynman technique.

Finally, I would like to thank my three adepts. I have learned a lot from you all.

CMc

For the last few years I have been a UX mentor to some great adepts in Stockholm. When I was first asked to do this I accepted without really reflecting on what being a mentor meant – I have never had an official mentor myself but was just happy to help. I have found the experience to be extremely beneficial as well personally challenging.

During our meetings we discuss a very wide range of subjects that may or may not fall under the definition of UX – design solutions, UX trends, internal organisational politics to the design of restaurant menus.

Through all of this I have noticed that many of these discussions tend to settle around a few major themes. Below are some of these themes together with some my thoughts on the subjects.

Learn how to collaborate.

UX is a team sport.

Gone are the days of 1-2 person teams.  As technologies cover more and more touch points the teams required to develop these solutions increases. Most digital products are far too complex for a single person to know everything (avoid people that say that they do). The more complex the problem we work on gets, the more complex the way we work gets. As a UX designer you will need to lead by example and listen and understand these other perspectives.

Dan Brown, in his book Designing Together defines collaboration with two components:

Collaboration is working together to yield products, not simply creating ideas.

These products are also better then what can be produce by any one person. A group that collaborates has the ability to consider more perspectives and to actually produce the resulting complex products.

As UX designers we need to understand the mindset, tools and culture that cultivates collaboration. The earlier you learn and practice these skills the more effective you will be.

Resource Tips: Designing Together, 42 Rules for Successful Collaboration

Once you start to collaborate you will realise this isnt so easy. One major big problem is that people really dont know how collaborate very well. People often have different perceptions of what defines collaboration. Some people will refuse and sit with their arms crossed while others wont be able to keep quite at all. To make any progress you will have overcome these differences and improve how groups work.

Enter facilitation.

Facilitation is when you help group of people explore a problem. The exploration can involve a final solution or a discussion that increases the understanding of problem for the future (often times both). The idea is not for facilitator to do all the heavy thinking but instead learn to be ‘the quite servant’ and step aside and let the team decide. It is making the journey to the solution or future state, more effective. Designers must learn to take on new roles and facilitate the exchange of ideas between different areas of expertise in order for this to be effective.

Resource tips: Gamestorming, The Skilled Facilitator: A Comprehensive Resource for Consultants, Facilitators, Managers, Trainers, and Coaches, Facilitating with Ease! Core Skills for Facilitators, Team Leaders and Members, Managers, Consultants, and Trainers

Maintain the beginners mind set.

Avoid becoming an expert. Attempt to hold on to the ‘beginner’ stamp as long as possible

Frank Lloyd Wright put it perfectly when he said

an expert is a man who has stopped thinking because ‘he knows.

Beginner traits to shoot for:

1. Beginners ask a LOT of questions – no question is too basic

2. Beginners are open to learning from anyone, not just experts – everyone has something to teach you. Look closely.

3. Beginners make a LOT of mistakes, because they are open to trying new approaches – new approaches are what lead to innovation. Dont forget that.

Beginners are lifelong learners and that is exactly what a designer should strive to be.

In Ashton Kleon’s book Show Your Work he talks about when Radiohead’s Thom Yorke was asked his greatest strength he answered:

Listen to Thom

When I started this post my list of ‘themes’ was rather short, but as I began to think more the list grew longer and longer

..and longer.

All I can say is stay tuned for Part 2. More to come. 

Anyone that knows me, knows I am a large proponent of User Research in the Product Development process.

Meeting Users is the single most valuable activity any product team can do. Period.

I am lucky since I work with a great team that values User Research as much as I do. In most cases when we research I always have the ‘my’ PM and Tech lead join me. We have been doing this for some time and I have never reflected over it.

Recently, I have had another PM ask me:

‘Do you think PMs should participate in User Research together with UX designers?’

My answer was a resounding ‘Yes!’

I view User Research as something every member of the Product Team should participate at some point. The more knowledge about the users that the team has the better the end results. I also find when these different roles participate in the research everyone view things with their special filter and biases.

Business, technology and Design.

No single perspective is completely correct, but together they (hopefully) balance themselves out.

I recently listened to a podcast with Peter Merholz where he stated that the ‘User Research’ function should reside in the Product Management team (min 13:45). In principle, I agree with this, but feel it depends on the UX maturity of the organisation. The less mature the organisation the less likely this will happen. It isnt until the organisation reaches the ‘Design as a process’ or ‘Design as a Strategy’ (using the Danish Design Centre’s Design Ladder) that they are equipped incorporate a generalist User research role. Based on the PMs that I have experience with, it is matter prioritising their time and User Research is something that takes time. I also believe this type of research takes time to learn and perfect as a skill. This happens through practice and I believe to do this well one needs to concentrate on this.

My general research approach is:

1.  Aim for PM’s to attend as much User Research as possible.

2. User Research should be facilitated by a UX researcher or designer.

3. Probably the most important. After each research session have a debrief meeting in order to summarise learnings, draw consistent conclusions and discuss resolutions.

4. Finally spread what has been learned to a wider audience.

DId I miss something ?

I have a confession to make.

I sometimes get lost in Agile projects.

I understand the Agile philosophy but from a design perspective I find it lacking. Very often, I miss the ‘Big picture’. Looking back, I have done many good designs that have ended up being realised as a bit of a ‘Homer mobile’ in the end. I blame myself, but the system has played its part.

In internal discussions, I find myself saying ‘shouldn’t we define this more comprehensively first ?’.

‘We need to look at the entire user flow..’

‘Who is this for and what problems are they solving ?’ and eventually the word ‘requirement’ will slip out of my mouth.

At this point someone will point to me and scream ‘Heretic’ and run away shaking their head mumbling something about Waterfall and the Agile manifesto and the conversation will end.

Recently, I have been reading Jeff Patton’s new book Story Mapping and really cant recommend it enough.

When I read it i thought ‘Finally, someone that gets me..’

Jeff reviews a lot of great methods in the book (LeanUX, Design Studio etc.) but the central theme is Story Mapping. I have spent the last month experimenting with this method and am extremely happy with the results.

Some background: Within our organisation, we have been working theme that includes a set of features that will deliver value but needs to work across multiple projects. The technology and the UX needs to be consistent across these three products. All products are maintained by different development teams and different PMs. The challenge has been to follow the UX and technology development across these products and User Stories.

A real soup.

The basis for Story Mapping is the telling of a story of a user. In this story, the user uses a product or system to solve their problem.

The telling of this story, will allow people working on creating this solution, to have the same understanding.

Lets imagine a future. Lets assume for a minute that this system is live and let’s talk about a day in the life of someone uses it and start telling the story.

First, they would do this, then this, and so on ….’  

This story, will allow people working on creating this solution, to have a discussion. Through this discussion they will define the scope of the solution (big picture), develop the same understanding of the major goals and find any weaknesses in their thinking. 

Pretty basic. Sort of.

Story Boards -

Up until know, I thought we had a fairly good definition of the problem we were solving, but over time I felt things were being viewed from different perspectives within the organisation

In order to align this thinking and so we could tell a good ‘what if’ story I felt we need something more.  To facilitate, this I chose to use another UX tool: the Story Board.

In this case, I worked with the PM teams to develop a Story Board that described what the system would do to solve the user problem.

I centered the Story Board around the ‘Job to be done’ principles. I have found this to be a really effective way of defining the user problem.

Overall I am super pleased with this discussion and the resulting Story Board.

Story Mapping 

The aim of Story Mapping is to tell the whole story – so the first priority is to concentration the breadth of the story and solution.

For practical purposes we needed to have two meetings (2 hours) for the entire Story Mapping session, but ideally it would be better to do it in a single one day meeting.

 Meeting #1

To do this I used the Story Board as a guide and had the team do a 10 min session of silent brainstorming. During this session, the group used the  major Activites of the Story Board and to consider steps that would go into each of these Activities. After 10 minutes the group presented their steps and these were grouped under the appropriate Activity.  This was a very good discussion and some new Activities were discussed that added to the width of the Story Map.

At this point the team was pretty satisfied with the breadth of the Story Map.

Meeting #2 

During this meeting we now dug into the details of each Step the respective Activities.

In doing this, I used a few questions to guide the discussion. Stopping at each step in the process we would ask:

• What are the specific things they would do here.
• What are the alternative things they could do.
• What would make this really cool.
• What happens when things go wrong.

I had the team do silent brainstorming then post their ideas under each Step individually. Each person then presented their idea and thinking to rest of the group, followed by a discussion. Once each person (6) posted their ideas we had a discussion within the group.  We consolidated some of the details and placed them in a of prioritisation, the higher priotitised details closer to the top .

The end result was a quite large Map that outlined the entire solution that would guide us through the development.

Conclusions

I was very pleased this this method and I received a great deal of positive feedback.  The major benefits:

• A well discussed common understanding of what problem we were solving and how a user would solve this with our solution.
• A clear image of what each Product needs to contribute to the solution, and where these connection points needed to be. This was extra-valuable in our context.
• A scope that made the Interaction Design much easier over the entire flow of the solution.
• A large number of holes in our thinking were uncovered. Numerous technical challenges were identifued that would need further investigation.
• We should have done this some time ago. I am glad we did these session now but  really felt this type of session is the most valuable when we start a development effort. Definitely more appropriate in the initial Discovery stage of a project.

Finally, I would like to thank Jeff Patton for a comprehensive well written book.

Recently I have been eating dog food.

I found it had a frustrating first taste, but was nourishing in the end.

Let me explain.

The expression ‘Dogfood’ generally refers to a scenario when a company uses its own product. ‘Dogfooding’ is a way for a company to demonstrate confidence in its own product and from a UX perspective to test the usability of the product. 

In my UX team I have the good fortune of having members that work with documenting the products and creating education courses we offer for these products. They are involved in the design process and document the product as changes are made.

During the documentation process, they need to take the perspective of the user and explain how things work. 

Or not.

Recently, after doing a very large change to a software product we were in the process of preparing a training course and it became obvious that there were some serious inconsistencies in the user flows. After being faced with these misses, the team was able to make some new designs and some fundamental improvements to the interface that ultimately lead to a much better product. Although this process was painful (bruised ego) I stood back and tried to learn from this. I found it rewarding in a couple of ways:

Early Testing -

We try to develop training courses shortly after or when significant changes to the product are made.  If you have ever had to give a course on a subject you know you are required to know your subject matter very well. If you dont, you really cant explain it someone else. In this case, the exposure to trainers and other ‘super user’  users that are far more crtitical then more typical users provided some very good testing early on.

Credibility - 

Lets face it, Dogfooding also builds credibility with your customers: it shows the world that the company stands behind what it makes and what it does. It is the equivalent of ‘putting your money where your mouth. I also think this is a very important quality for a design team to have.

Sympathy -

By using your own product you gain common experiences with your customers. This allows designers to see the world through their eyes which is the only world that really matters. The added benefit of working with trainers is that you also see the product through there ‘pedagogical eyes’. After all, if if you cant explain a product that is supposed to be  designed well, there is more work to do.

I am very glad to have documentation and training persons involved in my UX team and that this type of is a regular part of the design process. Furthermore  if you can get used to the taste, I view ‘Dogfooding’ as a valuable complement to User Research in developing a better understanding of how the user perceives your product.

Thanks Martin !

For the third summer in a row I have suspended my Facebook account. At the same time I eliminated posting to Twitter, Linkedin ( Admission: I was involved in some interesting heated discussions regarding Design Unicorns ) and Instagram  ( I do have a lot of shots saved for later).

Many have asked me why I do this, and the simple answer is

I need less distractions, digital distractions.

Actually, I need less distractions, period, and this seemed like a good place to start

Part of the break was to document what I actually did and get an idea of what the tradeoff has been. Granted some of these things may have done in part otherwise, but nowhere close to this the list below.

I think the biggest difference I noted by eliminating social media was that things slowed down considerably and has allowed me to have time for focus, reflection and reading.

Good things, basically. And it didnt cost anything.

Some highlights

An excellent overview of collaboration, the design process and the role of conflict in this process Design Together

I really can’t recommend this book enough Notes to a Software Team Leader

From reading this book, I got the tip of another book  Mindset, which I also found very interesting. The discussion  of Growth and Fixed mindsets was spot on and I recommend this book to anyone with school aged children.

I didn’t completely make it through On Looking: Eleven Walks with Expert Eyes. An entertaining book about how to ‘see’ the world around you by following experts around one block in NYC.

I watched this great documentary about NYC street photographers Everybody Street that I can highly recommend.

If you like Italy or Steve Coogan, or both, the film A Trip to Italy is worth watching.

In preparation for M and my trip to California I re watched Sideways - great movie.

My advice for becoming a UX designer

Nice description the visual aspect of Design - The Perception of Design is How Something Looks. This is something that comes up in my work on a daily basis.

I thought this was interesting read about restaurants and how they use psychology to manipulate customers.

Since I had taken a break from most social media I thought this view of what different social media platforms does to you as a person as telling. I can agree with a large part of what the author says.

The Men Who Made Us Spend - This compelling three part BBC documentary explores the fears we’ve always had about consumer culture.

Oh yeah, and I caught up on some blog posts here and here (warning, geek posts)

Actual physical social interactions:

M and I tried to be active during this month and the super Swedish weather helped in this regard.

After visiting Rosendahls trägård on the way back we had a spontaneous dinner at Oaxen Slip on their outdoor deck. Oaxen Slip is, in my opinion, one of the best restaurants in Stockholm at the moment.

Visited some very good friends at their summer house on Muskö in the Swedish archipelago.

Visited Per Axbom twice at his wifes summer house in Bro. They have an incredible deck and are generous hosts.

Finally, we finished July off (actually the 1 of August) by attending the Stockholm Music and Arts Festival on friday to catch Chrissie Hynde and Jill Johnsson

So there you have it. I will definitely repeat this next year.

Jag är nöjd.

In the previous post I wrote about what Design Studio was and wasn’t.

I wrote that it was ‘Not a Verb, but a Culture’, and since then have been thinking about Culture and how to change this. Culture is a complex, and living in another culture myself then the one I was born in, has given me a great deal to think about over the years.

To me culture is something that develops as a result of a set of common beliefs and practices.

Shifting culture comes down to constant communication of your beliefs, setting good examples and highlighting positive outcomes.

I also believe shifting culture, like making any change, requires  time.

While implementing Design Studio in our development process our team has worked on improving UX understanding and building a culture around this. This has been a symbiotic relationship in that the use of Design Studio plays a large role in this culture shift.

Our efforts have fallen into some basic categories:

1. Define your UX beliefs and philosophy 

A UX belief is a shared point-of-view. Working with a central UX team, buy-in is extremely important for success. Our UX beliefs are reinforced and demonstrated through processes, design approaches with members outside the UX team in the product development process.

So what are our beliefs ?

I would say we we have two -

In the case of our team, and likely because I come from a user research background, we believe strongly in a deep understanding of the user needs to be in place before products are developed. To support this belief, we invest time in end-user research focused on “contextual inquiry”, or interviews conducted in the environment where end-users interact with our products. We operate within a continuous software delivery system and frequent customer validation is also crucial for effective UX

Secondly, our always team strives for a high level of collaboration both within our group as well in the product development teams. Design Studio is a large tool that we use in this collaboration. We develop complex products and collaboration insures good designs and effective communication with all roles in the Product Development team.

2. Describe and document your process , tools and outcomes 

A set of beliefs will remain an abstract philosophy, until you put them into practice. In order for remove abstraction you must make your beliefs real and actionable. To do this you must go through an exercise of defining your Design process, guidelines and outcomes.

You must begin the documentation with the Design process. Documenting the design process is essential to communicate your practice within the organisation and key stakeholders. You need describe the process from high-level process (why) down through the (what) and finally describe the details of the (how).  Drill down into the tools and artefacts that  support the process.
In our case this documentation has included:  Design Process description - a presentation describing the major activities and how these integrate into the software development cycle. Role of User Research in the UX process - a  presentation that describes the User Research, guidelines how to conduct research as the well as communication of the results into the organisation.
Description of Design Studio in the Development process- Collaborative Design is an important part of our process, so this process is described in detail

3. Communicate your story and share your knowledge.

Once you have documented your philosophy, beliefs, and process,  you must be able to tell a story about your practice and benefits.  Depending on your organisation and the amount of technology focus, your UX practice will likely operate in a different way. Stories uncovered from research about real users interacting with our products and  how this relates to the UX process is a good way to do this.

Although we don’t have our own room all team members are encouraged to post recent designs on the walls to demonstrate where we are in the design process. In our case we also have a Yammer network that is used frequently to post images, wireframes and prototypes for feedback from persons not located in Stockholm. This has proved very effective in spreading our message.

Once presented, and internalised by others, the beliefs and practices will form a culture. Hopefully this will be a shared “practice-able” culture.

As my friend and ‘twitter sage’  Daniel Szuc says:

Be the practice you seek others to be, this requires hard work

I will let you know how this goes.

A year has passed since I started using the Design Studio method within our company.  What started as an experiment is now an assumed part of our product development process for three products and development teams. As the use of this technique has grown, and its value recognised, I have begun to see some challenges that come with increased scale. I also became aware of what Design Studio was not.

A Final Solution 

Problem + Design Studio ≠ Final Solution

As the Design Studio was integrated into the development process for each User story we conducted at least one session. The output of this session was generally enough for a design to be refined and a set of wireframes or prototype to be created. After some time, I noticed that some of the teams develop a bit of

 ‘ Lets do a Design Studio so I can get my wireframes’

type of sentiment. A bit of the ‘check box’ mentalliy was slipping in. When this wasnt the case or we had to conduct more then one session, the teams became impatient. This is still an ongoing struggle, but I usually start every session with the following:

Warning: Design studio will not result in the final design.

Then repeat this.

Wrong Mindset -

Over time I began noticing a large amount of idea ownership. Persons or groups that developed ideas seem to have difficult letting them go. They presented them enthusiastically and did not accept critique. In some extreme cases, there was ‘competitions’ between ideas to see which ones that made it through the convergence stage –  I think competition can be healthy and I found this encouraged a good exchange of ideas, but only as long people were willing to let their ideas go. Ideas are very personal things and people develop intense pride and ownership of them. However, it isnt until we let the ideas go and see if they fly do they have any long term value.

Is not a verb, but a Culture

When I first encountered Design Studio in Architecture School the term was not used as a verb, a method, but more of a place. A Design Studio was a messy place, with half finished models, empty soda cans and pens and paper everywhere.  It was a place of collaboration, exploration and experimentation. The space facilitates brainstorming, critiquing, presenting, prototyping, sketching, researching, synthesizing, and many other activities that figure within the design process. Sometimes it smelled like pizza.

After one year I can see we have a bit to go to develop this type of culture. It is my hope that over time, and by making some incremental changes, we can approach this.

A fixed formula – mix it up

After a few months of having at least one Dersign Studio session per week, many of the developers became very familiar with the process. So much so, that they pretty much began sketching when they entered the conference room. This want ideal since I really wanted people to approach solving the design problem with a fresh (somewhat) perspective. I learned through this that people are creatures of habit and take comfort in these habits. It is at this point that I began to mix things up.

Slightly different methods – since this point I have been on the look-out for some slightly different sketching methods. I decided to use the Brainsketching method and found this to be very interesting and greatly appreciated by the team. I cannot comment on the quality of the ideas, but there is definitely a higher sense of collaboration around the resulting ideas produced

Environmental changes – during this time I began to concentrate of the physical environment. I was a bit limited since the sessions where held in a conference room. I usually waited for everyone to come in and sit down, then I invited everyone to stand and then exchange seats with the person directly across from themselves. I had experimented with music a bit, but made a point to always have music playing when people came in and during the sketching sessions. I am a big jazz and low-fi fan so played a mixture of Jan Johansson, French FIP radio, the Dining Rooms, Philip Glass and Mike Oldfield. 

A full week since the Lean UX 14 conference and I finally have the time to reflect a bit.

It only took a few sleep-ins, Easter holiday food and some red wine for my brain to contract back to its normal state after the stretching during the conference.

All of the keynotes were excellent and I found myself making notes of some new books referenced to add to my reading list.

Here are some of the books I noted, either directly from the presentations themselves or from the conversations between sessions.

1. Teaching Smart People How to Learn New Things, Chris Argyris

2. Idealized Design: How to Dissolve Tomorrow’s Crisis…Today, Russell L. Ackoff

3. If Russ Ackoff had given a TED Talk (Ok not a book, but an excellent video)

4. The Principles of Product Development Flow: Second Generation Lean Product Development, Donald G. Reinertsen

5. Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration, Ed Catmull

6. The Art of Action: How Leaders Close the Gaps between Plans, Actions, and Results, Stephen Bungay

7. Training From the Back of the Room!: 65 Ways to Step Aside and Let Them Learn,  Sharon L. Bowman

This book was discussed in one of our breaks when discussing workshop facilitation methods

8. Designerly Ways of Knowing, Nigel Cross

I am sure there were many more from the different workhops that I did not attend, so let me know of any recommendations you have.

For now, this will add to my never ending reading list. Thats a good thing, right ?

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 Studio Sketching

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.

A proud developer reviews the task breakdown.

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 !