Design for the Conversation


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.  


The Question is More Valuable then the Answer


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.

Asking better questions:

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

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.

Creating Questions

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

Having a question conversation

Experience Canvas

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.

Experience Canvas 2
Experience Canvas 2

The canvas:

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.

Enterprise 2.0 and Human Psychology

The first time I met his ghost was in 2003. I had just returned from to my organisation after spending the last six months in Business School in England.

I returned with my analytic skills sharpened and my head full of new ideas and theories. Ready to innovate.

I had just completed a two month project to develop a executive information dashboard for the top leaders of the organisation. It was time to present my proposal to the CIO who was responsible for the funding.

After I was finished the presentation to the CIO, he leaned back, took a breath and said:

' Do you think there is a good ROI for this project ?'

'Absolutely, I am convinced this will lead to improved decision making quality and save time' I responded.

' But...can we point to an improvement on bottom line from this saved time.. in euros ?'

Mmmm heart sank, I knew I could surely do this, but what about the other aspects: decision quality, effectiveness, motivation ? What happened to all the modern psychology and human relation theories I learned about ?

It was at this point I saw the ghost of Henry Ford whisper in the CIO's ear : 'Making widgets, that is what is all about, making widgets'

Fast forward to 2008, Web 2.0, Facebook, Twitter, Crowd Sourcing, Enterprise 2.0 the buzz words are never ending.

I met the ghost more frequently now and he still whispered about widgets, and not much has changed. In fact, in some ways the financial crisis has made matters worse, project 'death by business case' is common. Despite this, I have spent the last number of years trying to incorporate various aspects of online collaboration into my organisation - project collaboration rooms, micro-blogging, new 'social' intranets - with little success.

After much frustration and much less hair, I am convinced the issue boils down to one thing:

Many organisations do not understand human dynamics and psychology.

Awareness of human psychology as it applies to work has evolved at a snails pace while technology flies by it at the speed of light

What’s taking so long?

Part of the story starts back in 1911 when Frederick Taylor – the “father” of professional management as we know it, propelled his ideas for advancing worker “efficiency.” The Taylor method prescribed a clockwork world of tasks timed to the hundredth of a minute, of standardized factories, machines and people. Naturally, ordinary workers resented having to work faster than they thought was healthy or fair.

At the time little was known or considered at the time about the “human dynamics” of workers and modern psychology was still in its infancy. In fact, it seems that the “human side” of worker’s needs was viewed as rather inconvenient by some of the industrial leaders of the time.  Surely, the inner workings of the human being were a nuisance at best to people like Henry Ford (the man not the ghost) who complains, “Why is it when I need a pair of hands I have to get the whole man?”. This way of thinking has permeated organisation so much that there is term to describe this thinking, Fordism, and the ghost of Henry Ford was born.

Sadly, the machine metaphors of Taylor and Ford still guide many of the underlying processes of the modern workplace. The command and control thinking and practices implemented during that time are still driving the management behaviors of most business leaders today. The ghost walks among them and is strong.

Despite the last 50 years of business education, and the shear numbers of MBA's in the working world now, change has been surprisingly slow.

What Business Says It Needs

When you ask business leaders what is needed to survive and thrive in today’s complex economic and global marketplace, the list is long – leadership, creativity, collaboration, innovation, motivation, trust, teamwork, partnerships, learning organizations, rationality, quality decision-making and problem solving skills, accountability and resiliency. But even though there is often consensus on what’s needed – there doesn’t appear to be any real understanding of how you get these things from people  – or where they even come from.

The concept that many of these goal can be achieved through a more open, transparent organisation that supports idea sharing and collaboration is evidently extremely hard to accept.

What’s even more baffling is that many business leaders don’t even recognize the need to understand how people function – what makes them tick.  These management mindsets are completely out of step with the growing body of science of the past two decades that illuminates the how and why of what we think, feel and act. This despite large HR departments whose goal it is to manage this 'asset' of the orgnanisation - the people.

The amazing information coming from research on neuroscience, physiological responses and emotional processes form the basis of a new blueprint that should be driving every management model.

This is where Enterprise 2.0 technologies can come into the picture. Organization's must approach these types of systems the same they way they would any other - with long term commitment and consistent strategy.

Unfortunately – most managers are still operating out of the old, ineffective, unproductive models that have shaped how we “manage” people.

This thinking has resulted in corporate cultures and organisation that do not support Enterprise 2.0 efforts.

Until this changes - social technology use in the organisation will be muddled, slow and ripe for failure.

Despite all of this I am positive and will keep on going. Join me.

PS: To give yourself (or any organisational executive) a crash course describing the most relevant research around human psychology and motivation, I can recommend Dan Pinks lastest book -Drive.