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
Solve problem of strategy not by more detailed plans but by richer conversations about the plans @jseiden #theleanevent— Neil Chalk (@_neilch) April 28, 2016
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.
Four years ago, I went from being a lead designer in a product company to be a manager of the UX team. I started to divide my time between ‘doing the design’ and everything that went in to that, to making sure and motivating others to ‘do the design’. My role developed into more of a coordinating function. In addition to this, one had to make sure each designer delivered at a uniform quality level (more or less). The more I thought about this, the more I found myself discussing what the appropriate level of UX quality was for each product and the business. Turned out this definition was different for different groups of people.
Leading a group also means you need begin to consider growing the team and I started thinking in terms of ‘value for the company’ in relation to UX. Having worked with UX for some years the value for me was clear, but now things had to be articulated in terms of organisational value. Explaining UX to persons that had their own definition was challenging and frustrating.
The company expanded shortly after I became manager and we grew to include two more products with their own development teams, this time located in the US. At the first few meetings with them, I described how we have integrated UX into our organisation. I had purposely promoted a very ‘loose’ process for the UX work. The UX team uses a ‘federal’ organisation where designers are integrated into each product team but solutions are usually developed through UX team collaboration.
One of the members of the new product teams asked:
Do you think this is the most effective way of organising things ?
After a minute or so, I answered ‘yes’, but wasn't really sure of my own answer.
I spent the next couple of months discussing this with people in other organisations in Sweden trying to find some answers. Surely someone else had asked these same questions as me ?
Questions like :
How where they organised ? How many of them worked with UX ? Was this effective ?
What activities did they work on ?
How did the organisation view their efforts ?
How did the UX team demonstrate value ?
I saw a lot of commonalities but just as many differences. It seemed to ‘depend’ on many different issues and who you talked to.
Around the same time, I noticed a shift on social media and UX conferences — a shift from the discussing the craft, tools and methods of ‘doing the design’ to coordinating and managing the design. UX was growing up and this was a good thing. The discussion shifted from ‘getting a seat at the table’ (personally I believe in bringing your own seat) to figuring out what we were going to do once we got there.
Although I love reading about all of the all the ‘design lead’ organisations that exist in the world, the numbers indicate that there is a very large group of organisations that are not nearly as mature as these stars.
How were these organisation creating a business impact with their UX efforts ? Were they ?
I wanted to know.
So to get a wider perspective, I decided to ask some more people. To do this I created a (short) survey on a European level around UX impact within organisations. This includes UX team organisation, UX activities and how UX influences certain business metrics.
If you have a moment, give it a look. Thanks.
Take part in the European UX impact survey
I am upset…and sad, and UX is to blame.
Let me explain.
I recently read a blog post How bad UX killed Jenny that described the tale of ‘Jenny’, a young cancer patient undergoing a very toxic type chemotherapy treatment. The treatment was so toxic that she needed to be pre and post hydrated to ensure the the chemicals left her body after each treatment session was done. If this is not the case, certain internal organs will shut down from toxicity.
I read this post intensely, and as I read each line I got a strange feeling deep in my stomach. It was way too familiar. This is partially since Jenny’s story is my story. Over ten years ago I was diagnosed with bone cancer in my left leg together with lung metastasis. After a lung operation to remove the metastasis I was given and extremely strong treatment of chemotherapy. It was much like ‘Jenny’s’ treatment described in the post.
Reading this brought back a flood of memories. The over 25 intravenous units I received over three days of treatments, the careful measurement of liquids into my body and the chemotherapy drugs. The drugs were so toxic that the nurses that administered them wore protective smocks so as not to damage themselves. All liquids were measured as they went into my body and when they came out. Balance had to be maintained.
I had great nurses and I remember that three nurses needed to verify the dosage of drugs before they could be administered.
Why ? I never even reflected why it was three at the time. Standard I guess. I realise now, this was partially to ensure they were administering the drugs and interpreting the dosage machines correctly.
I am sad not because the healthcare system failed, or the doctors or nurses did not do their jobs(who were super), or the machines themselves that broke: but where the machines interacted with the people they were designed to benefit.
The interface: that point of connection between the system and the user that seems so simple to create, but in reality is likely the hardest part to do well.
That is what failed. It destroyed the entire process for Jenny.
We need to stop this failure. There is a lot to do, hospitals and other institutions that care for people are using systems that have poor usability and lead to errors and human stress.
Jonathan has some good practical advice for UX designers to make a difference, but I appeal to the industry as a whole.
The next time you read a tech blog post that highlights a groovy new app or cool service we need to ask ourselves.
Is this the best use of your UX superpowers ?
Lets be honest we probably wont miss all the ‘likes’, or tinder dates, or even checkin points, that these services provide very long, but we just might miss our own lives or those that we care about.
Alive and kicking, fighting the UX fight.
PS: And thanks to all the nurses that checked my dosage machine.
At a recent meeting with director of Product Management we were reviewing the Product Roadmap discuss the status of things. While reviewing one particular item he made a comment to the effect:
‘Wow, I remember when you guys started working on this feature. You seemed pretty much done after the first meeting. That was six months ago….'
I went onto to explain that he participated in one session (I was very happy he attended this meeting) to explore the problem and that we were very far from a good solution at that point. This really didn't matter and clearly he was frustrated and confused. The fact was that we had gone from that meeting and iterated the design twice based on user feedback before having a solution we were comfortable with. I realised that from his perspective once the user stories were started it was reasonable to expect some sort of user facing output in the near future. The reality was we when we started User Stories some issues were unknown which tended to spawn investigations and other User Stories, and so on …you get the picture. It seemed to me we spent a large time researching and not delivering . We needed another way to reduce this multiplication of Stories and do a better job in their preparation.
I also realized I had also done a poor job of explaining the process that we used. I have written about communication to build UX culture in organisations and this is something that needs to be done continually to be effective. Since this conversation, we have begun to integrate a slightly different process (or more accurately defining ‘a process’ ) into the Product Development cycle.
The process is based on two distinct phases - Discovery and Delivery - which although are drawn in a linear fashion are actually practiced together in loop that utilises feedback. The goal is to ask the right questions before we start developing so the development can be contained and more fluid.
The start of this process is ideas.
In most organisations there is no shortage of ideas to consider for your product. In our situation we had way more ideas then we could ever realise. The key is to be clear what level of value each idea will bring and evaluate each very critically.
In our situation ideas come from a few areas:
Product Managers - The Product Manager spends a lot of time visiting customers documenting the needs that they have. These are usually in the form of qualitative observations or specific complaints. Sometimes there is time to dive deeper into the user details of the issue, but not always. In general I view all PM ideas as assumptions and that need to be investigated or verified further. These ideas get added to a PM backlog (this will be a latter post).
User research - I am consistently amazed how many things I learn from meeting end users. This should be a large source of development ideas for your product. If you are not doing this - start.
Internally (engineers) - probably one of the best sources of ideas in my opinon. Engineers have a deep understanding of the technology which allows them to more easily imagine what the technology can achieve. As products become more complex, end users sometimes lack this knowledge, have difficulty considering what is possible.
The Competition - competitors are a good way to review how another company would choose to solve similar problem. This can include both user facing as well as technology solutions.
The goal of Discovery is not necessarily to deliver any software. The goal of Discovery is to learn and to have conversations around some fundamental questions that will allow use to deliver better results. In our situation we were rushing into Delivery at the expense of doing the necessary Discovery.
During Discovery our goal is to answer some questions:
What problems are we trying to solve ?
What do people want to do that they cant do today ?
Are they willing to pay for a solution to this problem ?
What would a usable solution look like ?
Is this technically feasible ?
A clearly stated problem/opportunity is key for several reasons.
First, stating a problem clearly and concisely will allow you to define any holes in your thinking. It forces you to identify any assumptions, gaps in clarity and things that haven’t been validated. We found often that didn’t have all the pieces for any given particular problem definition. This forces a focussing of research and validation to clarify the problem boundaries. This was a large source of our User Story 'spawning' that was noted earlier.
Second, clearly defined problem boundaries nurture and encourage ideation which is important when we formulate your vision and Design. Whenever you present someone with a very clear problem the natural response is to start mentally picturing what a solution looks like.
It is important in this scope to link this problem back to the business value.
Some questions I usually like to discuss are:
How will solving this problem add business business value ?
What effect do we aim to achieve ? How will be measure this ?
How will solving this problem integrate into our overall strategy ?
Tools to consider:
I facilitate these discussions using a couple methods with good results. The Experience canvas and Impact Mapping are good for the strategic vision, while the Product Box exercise is good for product specific goals.
Use discussions with users and customers to gain more insight into how they use your product and what they want to achieve. In my opinion, this will be the single most valuable thing you can do to develop the UX or your solution. I have mentioned the value of doing User Research together with Product Management but it can beneficial for most anyone involved in the development process. Within our team we perform and combination of ‘contextual interviewing’ to discover new product areas as well as formalised user testing to evaluate specific features.
Tools to consider:
Jobs to Be Done - Since our products are Enterprise oriented there are some fairly distinct user scenarios that people follow. I have found the Job to Be Done model quite helpful in analysing these scenarios. I am a supporter and have been using some nice JTBD interview cards that have been handy when conducting Contextual Interviews to focus on the Jobs. I have found the identifying the major Job then breaking this down to small Job tasks blends very nicely into my next favorite tool - User Story Mapping
Story Mapping - I have written about the value of using Story Mapping before. I cant express enough what an effective tool this has been for us. By mapping how user work today you get a much better idea of the problem you are trying to solve. From a solution perspective, It has allowed us to a get much better picture of the entire solution as well as identify many holes in our thinking. Story Mapping has allowed us to design a high level conceptual model that can effectively fully support the more detailed feature designs.
At this point you’ve determined what problem you are trying to solve, why you’re building this from a business perspective, and you have investigated users and customers so you know what their world looks like. The next step is to to imagine the future — to envision the solution and how your target customers and users will make use of it. These step also blends well into the result of the Story Mapping and allows to take this Map and refine it further.
The most effective tool for this is Design Studio. We have been using Design Studio consistently for the last three years with three development groups. This has proven very successful and I have written about it a few times here and here.
An important dimension of Design Studio process is the engineering validation. Once of the advantages of having developers participate is you get an sort of built-in ‘will this work’ validation. Even still, I think there is a value to have a part of the Design Studio that includes a ‘what if’ session. You’ve imagined the solution from a user’s perspective, and visualised the experience. These ‘what-if’ session allow the entire team to discuss what’s going on underneath the user interface. During these discussion talk about business rules, data validation, and tricky backend systems or services you’ll need to connect with. This is especially important when you work on a complex platform with a high level of product interaction. In or situation we have had to include other people from different parts of the platform.
At this point there you have a reasonably good solution that has been discussed and understood technically. The key here is to divide the implementation into small enough pieces that can deliver value and at the same time be verified. For our organisation we are lucky and deliver things continuously, so getting value and user feedback is a bit easier. The goal is to minimise unecessary work so now is the time to priortise ruthlessly and reduce things. An important dimension to this is to communicate this plan to other stakeholders. This will allow them to understand the situation and manage expectations (which wasn't done in our situation).
The emphasis in the Discovery part of the diagram is a lot from the UX side of things and we have a large role to play, both in implementation and leadership.
As Jeff Patton says:
“UX work is mostly about discovery, agile [development] work is mostly about delivery. Two worlds – both concerns are necessary. Discovery never stop. And, discovery without delivery isn’t very valuable”
Delivery and Delivery need to work together and each organisation has their own way of doing development.
Once I have some time to use this model in practice I will follow-up with some thoughts on how Discovery and Delivery can work together.
Until then. Good luck.
Recently I had a discussion with someone in my company. I was talking about the our team and how things we going, and the challenge of all of these new things we needed to work on.
I said we needed to structure things better because there were so many unanswered questions we needed to address before we began a design.
'We spend more then half the time asking people questions and getting answers'
He looked at me and said:
'Ya know, your group has kinda a reputation of asking a lot of questions. This could turn some people off...'
I was taken back at first. Asking question was a critical element in my definition of doing a good job. How could anyone question this and get turned off ? After giving this a good bit of thought I realized that asking questions can go two ways.
Too hard - and you create conflict ; too soft - and you dont get the details you need.
Balance is the key.
I asked myself the question: 'Why does asking questions create so much resistance'?
I had realised long ago that, even the best intended questions of are not always interpreted this way. This often leads to frustration and conflict (I have the bruised ego to prove it).
Questions challenge authority and disrupt established structures, processes, and systems, forcing people to have to at least think about doing something differently.
These challenges are often viewed as criticisms.
In business, as well as our personal lives, results are what counts (outwardly anyway). Questions are often viewed as delays in the way of progress and stop the group from 'moving forward'. The risk here is without such questions, the group often acts out of habit - moving forward with an idea that was used before. As things become more complex old solutions become less and less effective when we face new challenges. New thinking is required more frequently.
Our present Western culture generally doesnt reward not knowing. As experts we are expected to deliver answers not more questions.
According to Sir Ken Robinson:
In our culture, not to know is to be at fault, socially.
If you ask a question and that person doesnt know the answer they (and others as well) can view themselves as failures.
Questioning often has an inverse relation to expertise - such that within their own subject areas, experts are apt to be poor questioners.
As a side note: This is one of the reasons I encourage all of my adepts to adopt the 'Mind of the beginner'.
So how can we get better at this ?
The challenge is that we have never been taught this in Western education. Instead, students are encouraged (and tested) to know 'the answer' to a question. Rarely is the process reversed allowing people to explore and ask questions.
Since the my initial conversation our team has started using two main methods to ask better questions and facilitate a conversation that has proven to yield some good answers.
When a new challenge comes into the team, there are immediately quite a few questions that pop up in the members heads. This usually creates confusion and frustration.
Instead of immediately jumping into answers to these questions I think it is important that we take a step back and insure we ask the 'best' questions we can first.
To do this we have used an adaption of the 'Question-Storming' technique developed by the Right Question institute for some time. The RQI is a non-profit organisation who's goal it is to educate people (emphasis on students) on how to ask more effective questions in their lives.
Question storming is a variation of brainstorming where, instead of brainstorming ideas (solutions) to a problem, participants generate questions instead. Questions are usually viewed as less fixed and peer pressure is typically reduced.
In a given session we will spend about 5 minutes (timed) to generate individual questions on sicky-notes in silence. At that point, each member posts them on a wall and explains the question to the rest of the team. Usually there are a few statements and these are converted to questions. After all the questions are posted there is a discussion where we try to refine and consolidate. The goal here is to get to the best questions that will get us the information that will allow us to develop a good design
Since we are trying to develop the best questions we can around this issue, we try to limit the number of closed - ended questions - those that can be answered with a 'yes' or 'no'. Instead we try to develop moreopen-ended questions - those that demand more of an explanation.
At this point we usually have a quite a few questions. So to not overwhelm people we generally divide this question into groups - immediate, those that we feel are the most important and secondary, those that can be explored later or that we expect to get an answer later in the process.
Once the questions have been identified then we can begin to take action around. This usually always involved a structured meeting the stakeholders to begin a discussion
I have found the asking of questions (or more importantly getting to the information of the answers) is much more effective in the context of a normal conversation. This avoids the feeling of a 'inquisition' which tends to put people on the defence and makes the exchange more natural.
For the last year I have been using a modified version of the Experience Map from Atlasssian (huge thanks), which uses some of the themes of Lean UX together with the Business Model Canvas to facilitate these conversations. I found this to be a good framework to have a conversation and often results in holes in our knowledge that needs to be filled before we can continue.
Problem – What triggered the hypothesis? How was this identified ? From PM's ? from Customers ? Are we solving the right problem ? Do we need to investigate further ?
Personas – Who will use this solution ? Will this differ from our present user personas for existing products ?
Stakeholders – Who is genuinely affected by this solution and should have a say. Who needs to be informed ?
Team – Who can deliver this solution? Will this fall into one of the existing Product teams ? Does a new cross team group need to be created ?
Idea – What are the early thoughts and options to solve the problem? Careful not to jump to quick conclusions.
Value – What is the user benefit and business benefit for your solution?
Validation – What does the smallest, easiest, fastest-way to validate your idea. This can be a sketch, prototype or basic version of the product. Who can be validate this ? t
End-to-end demo – Tell a story to bring this to life, using anything from role play, sketches, story board. Very often we will use Story Mapping to explore and visualise this.
Test results – How will you judge the experience you’re setting out to provide? Qualitative or Quantitate testing ? how ?
Here is a download of the my Experience Map - have fun.
I am pleased how these tools have allowed the team to ask better and more effective questions. I have found that this can be used in a number of other areas as well. These question, together with the Experience Canvas, I hope will lead to a better start to your designs.
Let me know how it goes.
This post is a continuation to my previous post Thoughts from a UX mentor (part 1). This will list will likely grow.
Critique is a integral part of the design process. As a UX designer you will need to effectively 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
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’ .
Resource Tips: 10 Life Lessons from Basic Seal Training
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 an 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.
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.
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.
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
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:
That I dont know what I am doing
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
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.
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.
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.
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.
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:
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.
I was very pleased this this method and I received a great deal of positive feedback. The major benefits:
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.
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.
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.
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.
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.
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.
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.
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 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
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 ?
When I was applying to one particular job at a UX form in Stockholm the issue of my MBA came up in the interview. ' How is your MBA useful in the UX area ?' they asked.
Now, I had never given this much thought and had seriously considered removing the MBA from my CV but my pride (and all the hours I put into to it) forced me to leave it on. Usually I just didn't mention it much.
I don't remember what I answered exactly, but it centered around strategy and analysis…..or something. As I remember it could have been a better answer.
I think partially I was a bit embarrassed of the degree. This is especially true in Sweden, where it isn't so very well known outside from the top schools in Europe and the US and thus hard to relate to. Since it wasn't a 'design' degree it somehow didn't go over as relevant.
Having worked a few years now in a number of UX agencies in Stockholm I have definitely seen the value of my MBA.
1. Ability to conduct analysis - this is probably the most valuable area that I learned from my MBA. The ability to structure, analyze, then communicate the results to an audience has been invaluable in my UX.
2. Real Cases - We were always exposed to the basic theories in various areas, but there were ALWAYS coupled with real case studies. Very little purely theoretical examples.
3. Education based on frameworks and mastery in applying them. No absolute right and wrong. - Now I have read some criticism of MBAs recently in light of the value of design thinking in business. Basically the argument goes -
MBA education encourages one answer to the case while design thinking embraces multiple possible outcomes.
In my experience this can’t be farther from the truth. For most cases we could propose many solutions as long as they could be justified. Believe me, if you have studied enough theories and frameworks you can justify anything. The best case studies that I did were ones that I combined frameworks from multiple areas to justify a innovation solution. Sounds a bit like design thinking doesn't it?
4. Consider things in their entirety. By the end of your program you are encouraged to think holistically and apply your knowledge across many operational areas.
This last point bares some further explanation, since I think it is particularly relevant.
I have just finished following the UXLX event in Lisbon on twitter and noted the continuing discussion around 'silos' in organizations and how they limit effective UX thinking. I have been involved in the UX area for a few years now and attended a handful of conference. In all of these conferences, this issue of 'silo crossing' always comes up in varying degrees. Clearly this is an area of frustration.
The discussions seems to follow a similar patterns with a good dose of hand wringing.
'The managers in department ________ just don't understand the value of what we are doing… '
We need to 'cross the silos' or ' get a seat in the C-suite' or something similar…
My true belief is that to integrate UX thinking into organizations will require people to meet somewhere in the middle between the silos. I agree with Peter Merholz that UX should be seen as a strategic effort as well embody tactical solutions (methods and tools). Until this is achieved we all will need to understand the other side.
To effectively eliminate silos (or at least minimize the effects), UX practitioners need to understand the other silos. To understand persons working in other silos we need to understand their motivations and how they define success. One way to do this is through business education.
When you look the core of a typical general MBA curriculum, you see a couple core areas:
1. Strategy 2. Finance 3. Marketing 4. Human Motivation - extremely valuable. 5. Some sort of Quantitative Analysis
All of these areas of knowledge have been beneficial, but what they have given me in my UX work is understanding.
Understanding of other departments and what their function is in an organisation and how they measure success. What makes them tick if you will.
'Understanding other silos can make yours better.'
Now I am not suggesting that all UX practitioners drop their wireframing tools and head off to business school. This is overkill.
But I do think that UXers should take the time to educate themselves in the basics of how businesses operate and organize themselves. Maybe shift the spotlight of their view point a bit more over to the other silo.
And UX consultancies and other organisations; the next time someone shows up at your door step with an MBA under their belt, give them a chance, they may just surprise you.
I can't imagine designing without making [physical products], I love making prototypes. We go right from idea to prototypes. I just love making objects.
Prototypes create this dramatic shift in the conversation - suddenly it becomes tangible and the silence goes away.
You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.
Great post The Problem With “Innovation” in which he cites the above quote from Buckminster Fuller and points out that what looks silly, superficial, inconsequential and downright distracting when they’re first proposed can “suddenly” have fundamental consequences for society as a whole. Or, as the author puts it:
New models create new markets, but they’re often misunderstood at the outset. Stupid checkins reshape how we explore and experience the real world. Prepaying for tick tock watches reshapes financial markets. Silly status updates spark revolutions. And grainy glitchy video calls cut into the commercial air travel.
Something to think about.
During the last few months I have been involved number of projects that involved a considerable amount of user research and testing. Through this process, I have interviewed over 50 persons for a number of digital and physical devices. There are already a large number of posts discussing user research planning and structure so I didnt really see the need for one more. What I did want to document, is the 'people' aspect of the research and summarize which techniques that worked well for me. 1. Listen - If I say listen, this is a bit obvious, but I am surprised at how many people that don't really listen during user tests. Whether this is to get through the test as fast possible or an over concentration on the task at hand, people sometime fail to listen. To assist the dialog I often try to use the same terminilogy as the participants. An exmple of this is when I interviewed bus drivers as part of a new instrument panel study I asked them which term they used to describe the panel anc continued to use the same term. (Interestingly, this was not the same term the manufacturer (client) chose to call it.)
2. Use two people to conduct a user test if possible. This will depend on the client, scope of the project and overall goals but overall results improved. This will allow one person to facilitate the interview itself and fully concentrate on the test person. I find that test persons are quite sensitive to distracted facilitators and the overall quality of the results are better. The second person can then concentrate on documenting the research and making sure the technology is working (which is often a challenge).
3. People don't open up until they are comfortable. For some test persons this never happens, but for most some simple techniques can insure this happens fairly quickly. If the test scenarios don't require it, try to keep the lighting as low as possible. I try to have ample space to conduct the interview. No one likes to feel cramped. Water, coffee, fruit and candy all help to get test persons to exchange freely. In general, I often start the interview with a few non-intrusive background questions. It is important to view the interview person as an individual and not just a 'cog in the research machine'.
4. Don't help too much. I am quite guilty of this. Very often we designers, after spending countless hours thinking about a solution, have a difficult time just letting people be in their attempts to understanding the interface. The goal of the research to to get feedback of the process and the outcome and things take time. Be patient - just give it five minutes, before jumping in.
5. Don't use a script. When testing people try to be as authentic as possible. The same rules apply to presentations as well as interviews. When someone sits and reads a script, test people sense this and I believe react accordingly. Very often the script is pre approved by the client to insure that everything is included in the test. In this case, I usually take the script and distill it down to a few keywords and then 'talk' around each these trying to weave the questions in tot the discussion. Improvisation is key here.
These are what I have come up with so far.
If you have any more good tips let me know.