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.

Sketching Business Models

This excellent video post from Josh Seiden describes a neat approach to understanding some of the mechanics of your design. I wanted to build on it based on our own experiences.

I like the approach, a simple model, to drive discussion and understand the key parts of the system. But I felt there could be a little more detail, not too much so as to destroy the usefulness of the approach. The problem I saw straight away is, what happens if I wasn’t in the room, or I read this later and forgot some detail.

I initially scanned through the video without audio and it was difficult to make sense of the two diagrams without the narration. I started to sketch a slightly different approach and found myself doing it in Skore app. It’s not really what Skore has been designed for but I think it works nicely.

What Skore brings is the structure around key details, what’s happening, who is doing it and what are the relations between these things. Here is the sketch I made of the Ecosystem diagram (first example) in Skore app.

Screen Shot 2015-11-23 at 12.07.51

I started sketching out the Buyer’s Club example too and was interested when Josh started annotating the diagram. This time I added the annotations as attachments in Skore. You can see these as the little paperclip icons on the boxes.

Screen Shot 2015-11-23 at 12.11.15

The benefit of adding these as attachments is that I can instantly report on them. Just click on Analytics > Reporting and I can see something like this.

Screen Shot 2015-11-23 at 12.13.08

Of course that data can be instantly exported to a spreadsheet for further analysis or to be inserted into a report or proposal.

Note. As of writing this article the version of Skore app I have used above has not yet been released so some of these features are not available. If you want to beta test this version why not send us an email

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?

The real life aspect of your product

Embedding the activities a user do outside of your software helps clarifying the purpose

Having a product that solves a problem is one (important) thing; but how nicely your solution fits in existing user’s ways of working ?

When exploring product ideas with Skore, I always try to keep in mind scenarios (user journeys) starting and finishing outside the software. It gives a different point of view to the features, puts them in the context of the real life.

For example, how are your map used once they are created ? Sure you could send over the file. But you might as well only need to send a snapshot of your map, to include an image directly in an email or presentation. Screen shots have their limits… It’s when considering this that we prioritized the export-to-image feature.

Skores helps to easily add “real life” context to your product vision.

3 things learnt:

  • The user journey always starts somewhere in the real life
  • Plan for the lowest attention span you can imagine
  • Take into account all external inputs / outputs required to continue the journey (e.g. have the credit card on hand when proceeding to checkout)

Find your MVP using Skore and user journeys

Skore helps you finding where to start

A Minimum Viable Product demonstrates your product works for a group of users. Easier to say than done, where to draw the line? Which feature should get in, and which doesn’t? A MVP helps you finding where to start.

Recently, I have used Skore to map all potential user journeys in a software idea I have. I skored the high level vision and went into a big deal of details; different user journey for different users; as far as reporting, tracking changes, etc. It helped me understanding the purpose of each step contributing to the achievement of the goal.

I still have no clue if most ideas will make it to the final product, but, while mapping in Skore, I could already understand my own idea better.

I could see what my typical user would do, what was needed. I found the right word to speak about these actions. At the end, this helped me deciding what is important and what is not.

Skore helped me to

  • Focus on the product high level vision first
  • Find the right vocabulary and names to talk about the components of the software
  • See what is important and what is not
  • Deduce the list of features for my MVP

Of course this list might change over time, but a few hours after having the idea, I could already see the features that are essentials and what was their purpose. It’s then easy to filter what is necessary to get started.

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.