Unstructured and unconstrained discussion has its place in a UX workshop, but it is difficult to manage, especially if topics are potentially sensitive (e.g., insights from stakeholder interviews), there is a wide breadth of roles and perspectives present, or workshop attendees are hesitant to speak out loud openly due to the presence of dominating participants.
Dot coding is an effective workshop technique to use for driving collaborative, focused discussion around a wide set of items, that could otherwise be difficult to manage in a group session.
Definition: In dot coding, individuals react to a set of items by placing colored dots with preassigned meanings on each item in the set.
Much like dot voting, dot coding requires participants to place colored dots on items within a set. However, in dot voting, participants use the dots to prioritize the items or narrow down alternatives and converge to a smaller set of concepts or ideas. Dots are essentially votes that can be tallied to score the items against each other.
In dot coding, dots are not participant votes, because dot coding is not a forced-ranking exercise. The goal of dot coding is not to prioritize items in the set, but rather to elicit reaction and encourage discussion of those items. Therefore, the items in a dot coding set are not alternatives to be chosen or narrowed down; they are parts of a whole to be considered.
Like dot voting, dot coding can be applied to just about any topic. Some common contenders for dot coding are:
- Research insights
- Design ideas
- Internal initiatives
- Product features
The Dot-Coding Process
Follow this process to facilitate a dot-coding activity in a UX workshop:
1. Post up the items and gather materials.
Most commonly, tangible materials include sticky notes posted on a wall and colored sticky dots. Using a predetermined key, participants place the colored sticky dots on items to capture their reactions to those items. The process is especially useful after an affinity-diagramming exercise if there are too many individual items than can be effectively discussed. In this case, the dot coding applies to the clusters of items, rather than individual items.
An alternative to posting up items on sticky notes is to provide a simple list of statements, themes, or insights to be coded. This is an effective approach if the set of items has been previously generated or agreed upon outside of the workshop.
2. Establish which categories you will use and how you will represent them.
Categories can be just about any potential attitude or perspective participants may have about the items. It’s useful to include categories on opposite ends of a spectrum in order to balance discussion, such as “agreement” and “disagreement” or “surprising” and “unsurprising.” Limit the activity to 4 or less categories in order to mitigate unnecessary complexity and enable easy identification of patterns and themes after the activity is complete.
Decide how you will represent each category. Traditionally, different-color sticky dots are used for each category.
Alternatives:
- Use shapes instead of colors to represent the codes. For example, instead of using red dots to signify disagreement and green dots to signify agreement, use star stickers and caution-symbol stickers, or smile- and frown-faced stickers. Using shapes instead of colors alleviates any obstacles color-blind participants might face in distinguishing colors.
- Use markers instead of sticky dots. If sticky dots are unavailable or cost-prohibitive, give participants colored markers and instruct them to draw a colored dot or shape beside the items.
- Use a digital whiteboard and virtual “dots” for remote sessions. Google docs, Miro, Mural, FigJam, or any other collaborative platform that allows users to drop and drag shapes will work.
3. Explain the codes.
Before the coding takes place, explain the activity and the codes that will be used to participants. There should be a key of codes posted in a place that participants could easily reference during the coding activity. For example, the key could be written on the whiteboard beside the set of items or placed in a designated, easily accessible online space.
As general rules of thumb for facilitation:
- Participants can place as many codes as they wish (from zero to all) on any item — as long as the codes do not conflict, such as “disagreement” and “agreement” or “relevant” and “irrelevant.”
- Participants are not limited to the number of dots they can use.
- There is no reason for any one participant to put several dots of the same color on the same item (e.g., several red dots on one item); again, the purpose is to elicit reactions, not tally the dots to rank the items against each other.
4. Code the items.
All participants approach the items and begin placing their dots on the items together, without discussion. This process should be done silently to eliminate groupthink or influence. Time-box this activity in order to set expectations about how long participants should spend reflecting on the items.
Alternatives:
- If you are worried about some participants influencing others’ coding, apply an alone-then-group structure: Have participants individually jot down the codes they will place on the items before going up to the board.
- For distributed teams, use a virtual board and allow the coding to take place asynchronously over the course of a few hours or days.
- If anonymity is critical for your context or culture, send participants a digital poll where they can code in privacy.
- Provide additional structure if there are a lot of items or participants. Distance the items across the room and have participants move from one group of items to the next in a structured, timed sequence.
5. Reflect and discuss the output.
Step back from the board (virtual or physical) and allow participants to take in the results of the activity. Drive group discussion with open-ended questions, such as:
- What stands out?
- On which items does it seem that we mostly agree?
- On which items are there differences in opinion?
- Are than any outliers?
- Why does an item have a specific majority code? (Why do we think this item is surprising, critical, irrelevant, etc.?)
Depending on the goal of this activity, detailed discussion may not need to happen in a workshop session. If this is the case, take the input back to the core team for discussion or apply it to the next step, as appropriate.
Examples of Dot Coding in UX Workshops
Example #1: Dot Coding to Discuss Stakeholder-Interview Insights
In one UX workshop, dot coding was used to discuss insights from stakeholder interviews that had been conducted outside of the workshop. After presenting interview themes to the workshop team, the facilitator listed the themes on large sticky papers that were posted to the walls. The group used colored sticky dots to capture reactions to each of the themes:
- Yellow = Surprising. Items that you:
- Have not heard or considered before
- Did not expect to hear
- Red = Disagreement. Items that you:
- Do not concede
- Have a different perspective about
- Green = Agreement. Items that you:
- Acknowledge and strongly agree with
- Have a similar viewpoint with
- Blue = Essential. Items that you:
- Feel strongly about
- Believe are critical to recognize or improve for the digital strategy to be successful
This dot-coding activity was helpful for drawing out reactions to potentially sensitive stakeholder feedback and opinions. The group was also able to quickly identify if there were any glaring areas of disagreement with stakeholders. The discussion of these acted as input to their goal of creating a UX-vision statement for their team.
Example #2: Dot Coding to React to Hypothesis Journey Maps
In another UX workshop — a journey-mapping workshop — a core team created hypothesis customer-journey maps for a set of personas. Here, both dot voting and dot coding were used to facilitate the activity.
After filling in the journey map and identifying pain points, the team used dot voting to quickly isolate the biggest hurdles that users faced across the journey. This activity helped the group prioritize and focus on a narrow set of pain points.
In a second stage of the workshop, user representatives joined the workshop. As participants presented their hypothesis maps to them, users used 2 different stickers to react to the items on the map and code them with their perspectives.
Two codes were used:
- Silver star stickers = Agreement. Items that:
- Align to your experience
- Match your expectations
- Yellow caution stickers = Disagreement. Items that:
- Do not align to your experience
- You do not agree with
Allowing users to code their reactions to assumptions within the hypothesis journey map enabled them to physically contribute to the map to reflect their experience and help validate or evolve the assumptions.
Conclusion
Dot coding is a useful UX workshop activity to help:
- Make sense of a large number of insights or ideas
- Understand group-level reactions to a set of items, such as surprise, agreement, or anything else
- Balance perspectives between two different groups (e.g., designers and users or stakeholders and core-team members)
- Determine if and where there is disagreement or misalignment in the group
- Drive and manage deeper discussion in a group setting
Dot coding is flexible and can be adapted to serve a variety of formats and workshop goals. Tailor this dot-coding process to your workshop goals to:
- Create an artifact that captures sentiment and perspective in real time
- Equalize contributions in a workshop and encourage equal participation from all participants
- Help workshop participants understand areas of shared agreement and common ground.
