Dot voting

“Would you tell me, please, which way I ought to go from here?”

Lewis Carroll, Alice in Wonderland

Working through a Discovery phase with a large team, choosing what the next steps should is best done through common consensus. The problem is with several people in the room each with differing opinions, finding a common consensus can be challenging.

This is wear dot voting comes into its own.

As you will have seen from previous posts, a lot of our Discovery has been done in the form of post-it notes on the wall. Working this way makes our information visual and allows many people to work together and consume the same data. An example of this was mapping our stakeholders: we wrote the roles of the stakeholders on post-its and put them on the wall. This gave us a clear vision of how many stakeholders were involved and how they grouped together or related to each other.

With an idea of who our stakeholders were, we needed to investigate more about them what their experiences, pains and needs were in relation to our current service delivery model in order to drive the Discovery process. However, you don’t need to investigate all of them in detail. Indeed if you were to do so you would never move on from the Discovery phase! But how do you choose which to focus on?

With the choices on the wall and in sensible groupings, hand each team member a marker pen and invite them to place a dot on the post-its that represents the direction they would like to go in next. Each person has 3 votes cost by drawing 3 dots. Once everyone has finished, you can see which post-it has the most dots.

You are likely to end up with three to five leading choices. In the case of stakeholders, we took these labels and started developing personas. However, we also applied this method to deciding which features to take through a design studio. In fact, you can apply it to anything.

Dot voting. A quick, simple way to gauge a common opinion among a group and decide which way you ought to go from here.

dot voting

Design Studio

Once we have a set of validated personas in place the next step in our Discovery process is to understand the journey for each person.

We started by each adopting a persona and walking through the current journey making decisions as they would. By putting yourself in each customer’s shoes and stepping outside of your role as a BCC employee, you are able to objectively experience the process that we ask our residents to go through.This enables you to get a good idea of what is working, what is not and what our customers actually want.

Next it is time to get creative.

We gave everyone in the team a pen and a piece of paper folded into 4 quadrants, set the timer to 10 minutes and asked everyone to draw what they’d like the process to be. It doesn’t matter whether you can draw or not, the point is to get stuck in and share your ideas.


At the end of the 10 minutes take it in turns to talk through your drawing and your thoughts. It is likely that you will find some common themes between people. It is also likely that somebody will offer an obscure yet genius idea that resets your thoughts about the whole process. Through the group presentation and discussion you will gain a common consensus on which ideas should be taken forward.

On a master sheet of paper start bringing together those ideas and sketching an end to end process. By the end of this you will have a visualisation of your goal ready to turn into a prototype.



Using personas during discovery

For the past month we have been working on creating 2 new digital services for the Council. The first ‘Select a school place’ is nearing the end of its discovery phase and the second ‘Tell us it’s broken’ was launched a few days ago.

In order to best represent the customer during this process we start by creating a series of user personas. These start out as proto-personas where we flesh out what we imagine the users will be, give a brief description of their background and examine what they wish to achieve as well as what difficulties they may encounter in doing so. Finally we start to think about how we might be better be able to overcome these issues.

Inception schools stakeholders

Key stakeholder proto-personas generated during an “Inception Workshop”

Over the next couple of weeks we validate these personas by interviewing as many users, and potential users, of the service as we can. We check that the issues we initially identified are actually the main issues users are experiencing, and that we have identified the correct types of user for this service.

Once we have gathered enough information we go back and create a new set of validated users, using real issues identified in our interviews to create our final personas. We will then refer back to these personas as we create our new digital service, asking them to test and validate our ideas and prototypes as we build them. This ensures we keep the user at the heart of our design process and identify early on what areas to concentrate on whilst be build our prototypes.

validated personas

Personas validated through interviews

Retrospective: Looking back to move forward


Most project management manuals encourage you to look at lessons learnt or perform a “root cause analysis” on any problems that occurred. This is usually done at the end of the project or significant project stage to gather learnings before going on to the next. It often takes the form of a document  with an executive summary, scope, review, and next steps.

Here in HQ Digital, we are working to improve the digital services we offer. We are doing this in 3 distinct stages; Discovery, Alpha and Beta. We have come to the end of the first discovery of the first service, and are about to start our next. Therefore, we thought it important to take stock of our journey so far and gauge how the team were feeling about things in a Retrospective.

adjective; looking back or dealing with past events
noun; an exhibitions or compilation showing an artist’s work over time.

Rather than produce a lengthy Lessons Learnt document we put the headings “Happy”, “Sad”, and “Mad” on the wall, gave everyone a pen and some post it notes and added our thoughts under the appropriate headings. Instead of taking only an objective view to write a report from, we complemented this with a subjective view on the impact that the way we are working has had on the team.

This process enabled everyone on the team to voice their successes, praise teammates and also raise their concerns and disappointments. We took time to congratulate the team on the notes under “Happy” and recognised the elements of the process that everyone had enjoyed with a goal to replicate them in the next discovery process. We addressed the disappointments under “Sad” and frustrations under “Mad”, discussing different points of view and resolved how we would avoid repeating these incidents in our future work.

By going through a Retrospective in this format, we gave all team members a voice and picked out the things that impact a team as well as a project. This allowed us to discuss changes we needed to make to our environment and working styles to create a productive yet enjoyable working team. Some of this came from quick wins like changing the layout of the chairs and tables. Others will come from the way we approach challenging situations in the next Discovery process we run.

We left the session with a clear idea of what we already do well and what improvements we need to make. We also left as a more resilient team, knowing that frustrations we had felt had been shared, listened to, understood and hopefully would be prevented in future.  

A lot of projects will require a written Lessons Learnt document in a set structure. However, running a Retrospective exercise beforehand will give the opportunity to learn from your peers and collectively review the process providing invaluable insight and raising lessons that perhaps you hadn’t thought of before. Give it a go.