King for a Day

Overview

Most user research is bounded by what exists. You show people a prototype and ask what they think. You watch them use the current product and note where they struggle. These methods are essential, but they anchor the conversation to the present state. King for a Day breaks that anchor.

The exercise is simple: ask participants to imagine they have unlimited power to change the system they use every day. No technical constraints, no budget limits, no organizational politics. If they were king for a day, what would they change? What would they add? What would they eliminate entirely?

The value isn't in the literal ideas (which are often impractical). It's in what those ideas reveal about unmet needs, misaligned priorities, and pain points that users have stopped complaining about because they've accepted them as permanent. When a soldier says "I'd make it so the system only interrupts me when something actually matters," they're not giving you a feature request. They're telling you that the current notification system has failed at its most basic job: distinguishing signal from noise.

King for a Day belongs to the LUMA Institute's family of design thinking methods. It works because it gives people permission to think beyond the constraints they've internalized. In organizations with rigid hierarchies, whether military, enterprise, or government, that permission is especially powerful. People who would never critique the current system in a formal review will redesign it from scratch when you frame it as imagination rather than complaint.

When to Use It

• At the start of a redesign, when you want to understand what users actually want before you show them what you've designed.
• When you suspect users have adapted to a broken experience and stopped reporting problems because they've normalized them.
• When working with users in hierarchical environments (military, government, healthcare) where direct criticism of existing tools may feel uncomfortable.
• When you need to generate bold ideas before the team narrows down to what's feasible.

Skip it when you already have a well-defined problem and need to evaluate specific solutions. King for a Day is a divergent exercise. It opens up the problem space rather than closing it down.

How It Works

Gather a small group of users, typically four to eight, and give each person a large sheet of paper or a whiteboard section. Pose the question: "If you were king for a day and could change anything about this system, what would you do?" Give them 10 to 15 minutes to write, sketch, or diagram their ideal experience.

Then bring the group together. Each person presents their vision. As they share, capture recurring themes and surprising ideas on a separate board. The facilitation goal is to draw out the "why" behind each idea. When someone says "I'd get rid of half the alerts," the follow-up is "Which half, and why those?" That's where the design insight lives.

After everyone has shared, cluster the ideas into themes. You'll typically find three to five dominant threads that represent the group's real priorities. These threads become the foundation for your design direction.

The exercise works best when you keep the energy generative and avoid evaluating feasibility in the room. The moment someone says "we can't do that because of the architecture," the creative permission collapses. Feasibility comes later. Discovery comes first.

Tips

Frame it as play, not feedback. The word "imagine" does heavy lifting. "Imagine you could change anything" gets better results than "what would you improve," which still anchors to the current state.

Use physical materials. Markers, sticky notes, large paper. The physicality lowers the barrier to participation and produces artifacts you can photograph and reference later. Digital whiteboards work but tend to reduce the energy in the room.

Pair it with a prioritization exercise afterward. King for a Day generates a wide field of ideas. Follow it immediately with something like Target Prioritization to converge on what matters most.

Watch for the quiet participants. In hierarchical groups, junior members may defer to senior voices. Give individual writing time before group sharing so everyone's ideas are on paper before social dynamics take over.

Photograph everything. The raw artifacts, the clustered themes, the participants working. These become powerful evidence in stakeholder presentations later.

The Output

A set of user-generated visions for their ideal experience, clustered into themes that reveal underlying priorities and unmet needs. This is qualitative, generative data. It doesn't tell you what to build, but it tells you what problems are worth solving and how users think about the relative importance of different aspects of their experience.

The output feeds directly into design direction, problem framing, and prioritization exercises. It pairs especially well with Target Prioritization or Impact/Effort Matrix as a next step.

Related Methods

• Target Prioritization: Comes after. Use the themes from King for a Day as inputs to the target, ranking which user-identified priorities deserve the center ring.
• How Might We: Comes after. Convert the themes and insights into actionable problem statements.
• Interviewing: Runs alongside. Individual interviews before or after the group session can surface ideas that participants didn't share publicly.
• Persona Profile: Comes after. The visions participants describe often reveal distinct user archetypes with different priorities, feeding persona development.
• Affinity Mapping: Comes after. When you have raw ideas from multiple participants, affinity mapping helps you find the patterns across them.