My top 3 tips for awesome Process Mapping Workshops

Process Mapping Workshops haven’t moved on in the last 20 years…

When you mention process mapping workshops to most people they’ll think of standing around brown paper with pens & post-it notes, talking about the same thing over and over and over. The more arguments there are, the better the workshop right? Can you accept that they are successful and collaborative workshops based on this experience?

However, as Process Mapping software grows in popularity, here are Skore’s top tips to make your process mapping workshop engaging and enriching.

Want to learn more about Process Mapping? Read our guide to Process Mapping here

Why use Process Mapping Software?

People love post-it notes right? You don’t get the same engagement looking at a screen?

Wrong. Paper-based approaches aren’t slick, moving dozens of post-it’s around because you’ve suddenly remembered a step is a daunting task. Plus, rolling up the paper and spending days translating them into a digital format results in two major problems:

  • Workshop output has a half-life. The longer between the workshop and the delivery of the output, the less impact it has.
  • It’s very difficult for one person to successfully translate what was captured into an accurate representation. Couple this with the time it’s taken, you lose engagement as people don’t relate to the output

Whatever success you’ve experienced engaging through a workshop will be lost when the reporting doesn’t match up to the conversation you had two weeks ago.

Our Top Tips for Process Mapping Workshops

  Use a common language

Even if you’re clever enough to have learnt BPMN, no one is going to be impressed with your use of connector symbols, diamond, squares, etc… Keep it simple, people don’t want to have to learn a whole new language to engage in the workshop. Keeping it simple and accessible means the whole organisation can be engaged in change – not just the process experts. Simple process language explained

  Don’t jump into the detail

It’s all too tempting to spend hours focusing on one part of the problem. You’ll get a far better picture if you start at a higher level, then break it down into the detail as needed. It also means you can get the right people in the room at the right time. Using software means you can drill down into the detail easily later while keeping the process map to one page. 

Hierarchy of Skore Process
How a Skore Process Map Drills Down

  Share it instantly

If you’re doing it right, the content should be shareable by the time the attendees are back at their desk. You want them to be able to review it whilst it’s still fresh in their minds, make that comment, ask that question. Also, they’re more likely to share it with people that didn’t make the workshop, gaining a wider level of feedback.

Using a process mapping software, and our tips, will help you engage on a whole new level. You’ll be able to get to answers quicker, demonstrate instant value and move the audience onto the next stage sooner, be it future process improvements, system implementation, or something else.

Skore is the Process Mapping and Analysis Platform that enables you to map processes in live workshops at the speed of conversation. Create instant insights and dashboards and shareable to everyone. If you’d like a free trial, let us know.

How to Capture a Process in Skore

Congratulations on getting your Skore Workspace! Your process discovery experiences are about to become collaborative, enjoyable and satisfying. In this article we’d like to show you how to capture a process in Skore and explain why it is so effective.

For this exercise we are using the aircraft turnaround process as an example as it demonstrates the many different aspects of process visualisation and is a pretty complex process.

The basic components of a process

Processes are a series of activities that transform inputs into outputs. At the core we need to know what happens, who does and why. Skore is built around these core questions.

Drawing a process with Skore means adding a What box to describe what happens and who does it, then a Why box to describe the output of each step in the process.

Need to know how to add a Why or What box? Click here

A WHAT box followed by a WHY box

Click on each box to edit text and describe the activity, the role that does the activity and the output of that activity.

Let’s use a simple activity: Unload Passengers

A completed WHAT box

In this example the person responsible for safely unloading the passengers is the Cabin Manager. The reason we unload the passengers… well apart from the fact they want to reach their destination… we need to get them off as quickly as possible so we can start preparing the cabin for the next flight.

You can read it like a story:

As a Cabin Manager I need to unload passengers so that the cabin can be inspected and cleaned.

Drawing process flows

Now we know how to define a single activity in a process let’s look at how to create process flows. If you feel really confident you can start capturing activities in a flow. However here we recommend an easier way to get started and make sense of business processes.

Your audience will always find it easier to tell you what they do rather than why they do it. In fact asking someone directly why they do something can make people feel uncomfortable.

So let’s start with some basics. First off we want to clearly show what process we’re mapping. Make sure you have the title of the process clearly visible.

Next let’s set the ‘scope’ of the process. This means where the process starts and where it finishes. The first input and the final output.

Start with title and scope

Now we know what we’re looking at, the next step is to try to capture the main activities. So start putting a few what boxes onto the page and then ask what the main tasks are.

Place some empty WHAT boxes on the canvas

That wasn’t so hard and we didn’t upset anyone yet. Rearrange so all activities are in the right order. So now try to add the role of the person who owns this piece of work.

Add activities and roles to the WHAT boxes

The next stage is to add the outputs. Each output becomes the input for the next activity so think of them as the handover from one to the next. What tells you one activity has finished and the next is ready to start.

This could be as easy as a document completed, a signature captured or a form approved. As you capture these you can link all the boxes together in order.

Finally add WHY boxes and connect the lines

Creating detailed views of a process

Once we’ve described the high level process we can start to explore how it works at a more detailed level. Some people call these sub-processes or drill downs.

You don’t have to create a detailed view for every activity, it depends on whether you need to know more about that activity or not. If you do then this is how.

Simply click the detailed view icon on the what box.

Click the detail view icon to create a new diagram

You’ll immediately move to a new diagram. Look at the breadcrumb and you’ll see you’ve entered a new level of detail.

The breadcrumb is created as you go into more detail
The breadcrumb is created as you go into more detail

Now start drawing the next level of process. You can start your scope by dragging the inputs and outputs from the parent level onto the canvas from the Create menu.

Then follow the previous instructions to create flows.

If you need to create more details you can. There is no limit to the number of detailed views you enter.

Linking to relevant documents

As you capture a process you will want to add additional information to it. For example, document templates, systems or descriptions of the process steps.

All of these are easy to add in Skore. Every step in a process can have a text attachment or a link to another document or system.

To create a text attachment simply move your mouse over the step in the process and click on the paperclip icon.

Click the paperclip icon to add an attachment
Click the paperclip icon to add an attachment

Click Add New Text and enter the text you need. You may use markdown to format the text if required.

To link to a document or system use the URL link on the attachment window.

Additional text and links to systems and documents can be added as attachments

These are the basic steps to any process capture in Skore. We hope you have found it useful. If you have any further questions you can contact us at [email protected] . Follow us on our social media below for further hints and tips on how to get the best out of the Skore Digital Discovery Platform.

Skore versus MS Visio, Lucidchart and Gliffy

For the purposes of this article we will consider Lucidchart, MS Visio and Gliffy to be general purpose diagramming tools. Given its ubiquity we will refer mainly to MS Visio for the examples.

How is Skore different to Visio?

This is the most common question we come across when introducing Skore to new audiences, especially analysts and consultant. We use Visio to create flowcharts and we create flowcharts in Skore so how are they really that different?

It would be easy, but rather boring, to try and explain the difference feature by feature.

Instead I would describe Skore as a strategic tool that helps organisations better understand themselves and therefore better able to improve and change. Whereas Visio is very much a tactical general purpose diagramming tool. I can design a business process flowchart in Visio, and I can design my new kitchen.

Process – a strategic view

For decades business leaders have considered their organisation’s processes as strategic assets. Processes flow through organisations, transforming inputs from suppliers into value for customers. They are the reason businesses function. And yet, after all this time, executives continue to struggle with problems of efficiency, standardisation, quality, risk and effectiveness.

When taking a process view of an organisation it’s easy to see where the problems are. Bottlenecks and breakdowns happen most often where the process moves from one team to another, from one department from another, or from one person to another.

Inefficiencies and errors thrive where different people deliver the same piece of work in different ways. Or design new work every time they do the same thing.

As an organisational improvement tool process flowcharts are used to show us, and help us fix, these problems.

So why do these problems keep coming back? Why do so many leaders still consider process and process efficiencies as a strategic priority? Why have we not solved this once and for all

Process – a tactical view

At a recent client the chief executive complained that he couldn’t understand why people still kept making the same mistakes despite his efforts to make the whole organisation more process focused. This reflects the fact that in most organisations ‘business’ processes are confused with flowcharts.

Flowcharts are fantastic tools for visualising flows of activities or data. They say a picture paints a thousand words and a flowchart allows you to layout complex sequences of activities that may be sequential or parallel or both. Something a text document does very poorly.

So can you draw a ‘business’ process using a flowchart? Absolutely, however it’s not so easy to create true business processes, at least not as easy as it is to draw any old boxes and lines. Something many people confuse with business processes.

In practice flowcharts are created for many reasons, as very low level task instructions, decision trees, or for implementing specific parts of a system. When created in Visio they are flat 2 dimensional diagrams with the only guidelines and rules based on the experience of the user.

Or they are created on whiteboards, they are large, complex and with varying levels of detail all displayed in one noodle soup of a flowchart.

The problem with thinking of process as a strategic asset

The problem is that processes exist at many levels of an organisation. There are the big strategic chunks of work that describe the core value chain. Or there are the management routines required to ensure work is optimised and continuously improved.

There are the key activities that describe what the organisation, team or department needs to do. And there is the implementation level of work such as tasks or requirements for systems.

These different levels of process are still often drawn in Visio but they require considerable expertise, skill and experience to create and manage them. In fact, in most cases, the same expertise is needed just to explain them and how they fit together.

This expertise takes years to develop and individuals that fit this bill are rare and sought after. They are most likely to be interim roles or expensive consultants. Organisations bring them in for specific projects and programmes.

This type of skill rarely gets embedded into an organisation and once the consultants leave their ability to update and maintain a true process view of the organisation goes with them. The organisation gradually reverts back to type.

A further problem, and one that any good process consultant will be perfectly aware of, is that processes do no exist in isolation. A process doesn’t work without people to do it, nor does it work without the inputs and resources that are to be transformed. Again, without the systems, rules, machines and equipment that make it work, a process is nothing but an idea.

To really understand an organisation’s strategic processes it is essential to have a good understanding of how all these interlocking pieces form the complete picture. Our experienced consultants have created a myriad of tools to assist them but it generally boils down to flowcharts and spreadsheets.

Spreadsheet upon spreadsheet of data all related to specific parts of our process. Creating this monster requires a PhD in astrophysics and an army of analysts to create and keep in synch. No one understands how it hangs together expect the original artist that created it. And although they can answer any question using this resource, it appears as a clouded crystal ball to virtually everyone else.

How Skore solves this issue

What we’ve just described is a status quo that has existed for many years. Visio, Lucidchart and similar tools have simply created an electronic version of brown paper and string, or it’s more modern equivalent, whiteboards and sticky notes.

It doesn’t bring a fundamental change in thinking. It doesn’t address the issue of getting an organisation to recognise, articulate and love it’s processes in an ongoing and strategic fashion.

Skore is different first in its approach and secondly how that is applied in the tool. Skore is designed to make it easy for more people in an organisation to learn how to capture and describe processes.

And when I use the term ‘process’ I mean multi-level flowcharts that include all the other things an organisation needs to function. Not just the work activities, nor even the people, but all the systems and other information required.

All this information is stored in a single model, not multiple flowcharts and multiple spreadsheets that need to be kept in synch manually, but a dynamic model that includes all the information linked together.

This is also not some technical architectural tool. Skore follows some very simple rules that makes it very easy to understand and use. It’s not for everyone and while everyone can create boxes and lines in Visio, a significantly larger portion of your organisation will be able to develop good quality processes in Skore.

A model in Skore can start at the top of the organisation showing our strategic buckets of work and, clicking a button, you can zoom into any level of detail you wish.

It becomes a true strategic view of an organisation’s processes where the CEO is looking at the same model as everyone else.

Contact us to try Skore today.

Create Rich Interactive Procedures

In this video I take you through a demonstration of an example process and procedure portal created in Skore app.

Traditionally Skore app has been focused on process design and analysis with our view on making it as quick and easy as possible. As we worked with more and more teams they told us that creating documentation with the process information was also very important.

Once you’ve designed a great process it is only really great if your team use it. We provided tools to help create documentation such as image export and save to PDF but we really wanted to do something better.

With Skore app you can create ‘easy to read’ process flows that tell you what happens, who does it and what outcome should we expect from each step. Process flows present the steps visually which makes them easy to follow, especially if the process has choices, alternatives and branches.

On to this we can add further information, detailed descriptions, images, video, audio and links to systems and documents. This means that the procedure is no longer just a static document but provides access to all supporting information presented in a clean interactive flow diagram.

Check out our Learn pages to find out how to build Rich Interactive Procedures in Skore app.

Getting Better at Business Requirements

The approach to process, that forms the basis of skore app, has been used widely in many organizations. It has been particularly successful in implementing large scale ERP and CRM systems. In one example a team, that we have worked with extensively in the past, helped implement an ERP in 6 weeks when the leading Systems Integrators had quoted 6 months!

In project after project we see high levels of success using this approach. A single process model is defined up front and used throughout the project to capture business requirements and communicate those effectively. The documentation is used by the technical team to configure the solution. It is used by the change team to manage the transition. It is used by the business to express their needs.

Yet research, such as this by IAG Consulting, tells us too many projects fail due to poor requirements. Here we explore one reason this happens and introduce our approach to mitigating these issues.

Asking users what they want

A major problem any analyst will find in a requirements gathering project is that the business owners, or users, don’t often know what they want. Of course no one would ever say that outright. You may get the odd “I’m not sure but I’ll know it when I see it.”

Business users are normally full of ideas and thoughts about how a new process or system ‘should’ work. And yet so often, when delivered the product is deemed not fit for purpose. Whose fault was it? The analyst who didn’t interpret what the user asked for correctly?

In any project we must make a number of assumptions and test these as we go. But we still need a start point, and the further down that road we can start the better.

The problem with asking users what they want is that’s actually a very difficult question to answer. These users tend to be immersed in their day jobs. Busy fighting the very fires you’re there to help put out with your new project.

They’ll have lots of ideas, they’ll see lots of things that can be improved all the time. They are probably overwhelmed by things that could be fixed. They won’t have had time to think through which would add more value. What they’d do first and what would have the most impact.

Answering a different question

You approach them when they have little time to spare and other important things that need to be completed. They will not have the time, or energy, to start making sense of what they know. As Daniel Kahneman describes in Thinking Fast and Slow, when asked a question that’s too difficult to answer with an immediate response we default to answering an easier question.

And so your best intention, to gather requirements, through the use of interviews, surveys and workshops can result in a lot of answers to the wrong questions.

Ask users what they do

And here is where a process approach can help. For those already familiar using a Business Process Management System (BPMS) to automate processes this will not come as a surprise. Rather than asking users what they need we ask them what they do. A far easier question to answer and one a lot less likely to be substituted for something else.

As you discuss what happens, and visualize this in a process flow, the users move this information from their minds and out on to the page where they can move on to the next thought. They start to see connections and are reminded of ideas and thoughts they’ve previously had.

The process flow provides context for these ideas and reminds the user of the purpose. While talking about what they do they will find it easier to accurately describe what is wrong. And more importantly provide ideas on how to do it better.

A good process visualization tool will provide a quick and simple way for the analyst to capture these thoughts and ideas against the process. The tool will provide easy reporting so that these important requirements can be reviewed and analysed later.

A further requirement, for an approach like this to work, is the ease with which the user can understand the visualization you are building with them. They will not see and make these connections if the diagram they are looking at is made up of hieroglyphics only an expert will understand.

The process must be simple and easy to understand, providing enough information to accurately describe how things work but not overwhelm or confuse the audience.

Requirements are part of a process

The typical analyst will be familiar with modelling business process flows. However, the use of business process flowcharts tends to be tactical. In the development of a new digital product it may be used to define the flow of data or a user journey.

In the projects where we see the greatest success, process flows are used strategically to guide the project. Hence why they make a good business requirements tool. They are used to describe the work that the organization does and then act as a framework in which we position the requirements for the digital change.

A process diagram is not a deliverable as part of a requirement. Requirements are attributes of the business process.

As such, the process model becomes a point of reference for all stakeholders in the project. It is the model through which the business expresses its needs. The same model the design and development team use to build the solution. And the same model the training team use to manage and support the users once the solution is implemented.

Again this can only be achieved with a process approach that is easy to read and easy to understand for as many people as possible.

A better approach to business requirements

To help others take advantage of this approach we have started to create a general approach to business requirements gathering and definition.

This includes a Business Requirements Canvas, an early stage tool to help understand the purpose of the project, the key processes and any key technical and user requirements. The Canvas informs the project vision and objective, captured in the Strategy Template. And finally the process approach, or IDEFlite, a simple yet powerful approach to process that can be used as the single common framework for the project requirements.

Learn more and download the tools here.

Jobs To Be Done (JTBD)

Jobs_to_be_done_3This customer came to us with an adoption problem. They had a product that clearly solved a well know problem in their industry. For some reason user adoption of the product was relatively low with fewer customers getting the expected value than they expected. There was a suspicion, within the company, that the design of the user interface was responsible.

We reviewed the product and used a Jobs To Be Done (JTBD) approach to understand how the product fit within the target customer’s workflow. Jobs To Be Done is a simple but powerful approach that helps to better understand the context in which users use your product. It highlights hidden opportunities and helps you set the right direction for your product strategy.

The Product

The product itself is a data analytics platform used in the Oil & Gas industry. It helps to improve the efficiency of oil well drilling by using analytics to improve the behavior of drilling operations. Problems during oil well drilling can be extremely expensive. Spotting problems early enough can potentially save millions of dollars in lost drilling time.

The Problem

In many cases the customers were not seeing the expected benefit. After implementing the product it wasn’t leading to the correct change in behavior. These companies were not seeing the expected savings. On closer investigation it seemed that the various users in the customer were simply not using the product and therefore not getting the benefit of the insights it provided.

This is what lead our client to suspect the user interface as the potential problem. We certainly wouldn’t rule this out but before we could confidently make that call we needed to understand the context better. After reviewing the product and receiving both sales and technical presentations we sat through the product training and interviewed the implementation consultants. The next step was to interview the customers and understand how they saw the product fit in their existing workflows.

Jobs To Be Done

The Jobs To Be Done approach lets you look at what the customer is trying to achieve and then place the product within that process. Our adaption of the approach ensures that every step adds value to the overall goal. This means when you place the product into the process you can clearly see where it’s adding value, where it falls short and potential opportunities to improve.

The approach is relatively easy to apply and results in a set of simple visualizations the team can use to discuss improvements of all sizes including potential strategy changes. While we interviewed our client’s customers we sketched out these processes and asked them to help us position the product in the process. We then discussed the strengths and weaknesses of the product in this context.

We created a high level view of the drilling process in Skore app:

Simple high level view of the oil drilling process

This showed us where the product supported the customer’s activities. Next we broke the most important step, drilling the well, into a more detailed view. At this point we identified a series of user journeys that each resulted in a different outcome. Again each outcome added in some way to the overall customer goal.

Detailed user journey

Each of these user journeys followed the key steps that the customer did to achieve those goals including using the product. These visualizations made it very easy for the customer to describe what they needed and where the gaps were. When shared with our client, not only were we able to articulate why the users were not using the product as expected but our client also identified other improvement opportunities.

Providing the high level context first allowed the whole team to see the relationships between the different parts of the product and how each of those fit into what the customer did. It made it much easier to discuss improvements and understand the impact on the customer before any development even took place.

Product Strategy

These simple visualizations really helped to understand the product better. It helped the development team understand the context of what they were building better. It helped the sales team position the product better. It helped the implementation team train new customers better and it allowed the whole company to reach a shared understanding about how their product worked and what value it provided. As a result it guided a new product strategy that allowed them to deliver more value for their customers.

photo credit: Rig night shot 2 via photopin (license)


Skore app for Agile

One of our first videos and still one of my favorites! Some of our customers use Skore app to bridge the gap between User Experience (UX) and Agile requirements (User Stories). They map out high level user journeys then break these down into details that can be used as user stories.

With it’s simple interface and ‘map at the speed of talking’ capability, Skore app is ideal for use in live discussions to explore user stories based on the context of the user journey. This video provides a high level overview, with a soundtrack by Spiritchaser, we hope you enjoy it!

Epics Vs Stories – keep it simple stupid

Epics_vs_storiesEpics vs Stories – what’s the difference?

It’s one of those perennial discussions in Agile. Epics vs Stories. What’s the difference between these two types of requirement in Agile Development? In this article, they describe Themes in addition to Epics and Stories. So now you have Themes, Epics and User Stories. And of course some teams break User Stories down into tasks as well. So lets recap, that’s Themes, Epics, Stories and Tasks. Oh I forgot to mention that other teams also define Technical Stories!

Like the article referenced above many people try to make a distinction between all these things. But lets consider first what are Stories for and why have we ended up with different ‘types’? Then I’d like to explain how we try to keep things much simpler.

What are stories for?

It might be more prudent to try and argue the difference between a User Story and a Use Case but that’s a well trodden path. User Stories are here to stay and very popular for good reason. Fundamentally a User Story is a software requirement that describes something that needs to be delivered by the development team.

What makes User Stories different, from previous ideas of requirements, is the narrative that surrounds the idea of using Stories to ‘do’ Agile Development. By this I mean that every time anyone asks what a User Story is there is a cacophony of enthusiastic voices extolling the importance of the conversation. As one seasoned agiler once said to me “a User Story is the promise of a conversation”.

Others may say that the importance of the User Story is that it’s from the ‘user’ perspective, or that it’s a story rather than a formal Product Requirement Document written in abstract business terminology. What I see is better communication. Better communication between the business and the engineers, better communication between customers, users, Product Management and the team who have to build the requirement.

The User Story construct is simple, therefore easy to remember and, once you’ve got the hang of it, easy to implement. And once you’ve written User Stories, have you ever had to explain to a non-techie what they mean? As I say the narrative that follows the User Story around, like a rather pleasant smell, adds to its efficacy.

Simply put the purpose of a User Story is to effectively communicate value adding requirements, without ambiguity, in a form that is easy(ish) to estimate.

Why have different types of stories?

The main reason appears to be a conflict between ‘effective communication’ and the ability for an engineer to estimate the amount of work. Part of what makes agile so agile is that work tends to be broken down into small chunks that can be delivered in a short space of time. Instead of building a vast sprawling metropolis of features and functionality that no one uses, you deliver small parts that incrementally deliver value. If any of these small parts fail to deliver the expected value they can be easily brushed under the carpet out of view a lot easier than 100,000 development hours. What’s more, you’ve failed fast and, hopefully, learnt a valuable lesson.

Effectively communicating requirements requires storytelling, but storytelling doesn’t always come in small parts. So when a Story appears to be too large to deliver incrementally (i.e. too big to effectively estimate how long it will take to build) then it becomes an Epic. Or is that a Theme? I was once told that a Theme is a collection of Epics but others will say that a Theme is a different type of collection of stories…

Then, of course, some teams may break a Story down into tasks, sort of sub-stories, that they can deliver in the next sprint but the value is not realised until the main Story is finished. Sounds a bit like an Epic? Well it would be if the parent Story didn’t already belong to an Epic…

You can see the problem starting to emerge… confusion. If Stories are to support effective communication then they need to be simple. If we now have to explain to various audiences the differences between the levels that makes communication so much harder.

So what can we do?

Here at Skore Labs we prefer to stick with User Stories, the difference is that we accept that stories can be deconstructed to create more stories. One story can be made up of multiple smaller stories. And this deconstruction knows no bounds. We don’t force our stories into an arbitrary set of levels (e.g. Epics, Stories and Tasks, the story telling analogy ran out of levels pretty quickly). We keep deconstructing stories until we can effectively estimate how long they will take.

We do something else that’s different, we link stories together into visual flows. This may seem more like use case flows, or story mapping, but as we deconstruct stories these flows provide valuable context that would otherwise be lost. When you’re down in the detail you need to make decisions on whether individual stories can be delivered quickly or whether they rely on upstream or downstream stories.

We believe stories should be kept simple so as to facilitate communication, discussion and reduce ambiguity. This is our solution we’d love to hear how you deal with this?

UX Workshops with Skore app – How To

While there are many out there that will feel quite comfortable using Skore to drive a UX workshop it’s more common to see it used alongside the whiteboard and sticky notes. Where Skore really makes a difference, in this use case, is in providing an online, interactive set of documentation as the output of the workshop. Here’s how.

The problem : workshop documentation & post-workshop confusion

One of the common challenges I’ve come across is post-workshop confusion. There are always a lot of very useful and insightful discussions that take place in the heat of the moment, yet in the days and weeks afterward it can be hard to remember the details. Most people take photos of the whiteboard and document discussion items and actions for reference later.

“Transition from free-form to sequential documentation” 

The problem with this approach is in the translation from the free form nature of the workshop into the sequential and flat nature of traditional documentation. When a question arises later about why a specific decision was made, or what is the impact of changing something we discussed in the workshop, it can be difficult to draw that out of the documentation. One UX consultant I spoke to recently told me that most of their customers never read the documentation and just call them directly with questions. Even they have trouble remembering exactly what was said and what it referred to so they waste a lot of time discussing and reviewing the documentation on behalf of the client.

A typical UX workshop

DeathtoStock_Wired6_smallMost UX workshops we see are looking at how to improve the user experience of existing products and sites. In the workshop you bring together the research (interviews, observations, eye tracking etc) in the context of the steps the user takes. Then the team discuss the issues, identify opportunities for improvement, define goals and assign actions for the next steps.

The user’s steps are often represented by screenshots and stuck on the whiteboard. Known issues and feedback are highlighted through sticky notes and marker pens. The remaining space on the whiteboard is used to sketch out improvements and ideas.

Creating interactive documentation with Skore

Before the workshop define the steps of the user’s journey using What and Why boxes in Skore. Attach any screenshots to each step for quick reference. Add notes to the steps to highlight important feedback items and findings. This should be roughly the same as what you start with on the whiteboard in the workshop.Example_skore_OT

During the workshop capture additional notes, create detail views where necessary and attach photos of the whiteboard to the relevant steps. Before everyone leaves the room walk them through what you’ve captured in Skore so they are familiar with it and then send them a link using the Just Skore it export feature. Simple as that.

Instead of traditional boring documents in pdf, the customer will have an interactive set of documentation, built around the user journey, describing the problems and the suggested improvements. And of course these can be updated as you go. This will save you a lot of time and clarify things for the customer.