Christine Vallaure wrote about a new protocol from Google in UXdesign. Basically, if the interface is generated fresh for each request and then thrown away, the unit of design stops being the screen and becomes the system that decides what screen to make — which is context design, not screen design.

When I think about on-demand UI generation, I reach back to how working with computers are supposed to work in Star Trek (The Next Generation and after): interaction is a mix of voice commands and pushing buttons on the interface. The interface is a mix of permanent buttons (for example steering the ship) and on demand UI generated to fit a specific purpose, like running an experimental process.

When somebody (in-universe) designed the system, they made the system of UI elements, and how generated elements should work as a system. As even generated elements can work without any apparent onboarding (provided the users have domain knowledge), it’s not only about the individual elements, but also the rules how complete flows come together.

The slowness of writing code was doing a kind of work we never named. It forced you to think carefully about each line, and when the slowness left, the thinking left with it.

This is also true to various design practices, we are loosing benefits that we got due to how the design process was working. For example:

• Agents are great at finding patterns in a large repository of user interviews. If the researcher outsources this work, their tacit knowledge doesn’t get built. It’s much harder to jump in to a conversation with the team on a new user need or recognizing assumptions. The team’s product intuition gets shallow.
• With new design tools creating full prototypes in a few minutes, the designers don’t build an intimate knowledge of the solution space. Finding new interactions and spotting holistic problems becomes much harder.

These will cause long term degradation, as experience gets shallow and less effective. Less mature teams will not even recognize what they are loosing, while more mature team may develop practices to counteract this, like human-in-the-loop reviews and rely on institutional knowledge.

This boils down to being more mindful and explicit what goes where in the design process, that is being more rigorous, which helps in understanding which step can go fast, and where the team needs to slow down.

☕ Consistency is spelling, coherence is voice

I was leading a team working on a fairly complex CRM product. We were building a design system, had good coverage, and once we worked through the design debt accumulated over previous eras, the screens looked great and (more importantly) consistent.

But we still saw users struggling across workflows. After some analysis, I got the designers to work together on our fundamentals. That meant going beyond design system components and screen-level consistency. In our “20% design time” we worked on understanding the business strategy, how well we served users’ goals in each flow, and what principles guided our decisions. In short, we s on consistency and started thinking about coherence.

Consistency is important in designing anything beyond the simplest software. It’s the practice of solving the same things the same way: using buttons that look the same for the same kind of action, making navigation predictable, using the same terms for the same concepts, and following brand guidelines.

Consistency is the result of systematic design. Good designers solve things consistently by following their own system, and we create design systems so that teams can be consistent across people and surfaces.

Since inconsistency is so visible, design teams often set consistency as a target in various ways, through design system compliance checks or explicit review standards. It also makes consistency-related projects, like design systems, easy to pitch to product and engineering partners, because the work shows up in the product they already care about. Consistency is also a good rationale for rebranding projects, since making software look more uniform, pages following a single logic.

This is where the tension with consistency shows up. Taken to the extreme and applied rigidly, it leads to uniformity and a stiff UX that doesn’t actually help users. Because consistency keeps the focus on internally visible problems, it can overshadow the problems real users face. Making design system compliance the target pushes designers to follow guidelines first and put usability second.

Coherence is the practice of systematic design. It goes beyond solving problems consistently. It also applies the system to which problems get solved, and considers how problems and solutions fit together as a whole. For example, destructive actions can consistently use a red delete button. If we consider the user’s intent, the button should add more or less friction depending on the consequences of the action.

Coherence connects business and user goals to design activities and gives designers an approach, a set of principles that leads to consistency in the broader system beyond the immediate screens. Applied across each layer of the design, brand, design system, journeys, and user flows, it produces consistency at every level.

To put it simply, consistency is spelling things right, while coherence is getting the grammar and the voice right. Consistency works in the touchpoints of the user journey, while coherence works across the entire journey.

Where coherence considers users’ context, builds on their existing knowledge, and serves their goals, consistency mostly serves the team’s internal goals. Those matter too, consistency speeds up development, eases maintenance, and enables better brand alignment.

Consistency makes things more predictable, timelines for the team. Coherence adds predictability also for the users. Both are essential qualities of efficient and effective design.

Naturally, coherence requires more thought and practice than consistency. Teams with weaker alignment and lower maturity tend to focus on consistency first, because it offers visible, stable guardrails that are easy to align to. As teams get better, they can make more coherent decisions. For example they can work on sharper brand articulation that enables real brand alignment, not just consistent colors and logos.

Even consistency takes effort to achieve. A good design system is key, treating it as a living system rather than a strict rulebook is what enables more coherent designs. A gammar and voice that helps designers express intent, evolving as the team’s understanding of users and business deepens.

If consistency is spelling, coherence is the grammar and voice your product speaks in. Spelling keeps you legible; voice is what makes the product actually say something.

The work for design teams isn’t only to police the rules, it’s to decide what the product is trying to say, write those principles down, and then walk a full user journey end to end asking not only “is this consistent?” but “does this sound like us, and does it help the user get where they’re going?” Coherence begins with the first flow you’ll start on this week.

This is a post from my newsletter, 9am26, subscribe here:

🍪 Things to snack on

Achieving and Balancing Consistency in User Interface Design by Michael Zuschlag Provides a taxonomy of inconsistency types (irregularity vs. contradiction), strength assessment, and impact analysis. Argues that contradictions are almost never acceptable, while irregularities can be justified with empirical evidence of user benefit.
“We want the best overall user experience for our users, and sometimes that means trading consistency for something else.”

🀙

Coherent, Not Consistent by Bruno Bergher The article argues that coherence (making every part feel like it belongs) should replace consistency as the design priority. Identifies information architecture, nomenclature, and brand as the three areas where consistency remains essential, while everything else should be cleaned up periodically rather than blocking innovation.
“Coherence means making sure every part of your product feels like it belongs there, instead of trying to make them exactly the same.”

🀙

Consistency by DOC A nuanced exploration that treats consistency as multifaceted: spanning familiarity, business efficiency, predictability, and identity. Argues that consistent principles matter more than consistent UI, and that consistency should create room for differentiation rather than suppress it. Uses the jazz metaphor: improvisation works because the foundation is consistent.
“The real power of consistency isn’t in uniformity, it’s predictability.”

🀙

Consistency in Design is the Wrong Approach by Jared M. Spool Reframes the consistency question entirely: instead of asking “is this consistent with what we’ve designed?”, ask “will the user’s current knowledge help them use this?” Notes the irony that interfaces designed around current knowledge end up feeling consistent anyway, reinforcing the wrong lesson.
“When you think about consistency, you’re thinking about the product. When you’re thinking about current knowledge, you’re thinking about the user.”

🀙

Design for Coherence, not Consistency by Carlos Yllobre Frames consistency-first design as artificial, rigid, and innovation-killing, while coherence-focused design is natural, flexible, and innovation-friendly. Argues that design system teams should empower product teams as contributors rather than passive consumers of locked-down components.
“When designing for coherence your focus is not just on building and maintaining the user interface elements, but on the problem you are trying to solve and the people you are trying to help.”

🀙

Design Dialects: Enhancing User Experience by Michel Ferreira Introduces the “design dialect” concept, systematic adaptations that maintain core principles while developing context-specific patterns. Two examples, one from Shopify, how their Polaris system went from 0% to 100% task completion for warehouse pickers by creating a dialect, and another example from Atlassian and it’s Flexibility Framework: Consistent, Opinionated, Flexible tiers.
“Consistency isn’t ROI; solved problems are.”

🀙

Design Systems: Coherence vs. Consistency by David Linke Analyzes coherence and consistency as a spectrum rather than a binary. Consistent systems (like Bootstrap) are efficient for less experienced teams, while coherent systems require more skill but produce more tailored user experiences. Concludes that organizations should be prepared for both approaches depending on context.
“A consistent design system is highly coherent, but a coherent design system does not need to be highly consistent.”

Obviously just telling a coding tool to go and build something is not enough to solve any kind of real problem, there needs to be a clear intention. On the highest level, there should be a clear goal. As a thing gets built, the solution space gains more granularity and the rendering of intention (translating what you want into something concrete) should infuse each of the decisions. Rendering the intention also updates how we think about the initial intention, creating the iterative nature of design.

In the case of Tilecraft I had a clear high level intention (create a tool to explore pattern making), and a fairly well described solution space (in the form of a book describing each of the pattern operations). But even in this case, a lot of the finer interaction details (like canvas navigation, the drag and drop interactions of the pipeline or the snapping on the controls) needed a lot of back and forth and multiple iterations. Seeing the interactions in action also helped me to better understand what a pattern making tool should do.

But intention is just half the equation. Using a coding tool well is not just about having clear intentions, it’s also about how the intention gets rendered into a concrete thing. The tool sometimes needs us getting into the weeds and creating very specific examples or definitions it can absorb. Intention sets the direction, but we also need to update it to make progress. Like I needed to have almost specification-like descriptions for some of the geometric transformations, to get the outcomes I was after

Product design boils down to two main activities: creating a shared intention and rendering the intention. AI tools can definitely help in some of the activities supporting these.

As AI tools are getting better and better at rendering intentions, there will always be parts where someone needs to craft things by hand. Like creating core primitives of a visual language, writing an important library for the code base, or making sure a user flow is coherent. The Pareto principle applies: 80% of the experience gets done much faster by an AI tool, but the remaining 20% will need a systematic design effort. That’s precisely where clarity of intention matters most.

Creating a shared intention is still not something these tools can do well. Even in a small team, getting the right understanding of the problem space (even if research is sped up), and developing a shared intention takes effort. People need to watch the same TV channel, so to speak, to be able to create things that fit together.

With Tilecraft, I didn’t even need a shared intention, but clarifying my own intentions took time. In creating a shared intention both “shared” and “creating intention” are both important and hard parts, and AI tools don’t solve these fundamental challenges of design.

Some shared intention can be developed while working on the project, we understand the problem space as we work on the solution space. But initial assumptions about the problems limit the solution space, plus the almost ready feeling of the output also makes it harder to step back and restart with a completely new approach.

So to make sure we do have a clarity of intention, we need to approach the outcomes of vibe-coded software with extra mindfulness. External validation (like usability testing) gets even more important. We will need new ways to treat “almost done” prototypes as “barely 10% there” products. The speed of AI-generated output can trick us into thinking we’re further along than we are. Slowing down to question whether the output matches the intention (not just whether it looks finished) is a real skill to be developed.

We found that the phenomenon described in these posts—cognitive exhaustion from intensive oversight of AI agents—is both real and significant. We call it “AI brain fry,” which we define as mental fatigue from excessive use or oversight of AI tools beyond one’s cognitive capacity. Participants described a “buzzing” feeling or a mental fog with difficulty focusing, slower decision-making, and headaches. This AI-associated mental strain carries significant costs in the form of increased employee errors, decision fatigue, and intention to quit.

I believe this will be another example for the automation trap. While these agentic systems are great at automating some of the tedious work away, they also great at automating easy decisions, leaving only the hard ones for the human part of the centaur.

Also tools like Claude make it very easy to work on multiple things parallel, making the hard part taking even more energy (Pablo Stanley’s Fried writes about this).

So how to deal with this?

• Take a step back. Making decisions and orchestrating agents (or directing orchestration agents) is highly creative work, you not only need to take a step back to get new ideas, but also to let your brain breathe a bit.
• Embrace the new design process: sketch → agentic prototype → define details (doc, Figma, other tools). While sketching and writing also take brain power, they add a good mix of microtasks with various levels of cognitive costs.
• Mindful time planning. The old rule of thumb of max 5-6 hours of deep work per day is still very much true, even if agents can do more. Plan ahead what you want to get done over the day and week, and allow yourself to close your Claude Code terminal once those are done.

While speed always remains a concern, in the end distance wins the race.

☕ The power of stepping back

I love painting. The simple act of putting the brush to the canvas gets me easily into a flow, and I can get lost in the details. Getting lost in the details however can lead to an unbalanced painting, evoking a sight not quite right. When I learned to paint, our teacher forced us to stand up, take a step back, and take a look at the painting-in-progress from a different perspective. This simple practice allowed the students to the shift their view and focus back on the whole before diving back into the details.

This same practice applies to all creative work, and especially to design.

Stepping back is a cluster of techniques and psychological mechanisms that share a common principle: creating distance from the immediate problem to unlock more creative solutions.

The mechanism is simple. Distance removes details, and allows abstract structures to emerge. Construal level theory confirms this effect, psychological distance (temporal, spatial, social, or hypothetical) shifts thinking from concrete to abstract processing, activating broader conceptual networks and enabling novel associations.

At it’s core it’s a divergent move, and it only works in rhythm with convergence. You need focused work to step back from, and you need to step forward again after.

In design practice, stepping back manifests in several categories of activities:

• abstracting the problem to strip away surface details (overcoming functional fixedness),
• changing the resolution or zoom level at which you examine a design challenge,
• reframing through lateral thinking or extreme “what if” questions,
• brainstorming questions rather than solutions.

These share the same structural pattern, as they interrupt the default tendency to fixate on familiar framings and force the mind into unfamiliar territory where new connections become visible.

An additional challenge with digital design is that virtual constructs are too close. It’s hard to step away from a concept that lives in the computer and observe it from a different perspective. This is why this needs to be an intentional practice, embedded into the design process or the daily rituals. This way, we can avoid getting stuck on staying close to difficult problems.

There are a few exercises I’ve found are helpful as a way to step back:

• Getting feedback: When getting feedback, imagine you’re standing side by side looking at the work together, not presenting to an audience. This shared vantage point creates distance from the work and puts you on the same team as the reviewer.
• Narrate decisions: by articulating choices and tracing thinking during the design process, questions can arise more naturally.
• Journey view: what’s happening before and after the current experience, looking at screens from a broader, more holistic perspective helps to zoom out and see disconnects.
• Physical activity: focus on the body shifts perspective away from the immediate thinking and makes space for new ideas to emerge.
• Change context (work from cafe): changing the backdrop can lead to new connections forming between ideas and concepts, forces to re-evaluate existing links.
• Use forced perspective shifts: questions like “What if users scale up” or the Despicable Design technique of deliberately designing for evil outcomes manufactures a psychological distance.
• Change angle: As with a real painting, standing up and looking at the monitor from a different angle, zooming in and out in your tool helps to reset your focus.

All of these share one thing: they break the spell of proximity.

For leaders, these practices can be made intentional part of the design process. Practices like having weekly checkins, daily standup style meetings, mixing up environments or structure, alternating between pair and solo design, and asking for clearer collaboration steps all help in establishing a cadence of convergence and divergence.

This is a post from my newsletter, 9am26, subscribe here:

🍪 Things to snack on

Stepping Back from the Canvas by Myra Naito Gives three tips of changing perspectives to be able to look at your canvas in a different light. While these tips focus on more graphic things, they can be a good inspiration to apply to other types of work. Our strongest, clearest vision happens in the center of your eyes. Anything in your peripheral vision is not in focus. Your physical proximity to your canvas can often leave most of your work in your peripheral vision.

♦

Creative Cognition: The Construal Level Theory & Psychological Distance by Aditya Shukla Explains how construal level theory provides the scientific basis for the creative step back. Higher construal levels activate broader conceptual networks, enabling novel associations. Spatial distance (solving problems for a faraway university), temporal distance (reflecting on past events), and personal distance (solving problems for others) all measurably increase creative output. “High construals create a pathway to fetch creative ideas because the links between different ideas are more abstract & broad.”

♦

Zooming In and Out of UX Design Resolutions by Jared M. Spool Uses the Eames’ Powers of Ten film as a metaphor for how UX design operates at multiple resolutions, from screen-level to ecosystem-level. Each resolution reveals different problems and requires different tools, making the ability to zoom in and out a critical design leadership skill. “Each change in resolution requires a different set of skills. They are all still UX design skills, but because the problems and tools change, the skills necessary to solve those problems and operate those tools will change.”

♦

The importance of zooming out in the design process by Fabricio Telxeira Zooming in and zooming out are the two main components of the design process. The article shows a few ways to practice zooming out: forcing your brain to be idle, looking at designs from a different perspective, presenting designs aloud, show it around, writing summaries about concepts. Zooming in and focusing on a problem is relatively easy for us designers. The challenge resides in stepping back and judging the designs you are creating with fresh eyes and different perspectives.

♦

12 Powerful Creative Problem-Solving Techniques That Work by Scott Jeffrey Describes three stepping-back techniques: the 30,000-foot view (zooming out with a detached mindset), deliberate incubation (walking away to allow subconscious processing), and contextual reframing (examining underlying assumptions). All share the principle that mental distance from the immediate problem enables fresh insight. “Deliberate mind-wandering supports creativity.”

Joplin -> Obsidian

To fit my file-system-based + data ownership requirements, I ended up switching to Obsidian. It’s a tool I’ve read a lot of people praising, and after a brief testing period, I’ve been gradually switching my note-taking flows one by one.

The process to migrate from Joplin to Obsidian is fairly simple:

1. Set up your new Obsidian vault.
   • I’m syncing it through Dropbox simply by creating my vault in a synced folder. I’m not using my notes on mobile, but the Remotely Save plugin would work if I wanted to.
   • I’ve added a few plugins to make my life easy:
     • Find orphaned images: to clean up the trash images from webclips (like all those useless Substack avatars)
     • Local backup: to have a proper backup besides Dropbox syncing
     • Local images plus: to download images when clipping from the  web, to make sure that when an article disappears, I still have the full article with all the imagery
     • Tag wrangler: to make managing tags easier
     • Omnnisearch: faster search results
2. Export Joplin notebooks with the “Markdown + Front matter” option
   • I’ve started with my webclips folder, as it’s quite chunky (2500+ notes), and needed some tidying up.
3. Tidy up the exported folder. The pro/con of working with files: import is just copying files, but clean up is up to the user
   • On Mac, the filenames were truncated, which caused problems for some weird note titles, and images which were disconnected from the original files in the process - I fixed as much as I could with scripts, the rest I’ll just fix as I go
   • Moved the images and other files in a separate _resources folder to the note folder and updated note files with the image locations
   • Updated tags: Joplin accepted tags with spaces, Obsidian doesn’t like that, so more scripts to help with that

A thing I notice is how Obsidian is better at nurturing my data-hoarding hobby, for once, tag management is much nicer. In Joplin (and even earlier in Evernote), I let my tagging grow organically, but now I spent some time in structuring my tags better, which also helps in organising how I think about topics.

Pocket -> Instapaper

Last year, after Mozilla decided to close Pocket, I ended up with a stash of over 4000 “read-it-later” links. Besides using Instapaper, I’m also saving fewer things to my reading backlog - both curating things faster and throwing away uninteresting things. Meanwhile, I’m reading through the past items, relying on Obsidian’s better tagging and web clipper tools, plus on Claude to help with some of the more tedious reviews, like articles broken up to multiple pages.

Claude Code

After testing multiple agentic tools, I settled on using & subscribing to Claude Code, opting for learning one tool in depth, rather than multiple ones superficially.

I’m still figuring out the best approach. I’m sometimes chatting with Claude on the web for quick questions, using Claude Code from the terminal most of the time (Ghostty is great), and opening VSCode to see files and make edits. Generally, the terminal feels the fastest and most information-dense.

How I use Claude Code is all over the place: making side projects, exploring creative ideas, organizing and researching information. Like this week, I’ve made a simple command to summarise YouTube videos with timelines to explore (I like to read much more than to watch a long-form video). A lot of things I’ve considered hard or time-consuming in the past turned into something to pick up and finish between my morning yoga and the first meeting of the day, removing the need to learn uninteresting things or go through tedious processes.

In many ways this interaction (or maybe better described as meta-interaction) reminds me of modern mobile games: the energy mechanism (the tokens might run out), the sorta slot-machine like waiting for results (though Opus 4.6 is much more consistent than earlier versions), the easy to enter a flow state (“Huh, I’ve been working on this problem for 4 hours now?”).

The cognitive exhaustion / decision fatigue after a longer session is the most interesting effect I observed sofar. But I also feel more energised, with much of the tedium removed from making things.

It’s fun, but needs mindfulness on how to use responsibly - just because results are easy, sometimes the goal was not to get easy results in the first place. Kinda like how having a “2nd brain” in notes makes people do more thinking instead of doing, having such tools can make people doing more (instead of thinking).

My current rule of thumbs with using agentic systems as a tool are:

• If I intend something I make to be read / used by humans, I should craft ideas, words, and pixels myself as much as possible. If that’s not feasible, I’ll build a separate and appropriate workflow to establish systems and not just launch rapid-fire slop.
• Spend more social and 2nd brain time (here is how Obsidian helps) to balance out agentic time.

Usually, people go through three phases in expressing their intentions.

• People start with a low intention and are more focused on expressing it. Early career professionals (junior designers are in this phase, thinking a lot about how things look, how tools work, what style to use. Additionally, there are people in this phase who don’t value design as much, thinking it’s shallow and superficial, and that using a good enough front-end framework is enough for design. “Just make it look nice” or “Copy what Notion does” are attempts at expressing an intention that was already unclear. Intention is unformed, without shape, it’s more of a wish for something to exist. It’s why “just generate a website with AI” style efforts fail.
• Over time, some will get better at having a clear intention. Mid to senior-level designers and people who develop a good product sense will get here, they have a clear intention that they can also express with their tools (like design, writing, or code). There is an internal image of what good looks like and how it should be expressed.
• Unfortunately, most things (almost certainly most software worth creating) need multiple perspectives coming from multiple people. These perspectives have to come together in a shared intention. The task of the person designing changes is to create a shared intention, a common understanding, combining the clear (or not so clear) individual intentions that can be expressed. Senior to senior+ designers, driver contributors are in this phase.

AI tools (more specifically, the current breed of generative tools) don’t carry an intention. They create plausible things based on the input they are getting. The output will be probably right most of the time (especially as we get better and better tools). But there is no innate intention, so they also cannot create or propagate a shared intention across multiple interactions with multiple people.

AI tools have some use in expression, as they can quickly express an intent. If the intent is well-formed, the expression will get better. But a well-formed intent is also an act of expression. If people try to ask the tool to shape the intent, it will fail, mostly since AI tools are not great at creating high-density expression. At least writing well, but also designing and coding well, are still highly useful expressions of intent that fit into a chain of tasks, maybe containing AI tools down the line.

☕ Combating groupthink

Products might fail for many reasons. One of them is if the team ignores feedback or evidence and goes all in on an idea that, in the end, was not the right one. While there could be approach or organisational issues, a reason for failure is also if the team focuses too much on internal agreement, that is, groupthink, in their decisions.

Groupthink is a phenomenon of social decision-making, when the group members value internal harmony and lack of conflicts higher than great outcomes. Because agreement can be based, for example, on the loudest voice or the lowest common denominator, this can lead to mediocre decisions, a lack of innovation, and ultimately wasted resources.

The need of humans to be accepted by their groups makes this phenomenon extremely common in situations where disagreement might lead to social rejection. Since product development is usually a high-pressure situation, there are quite frequent opportunities for friction between team members in almost every step of the process, like interpreting research results, brainstorming ideas, prioritising, or reviewing design choices.

Why the group ends up with a mediocre choice is best understood from social dynamics, deadlines are tight, there is a lot of external pressure, there are dominant personalities in the team, dissent or disagreement isn’t encouraged, or the team is lacking diversity of thinking.

While designers are not always responsible for facilitating disagreements, since by its nature, design questions highlight internal problems, they often find themselves trying to figure out the group consensus.

Besides finding themselves in these situations, the nature of the design process also lends itself to facilitating discussions. Alternating convergent and divergent thinking is a key piece of handling groupthink. When there is space to analyse data and mature ideas outside of conversations (divergent thinking), it’ll be much easier to articulate new ideas or connect the dots in a discussion (convergent thinking).

The convergent — divergent thinking is not our only tool. Holding structured critiques helps in better discussions, not only in design, while advocating for user centricity helps understanding and accepting how data from outside of the immediate group can be helpful, for example, via user research.

As a side note, while a team’s decision-making processes are important to scrutinise, groupthink might start much earlier, when teams are formed. When designers hire other designers like them (focusing on similar skills or a similar background), it can lead unintentionally to a group that rarely looks for information from the outside and falls into the groupthink pattern. A purposeful hiring process is the first step to avoid this.

Fostering psychological safety is a tool for leaders to improve decisions. This makes giving a fair stage to every viewpoint part of the culture. There are a few things any leader can start doing:

• Leadership’s role is to be a role model for being open and respectful to opinions other than their own.
• Encourage dissent by not only providing a space, but explicitly asking for opposing ideas, as that makes it easier to articulate things that go against the majority opinion. Workshop plays like pre-mortems help solidify the point that failures need to be discussed.
• Blameless post-mortems, after something happens, focus on learning from mistakes.
• Celebrate constructive conflict by recognising how challenging ideas and having a healthy debate about options lead to better outcomes.
• Empower junior team members, since they might be reluctant to speak up and question more senior members.

However, the above only works if the team’s roles are set up to do this.

• Facilitation needs to be a clear role, to have someone who guides the discussion and makes sure everyone gets to talk. Rotating the facilitator (like having it on a schedule, or choosing randomly at the beginning of the session) helps work on problems with different discussion patterns.
• Devil’s advocate can be defined as a role tasked with challenging ideas or coming up with counterarguments.
• Cross-functional participants provide new perspectives and generally improve collaboration across teams.

These tactics won’t easily solve all problems with groupthink; besides being mindful when creating team practices and rituals, it’s also a continuous effort that needs leadership. However, open dialogue and diverse perspectives are powerful tools to create truly impactful products.

This is a post from my newsletter, 9am26, subscribe here:

🍪 Things to snack on

Groupthink by Wikipedia Wikipedia, as always, has a good overview of the topic, adding some history too, including the insight that the effect is not that well researched and understood, but has plenty of anecdotal evidence. There is also a longer section on prevention, with some really nice advice, like inviting experts from outside the group to get a different, out-group perspective. Diversity of all kinds is also instrumental in preventing groupthink. Individuals with varying backgrounds, thought, professional and life experiences etc. can offer unique perspectives and challenge assumptions.

♣︎

Groupthink: when collective decisions go wrong by Dr. Hannah Rose A few more general examples of how groupthink impacts our daily life, and strategies to avoid it (for example, assigning some group members to play devil’s advocate). As in work situations, in non-business contexts it also helps to put a little structure into decisions, like treating ideas as something transitional, but not the final solutions, until the other members can articulate concerns. Groupthink can be responsible for collective decisions that are irrational, risky or even illegal. In a group setting in which cohesion and a positive social opinion of the group are highly valued, members put a lot of energy into ensuring harmony within the group.

♣︎

Groupthink in UX Work by Samhita Tankala A nice summary of symptoms of groupthink in design contexts (collective rationalisation, illusion of unanimity, self-censorship, and direct pressure on dissenters), with some guidelines to prevent it in UX activities. The guidelines are grouped by various scenarios (like during ideation or in remote environments), which in itself also describes the common situation where groupthink can arise. Groups benefit from hearing diverse perspectives. For that to happen, group members have to feel comfortable in sharing their thoughts. We need to intentionally build awareness around groupthink, acknowledge that it occurs in group settings, and create a work environment that prevents it from happening.

♣︎

Common-Knowledge Effect: A Harmful Bias in Team Decision Making by Evan Sunwall While team decisions are generally better, the diversity of perspectives is often wasted, as team members are more comfortable discussing information they all already understand (the common-knowledge effect) and underutilise information only a few members know. One result of this phenomenon is groupthink. The article has a nice example scenario of how this happens, what biases are in play, and what some strategies to mitigate the effect. As counterintuitive as it seems, increasing the number of people involved in a difficult decision will likely decrease decision-making quality. Whatever unique knowledge individuals could offer to deliberations often goes unshared or disregarded.

There are three ways how automation can change a person’s job: do more of the same thing, do the same thing better, and do different things.

Better efficiency: automation helps to do more of the same given resources like time. Things like repetitive tasks or time-consuming tasks are good targets for this kinda of improvement.

• For example, in product design the new tools are promising to help create more screens faster, and go from an idea straight to a prototype, these are all efficiency improvements.
• As a pitfall for better efficiency, it’s often just part of the process that is easy to automate, and the parts that are harder to automate will get even harder, requiring more attention from whoever is doing the task. For most people doing the job, this will also mean more pressure to deliver more things in the same amount of time.
• A historical parallel would be the telephone and email that didn’t decrease the amount of communication, but rather allowed for both more communication and more complex systems established with communication.
• Design considerations would be to help the users to connect tasks to the overall workflow better, and get enough insight on the status of the automation runs to intervene if needed. So humans should be able to stay in the loop easily.

Better effectiveness: automation can improve precision and quality, following established standards more closely and making time for the person to create more personalized experiences.

• In design tools, I see less focus on this type of automation, maybe since quality is harder to measure. Most tools don’t seem to be focusing on reducing preventable errors or even applying heuristics meaningfully, outside of trying to follow design systems more closely.
• Since quality often depends on nuance, judgment, and understanding the complexity of human motivations and needs, it doesn’t always lend itself to easy automation. Automation bias leads the remaining people in the system to be less vigilant of possible errors.
• A historical parallel would be the standardized manufacturing process, which enabled more precise machinery that led to more consistent product quality.
• Design considerations: thinking about the existing workflow, what drives quality, and augmenting the human in the loop with new capabilities around the quality attributes helps to create centaurs building on both sides’ strengths.

Shift role and focus: with automation doing the more basic things, people can do higher value and more interdisciplinary things.

• In product design the shifting role is part of the discussion when designers are described as having to code, having to know more of the overall product development process, and needing to do more strategic and often cross-team work beyond their immediate product teams.
• Obviously, the pitfall is, that workflows, companies and maybe even what people would want to do often don’t enable shifting of roles or enabling a bigger focus, which leads to people getting laid off.
• A historical parallel could be how secretaries moved from typing letters to a broader role of managing offices and supporting executives and teams.
• Designing for shifting roles usually goes beyond immediate product design, as it requires changes more on the organisational level. However, with new people doing different things differently, there is an even greater need for thoughtful product design, connecting workflows across different disciplines.

A special mention should be how automation might enable new users to perform the same tasks. Like providing customer service in a foreign language, or improved accessibility to tools.