ISTS UX Offsite — Designing the City Behind the City

Workshop Purpose

What We're Here to Do

Not a presentation about UX. An experience of design thinking — through building, storytelling, and shared discovery.

Five Goals

Build shared understanding of what UX Design can contribute to ISTS
Surface the most meaningful user and organizational challenges
Bring business stakeholders and designers into the same problem space
Identify where design can drive measurable impact across the full range of ISTS services, tools, and experiences
Leave with a small number of opportunity areas worth pursuing

Facilitator's North Star

The goal is not to teach UX. It is to let stakeholders experience design thinking by doing it.

The recurring question for both days:
Every time someone describes a user problem, the room asks: "How do we know this is true?" — and places it into one of three buckets.

We Know

Evidence exists — data, research, direct user feedback

We Believe

Strong assumption — not yet validated by evidence

We Don't Know

Genuine gap — research needed before acting

The Metaphor: Chicago Architecture

The morning tour grounds the workshop in a physical metaphor. Every building maps to something in ISTS.

City Element	ISTS Equivalent
Historic buildings	Legacy systems and processes
Infrastructure	Invisible services that support everything
New architecture	Innovation and modernization
City residents	Engineers, infrastructure & ops teams, security partners, and all ISTS customers
Urban planners	ISTS leaders
Architects & designers	UX and product teams
Utilities & transportation	Infrastructure platforms, DevSecOps, tooling, security

Hybrid Format

Running with Virtual Attendees

Some participants will attend remotely. This section covers what stays the same, what changes, and how to keep both groups working on the same problem in parallel.

What Stays the Same

All Day 2 sessions — User & Customer Journey, User We Rarely See, Future City, Opportunity Landscape, Leverage, Opportunity Statements
The evidence framework — virtual attendees apply it identically
Group assignments — virtual attendees are assigned to working groups and participate as peers
Dot voting and prioritization — done on the shared Miro board
All four output artifacts

What Changes

LEGO builds → Miro LEGO board (virtual attendees build digitally in parallel)
Architecture tour → virtual attendees join at 12:30pm; receive photo summary at lunch
Physical share-outs → room camera on LEGO tables; virtual attendees screen-share Miro builds
Gallery walk (Session 4) → virtual attendees navigate Miro board and drop digital sticky notes
Physical dot votes → Miro voting tool for virtual attendees simultaneously

Virtual LEGO — Miro Board

A Miro board version of LEGO Serious Play has been created for virtual attendees. They build using a digital brick library in parallel with in-room physical builds. Each workshop session has a dedicated Miro frame matching the physical prompt.

Before the workshop

Share the Miro board link with virtual attendees at least 3 days in advance
Ask them to open the board and verify edit access before Day 1
Send a 2-minute Miro orientation: frame navigation, how to add and move bricks, how to add sticky notes

During sessions

Virtual attendees build in their own labeled section of each frame
During share-outs, ask virtual attendees to screen-share their Miro section
At the end of each physical build phase, photograph each table's model and drop it into the corresponding Miro frame before share-outs begin
Group merge activities: virtual attendees move their Miro pieces into the shared group frame

Sync rule: Before every share-out, pause 60 seconds to upload photos of physical builds into Miro. This gives virtual attendees the same visual context as the people in the room — both groups should be looking at the same thing when someone is talking.

Room A/V Requirements

A/V is load-bearing for this workshop. Budget time to test it thoroughly the day before. A bad audio setup will effectively exclude virtual attendees from discussions even when they are technically connected.

Camera
Dedicated wide-angle camera (not a laptop webcam) on a tripod, pointed at the LEGO tables. Virtual attendees need to clearly see physical builds. Reposition between sessions if needed.

Room microphone
USB conference speaker (Jabra Speak, Meeting Owl, or equivalent) placed centrally. Test voice pickup from the far corner of the room. Echos and one-sided audio are the most common failure.

Playback speaker
Virtual attendees' audio must be audible to the full in-room group — not just whoever is seated near the laptop. Use an external speaker at room volume. Test this first.

Assign a dedicated tech host. Someone whose only job is monitoring the video call, managing virtual attendee audio, and flagging when a remote participant is trying to speak. The facilitator cannot do this and run the room simultaneously. This role is non-negotiable for a hybrid session.

Architecture Tour — Virtual Attendees

Virtual attendees skip the walking tour and join Day 1 at 12:30pm, at the start of lunch. The metaphor still works for them — it just needs to be handed to them directly rather than experienced in person.

Send before Day 1

The Chicago metaphor reference card (PDF) — same as in-room participants receive on the day
The building-by-building table and ISTS parallels (from the Overview section)
The observation card prompts — ask virtual attendees to write 3–5 answers before Day 1 starts, based on the metaphor description

During the tour and at lunch

Designate one in-room person to photograph 2–3 key moments at each building stop
Post photos to the Miro board before 1:00pm — before the warm-up begins
At 1:00pm, before the LEGO warm-up begins, spend 5 minutes orienting virtual attendees: one sentence per building and its ISTS parallel

The key is that everyone enters the afternoon sharing the same reference: Pritzker Pavilion as invisible infrastructure that disappears when it works and becomes a crisis when it doesn't. Virtual attendees can hold that metaphor without the walk.

Session-by-Session Hybrid Notes

Session	In-room	Virtual
Pre-Tour Briefing	As written — observation cards, tour framing	Skips. Receives metaphor reference card and observation prompts in advance.
Architecture Tour	As written — 7-stop walking tour	Skips. Joins at 12:30pm; receives Miro photo summary at lunch.
LEGO Warm-Up	Tower build (2 min) → Value build (8 min) → share-outs · Super Story extension	Miro board — Tower and Value frames. Text label for value Post-it. Super Story: positions model on shared canvas. Screen-shares during share-outs.
Session 1: Current City	Physical individual build → group merge	Miro — individual frame → moves pieces into group merge frame. Screen-shares during 2-min share-out.
Session 2: Fault Lines	Groups of 5 on shared city model	Assigned to a group; works in Miro alongside their group's physical section. Tech host uploads physical photos at phase end.
Day 1 Synthesis	Physical dot vote on whiteboard themes	Miro voting on the same themes (tech host mirrors physical whiteboard themes into Miro before voting begins).
Session 3: User & Customer Journey	Physical group build — 5 scenarios	Assigned to one of the five groups; builds scenario in Miro group frame.
Session 4: User We Rarely See	Individual build + full-circle share-out	Individual Miro frame; presents their own model in share-out round; drops digital sticky notes during synthesis.
Session 5: Future City	Physical group build	Assigned to a group; builds in Miro group frame.
Session 6: Opportunity Landscape	Physical card placement on 2×2 wall	Miro 2×2 matrix frame — places and repositions cards digitally.
Session 7: Leverage	Physical dot stickers on wall cards	Miro voting tool on same opportunity cards.
Session 8: Opportunity Statements	Small group drafting, share-out aloud	Assigned to a group; co-drafts statement in Miro text frame or shared doc.

D1

Day 1 — Discovery

Field experience · LEGO warm-up · Build the current city · Find the fault lines · Day 1 synthesis

12:30pm

Facilitator setup (no participants)

1:00–2:00

LEGO Warm-Up 60 min — 4 tables, everyone builds & shares

2:00–3:30

Session 1: Build Our Current City 90 min — 2-min timebox, all ~20 share

3:30–4:45

Session 2: Finding the Fault Lines 75 min — 5 groups of 4 by journey stage

4:45–5:00

Session 3: Day 1 Synthesis + Reflection

5:30pm

🚢 Water Taxi — departs for Chinatown (everyone)

6:30pm

🍜 Dinner — Chinatown (location TBD, everyone)

Pre-Tour Briefing

9:00am 30 min Full group

Frame the tour as fieldwork, not sightseeing. Distribute observation cards and sticky notes. Ask everyone to collect at least 5 observations.

Opening framing to read aloud "We are walking through a metaphor. Every building you see today maps to something we are dealing with in ISTS. Collect specific observations — write down what you see, not what you think."

Observation card prompts

What makes this city usable for the people who live and work in it?
What infrastructure do people rely on but never think about?
Where does old and new coexist well — and where does it create friction?
What would a first-time visitor find confusing, overwhelming, or invisible?

Hybrid: Virtual attendees skip this session. They receive the metaphor reference card and observation prompts before Day 1 and complete them independently. They join at 12:30pm.

Chicago Icons: Connecting Past and Present

10:00–12:30 ~2 hrs walking 7 stops

Meet: Chicago Architecture Center, 111 E. Wacker Dr. · Format: Walking tour, flat paved route · Access: Wheelchair accessible via alternate routes

Building	What to notice	ISTS parallel
Reliance Building 1895	Steel-frame construction — invisible, but makes everything after it possible	Foundational infrastructure users and teams depend on without knowing it
City Hall 1911	Built to project authority; hard to navigate if you don't know the system	Governance, approval workflows — necessary but often opaque
Thompson Center 1985	Every floor of state government visible from the lobby — radical transparency by design. Workers inside hated it: too hot, ungovernable, impossible to maintain. Now being rebuilt by Google.	Systems that signal openness vs. systems that actually work for users. A portal that exposes everything but serves no one.
Marina City 1964	"City within a city" — residential, commercial, entertainment in one structure	The ISTS platform ideal: all services discoverable in one place, by anyone who needs them
Daley Plaza / Picasso	Public-facing surface; the sculpture has divided people since 1967	Interfaces that require interpretation; what we show vs. what's underneath
Pritzker Pavilion 2004	Distributed speaker grid under 36 acres of lawn — invisible but essential	The closest parallel: hidden services that enable the experience
LondonHouse 1923/2016	1923 bank building transformed into modern hotel — façade kept, interior rebuilt	Legacy modernization: when to preserve vs. rebuild

Pritzker Pavilion is the key metaphor. Most people don't know there's a distributed speaker grid under the lawn across 36 acres. Without it, no one hears the music. That is exactly what ISTS provides — infrastructure that disappears when it works and becomes a crisis when it doesn't.

Thompson Center is the counter-metaphor. Designed to make government transparent and accessible — and experienced by the people inside as hot, ungovernable, and hard to use. Ask the room: which one does our system look like from the outside vs. feel like from the inside?

Tour debrief — use on the walk back or while waiting for lunch (5–10 min, informal) Don't run this as a structured session — let it happen as people walk. Throw out one or two questions and listen. The goal is to surface observations before they evaporate over lunch.

Which building stuck with you most — and what did it remind you of in ISTS?
Was there a building that made you uncomfortable or that you disagreed with the parallel for?
What did you notice that wasn't on the observation card? Something that surprised you.
If you had to pick one building that represents where ISTS is today and one that represents where you want it to be — which two would you pick?
The Pritzker Pavilion works because you never know it's there. Is there anything in ISTS that works like that right now — and if so, does the team know it?
The Thompson Center was designed for citizens and ended up being hated by the workers inside. Where does ISTS do that — something that looks right from the outside and is miserable to maintain from inside?

Hybrid: Virtual attendees skip the tour. Designate someone to photograph 2–3 moments at each stop. Post to Miro before 1:00pm. At 1:00pm, give a 5-minute tour recap to orient virtual attendees before the warm-up begins.

Lunch + Informal Debrief

12:30pm 45 min Unstructured

Play the Jaime Lerner TED Talk ("A Song of the City", ~17 min) while people eat. No framing needed before — just start it. Let the tour be fresh in the room when they watch it. The facilitator listens and takes notes.

Video Jaime Lerner: "A Song of the City" — TED Talk, ~17 min. Lerner transformed Curitiba, Brazil by designing its systems around the people with the least power and the most friction. Bus tube stations with level boarding and pre-pay — because bus riders deserve the dignity of subway riders.

What connects to the tour

Invisible infrastructure as the goal — Pritzker Pavilion's speaker grid and Curitiba's BRT both disappear from the user's awareness when they work
Constraint forcing better design — Curitiba couldn't afford a subway; Chicago's Reliance Building used steel because masonry couldn't go higher
Repurposing vs. rebuilding — Lerner adapted what existed; LondonHouse kept the façade, rebuilt the interior

Where they pull apart

Curitiba was designed for the person with the least power. Chicago's icons were mostly designed to project power, commerce, authority — Thompson Center tried for openness but the workers inside it hated it
Lerner had a philosophy and executed it deliberately. Chicago's skyline is 130 years of accumulated developer decisions. ISTS probably looks more like Chicago than Curitiba.

Drop this question before people get up "Lerner gave bus riders the same boarding experience as subway riders because he believed they deserved it. Where does ISTS give its users that? And where does it make them feel like the bus rider who has to flag down the driver and count exact change?"

Video debrief — additional discussion questions (pick 1–2, don't run all of them) Use these if the room is energized after the video and there's time before the warm-up. Don't force a structured debrief — these work best as prompts dropped into natural conversation.

Lerner didn't build a new city — he redesigned how an existing one worked. What's the equivalent move for ISTS? What already exists that could be redesigned rather than replaced?
Lerner started with the people who had the most friction. Who is that in ISTS's user base? Are we designing for them — or for the happy path?
The bus tube station works because it removes the decision of "is this the right bus?" — you pay once and the system handles the rest. Where could ISTS remove a decision that users and teams currently have to make?
Curitiba's BRT looks simple from the outside. The complexity is hidden in the system design. Is ISTS hiding the right complexity — or are we exposing complexity that users should never have to see?
Lerner had a philosophy: design for dignity. What's our equivalent? If you had to write one sentence that explained what ISTS is optimizing for — from a user's perspective — what would it say?

LEGO Warm-Up

1:00pm 60 min Individual builds

Two exercises: get people comfortable with the bricks, then put something real into a model before the afternoon sessions begin. The value build connects directly to the work — models stay on the table as a shared reference point for both days.

Exercise 1 — Build a Tower
2 min build · no instructions beyond "build a tower, anytime you like, as long as you're happy with it" · everyone shares within their table, 60 sec per person · 4 tables run simultaneously · total: ~15 min

After tower shares: "Does your tower remind you of anything we walked past this morning? Don't force it — but if a building comes to mind, name it." This seeds the metaphor vocabulary before the value build.

Exercise 2 — Build a Value
Deconstruct towers first · 8 min build · write the value on a Post-it and attach to model · share-out: everyone shares within their table first (~8 min, 4 tables simultaneous), then one observation per table to full room (4 × 2 min) · total: ~30 min

Build Prompt — Exercise 2 Build a model that represents a value that is important for our team.

Value directions for this group

Don't pre-seed specific values — let people bring what they bring. But if someone is stuck, these connect directly to the workshop themes:

Reliability
The Pritzker Pavilion value — earning trust by showing up invisibly, every time

Humility
The Thompson Center lesson — knowing that a system designed to look good from the outside can feel ungovernable to the people inside it. Rare in infrastructure orgs where technical confidence is high.

Curiosity
The "how do we know this is true?" value — asking before acting

Accountability
The Reliance Building value — owning the steel frame users and teams stand on, whether they know it's there or not

Trust
The Marina City ideal — between ISTS and its customers, between teams. The thing that makes a city-within-a-city actually work.

Craft
The LondonHouse value — knowing what to preserve and what to rebuild. Caring about what you hand to users and customers, not just that it functions.

Facilitation note: This is a mixed room — engineers, operators, security teams, stakeholders, and designers. "Value important to our team" will mean different things to different people. That divergence is the point — the variety of models is what you want going into the afternoon. Don't narrow the prompt. When someone shares, ask about the model: "Tell us about your model" — not "Tell us about your value."

After share-outs, push all models to one edge and clear the table. Everyone stands. Each person places their model in relation to the others — negotiating position, distance, and orientation to tell a collective story about how these values relate within the team.

Step 1 — Place
Each person moves their model into position. Talk to each other — negotiate. Try things. There's no right answer yet.

Step 2 — Walk
Everyone takes three steps clockwise to see the super story from a different angle. Does anything change?

Facilitator prompts "Is anything in completely the right place — or would you tweak something?" · "Does this have to come before that, or can they coexist?" · "We're not jumping to a conclusion — the process of negotiating this IS the outcome."

Why it works here: The super story surfaces how the room thinks values relate to each other — whether trust precedes accountability, whether curiosity and reliability are in tension. That's exactly the kind of implicit disagreement you want exposed before the afternoon sessions begin. The models stay on the table as a reference for both days.

Hybrid: Virtual attendees complete both exercises on the Miro board in dedicated frames. For the Value build, they write their value in a text label alongside their digital model. For the Super Story, they position their Miro model in relation to others on a shared canvas frame — the facilitator prompts them to negotiate placement the same as in-room participants.

Session 1: Build Our Current City

2:00pm 90 min Individual → Group merge

Build Prompt Build a model representing ISTS today — from the perspective of the people we serve.

Include: everyone who relies on ISTS — developers, infrastructure and ops teams, security partners, product teams — and the dependencies, barriers, pain points, and workarounds between them.

Phase 1 — Build
20 min · individual · silent

Phase 2 — Share-out
50 min · strict 2-min timebox per person · visible timer · 20 × 2 min = 40 min + facilitation = ~50 min · everyone shares, no exceptions

Phase 3 — Group merge
20 min · 3 tables merge individually first, then bring tables together

~20-person timebox rule: Use a visible 2-minute timer for every share-out. When it sounds, the speaker wraps up regardless. This is not rude — it is the only way everyone gets a voice. Every person shares — no skipping, no volunteers-only. Tell the room this before starting.

Discussion questions

What works well in this city?
What is invisible until it breaks?
What is overcomplicated?
Where do people get stuck?
What do we assume users already know?

Reliance Building callback: "What is the steel frame in your model — the foundation users and teams stand on without knowing it's there?"

Thompson Center callback: "Is there something in your model that was designed to be visible and open — but is experienced by the people inside as ungovernable or hard to maintain?"

Pritzker Pavilion callback: "What in your model would become a crisis tonight if it failed — but no user would notice it exists until then?"

Session 2: Finding the Fault Lines

3:30pm 75 min 5 groups of 4 — by journey stage

Build Prompt If a major earthquake hit our city, where would it crack first?

Groups of 4 each find fault lines in one stage of the user journey. Group A — Getting Started (onboarding, access, env setup) · Group B — Build Loop: Backend & Platform (CI/CD, build pipeline, AI-assisted dev) · Group C — Build Loop: Mobile (Mac build agents, signing, App Store, device lab) · Group D — Changing the City (change management, approvals, deployment) · Group E — When the City Floods (incidents, observability, data access, AI/ML). Build time: 20 min. Each group presents: 5 × 8 min = 40 min. Whiteboard clustering + evidence labeling: 15 min.

Groups are organized by user journey stage, not by team ownership — this forces every group to build from the resident's perspective, not the city planner's. Every person contributes to their group's build and story. See the Breakout Groups guide for full composition and city metaphors.

Capture on whiteboard — cluster into

User pain Employee pain Org pain Strategic risks

Apply the evidence test to every fault line as it surfaces. Write We know / We believe / We don't know next to each theme in a different color.

Building vocabulary for naming fault lines. When groups present, help them name what kind of crack they found — use the tour buildings as shorthand the whole room already shares:

City Hall crack — necessary process, but opaque and hard to navigate if you don't know the system
Thompson Center crack — designed for openness or visibility, but ungovernable in daily use
Reliance Building crack — foundational infrastructure failure nobody sees coming until everything above it collapses
Pritzker Pavilion crack — invisible until it breaks; the moment the speaker grid fails and no one hears the music
Daley Plaza crack — a public-facing surface that requires interpretation; what it means depends entirely on who you are

Session 3: Day 1 Synthesis + Reflection

4:45pm 30 min Full group

Fast close. The goal is to land the day, not debrief it. Keep this tight — the room is tired.

5 min — Lock evidence labels
Facilitator quickly reads each whiteboard theme. Room calls out: Know, Believe, or Don't Know. Move fast.

5 min — Dot vote on top fault lines
1 dot per person. Which 3 problems are worth exploring tomorrow? Circle the winners. These anchor Day 2.

10 min — Reflection round

What surprised you today?
What is one problem worth going deeper on tomorrow?
Which building from this morning best represents ISTS right now — and which represents where you want to be?

Facilitator close (5 min): "Tomorrow we go from what we found to what we should do about it. We'll look at these problems through the eyes of the people who live with them — and we'll build what a better city actually looks like."

Evening — Water Taxi to Chinatown

5:30pm CT Everyone

Water taxi departs at 5:45pm CT — plan for everyone to go. The ride down the Chicago River and into the lake connects back to the day's themes — infrastructure you use without thinking about. Comfortable shoes still on; it's a short walk to the dock.

Confirm departure dock location and boarding instructions closer to the date. Typical Chicago Water Taxi Chinatown route departs from Michigan Ave bridge area.

Dinner — Chinatown

6:30pm CT Everyone · Location TBD

Dinner in Chinatown. Location to be confirmed. No agenda — just let the conversations from the day continue without structure. The informal debrief over a meal is often where the most honest observations surface.

Book a reservation for ~20 at least 3 weeks out. Chinatown restaurants popular for group dinners: MingHin Cuisine, Lao Sze Chuan, Katy's Dumpling House.

D2

Day 2 — Direction

User journey · User empathy · Future city · Prioritization · Opportunity statements

8:30am

Facilitator setup (no participants)

9:00–9:15

Opening & Day 1 Recap

9:15–10:40

Session 3: The User and Customer Journey 85 min — 5 groups, one journey scenario each

10:40–11:40

Session 4: The User We Rarely See 60 min — full-circle share-out, everyone presents

11:40–12:00

Session 5: Build the Future City 75 min — 5 groups, one city domain each

12:00–1:30

Lunch

1:30–2:35

Session 6: Opportunity Landscape

2:35–3:15

Session 7: Where Design Creates Leverage

3:15–3:45

Session 8: Write Opportunity Statements

3:45–4:00

Closing & Next Steps

Opening & Day 1 Recap

9:00am 15 min Full group

Reground the room in what yesterday uncovered — briefly. The fault lines are on the wall. Name the top two or three. Then bring back the metaphor before the day begins.

Opening prompt "Yesterday we built a city and found where it cracks. Today we build what the better city looks like — and figure out how to get there. Before we start: which building from yesterday's tour keeps coming back to you as you think about what we found?"

Let 3–4 people answer. This reactivates the shared vocabulary from Day 1 before the first build. You're not looking for a "right" answer — you're reconnecting the room to the metaphor and signaling that the buildings stay in play today.

Session 3: The User and Customer Journey

9:15am 85 min 5 groups — one journey scenario each

Build Prompt Build the journey of a real user or customer — someone you talked to before today. From the moment they need something to the moment they either have it or gave up trying. Build the actual path, not the happy path.

Timing (85 min): 20 min build → each group presents (12 min × 5 = 60 min) → 5 min full-group synthesis. Keep presentations tight — use a visible timer.

One scenario per group — drawn from pre-work conversations

Group A — Getting Started
A new hire or developer starting a new project: environment setup, access, tooling, first build

Group B — Build Loop: Backend
A backend engineer's daily loop: write → CI → security scan → build artifact → iterate. Include AI-assisted dev moments.

Group C — Build Loop: Mobile
A mobile developer's release journey: build on Mac agent → sign → TestFlight → App Store → wait → (can't hotfix)

Group D — Change & Deploy
An engineer getting code to production: change request → approvals → deploy → validate → rollback if needed

Group E — Data & Incident
Two moments: a data scientist requesting data access + a backend engineer being paged at 2am

Put Groups B and C back-to-back in the share-out order. The contrast — backend ships on merge, mobile ships when Apple approves — is one of the most productive tensions you can surface. Let the room sit with it before moving on.

Discussion questions (full group, after all 5 present)

Where is effort highest in these journeys — and is it effort that produces value, or just friction?
Where are the handoffs — and what falls through the gaps?
Which journey is most different from what you assumed before today?
What does the user not understand that ISTS assumes they do?
Does this journey feel more like City Hall — necessary but opaque — or Thompson Center — designed for visibility, but experienced as ungovernable from inside?
Where is the LondonHouse moment — the place where the façade looks modern but something old and unmaintained is running underneath?

Session 4: The User We Rarely See

10:40am 60 min Individual → full-circle share-out

Build Prompt Build the user whose problems we least understand. Not the user you know well — the one you have assumptions about but rarely talk to.

Candidates: new developer who figured things out alone · platform engineer maintaining services nobody thanks · product owner navigating security requirements · security partner trying to enable but experienced as a blocker · support engineer triaging incidents at 2am.

Timing (60 min): 12 min individual build → full-circle share-out: every person presents their model (90 sec each × ~20 people = 30 min) → 8 min whiteboard synthesis · Every model gets a voice. Do not select or highlight only 3–4 models.

Daley Plaza callback: "Think about the Picasso — a public-facing surface that has divided people for 60 years. It means something to the people who commissioned it; it requires interpretation from everyone else. Where is the Picasso in how this user experiences ISTS? Something the team is proud of that the user just finds confusing?"

Key output of this session: A dedicated whiteboard section titled "Before we build anything for this person, we need to know…" — filled during share-outs. This becomes the research agenda.

Session 5: Build the Future City

11:40am 75 min 5 groups — one city domain each

Build Prompt It is three years from now. ISTS is recognized as a model organization. Build your district of that city — the part you own. What does it feel like to live and work in it?

Build experiences, workflows, relationships, behaviors — not technology. If someone builds "a new portal," ask: "What does a user feel when they use it?"

Group A — Future of Getting Started
Onboarding, access, provisioning — what does week one feel like?

Group B — Future Build Loop (Backend + AI)
CI/CD, AI-assisted dev, build reliability — what does the daily loop feel like?

Group C — Future Build Loop (Mobile)
Build agents, signing, release — what does mobile development feel like?

Group D — Future Change & Deploy
Change management, deployment, rollback — what does shipping feel like?

Group E — Future Operations, Data & AI
Observability, incidents, data access, ML platform — what does building with data feel like?

Timing (75 min): 20 min group build → 5 groups present (10 min each = 50 min) → 5 min cross-group synthesis: what futures do all five districts share?

Tour anchors for the future city. The buildings give the room shared vocabulary for what good looks like — use them if groups need direction:

Pritzker Pavilion — the aspiration. Infrastructure so reliable it disappears. Users never think about it.
Marina City — the integration ideal. Everything a user or team needs in one discoverable place, without needing to know the city layout first.
LondonHouse — the modernization path. Preserve what has earned trust; rebuild what has become a burden. The facade stays; the interior is entirely new.

If a group is stuck, ask: "Which of these are you building — and which one are you most afraid of ending up with instead?"

Discussion questions

What is different from the city we built yesterday?
What disappeared entirely?
What became easy that was hard?
What does the user relationship with ISTS feel like here?
Which of yesterday's tour buildings does your future district most resemble — and which one did you have to deliberately avoid?

Photograph every model — these will be referenced in the synthesis document.

Lunch

12:00pm35 min

Facilitator: review morning themes, finalize opportunity mapping wall, note recurring themes across groups.

Session 6: Opportunity Landscape

1:30pm 65 min Full group mapping

Map surfaced opportunities across two dimensions: User Pain vs. Org Readiness. Each card also gets a circle (high design influence) or square (systemic problem) marker, and an evidence dot (red = don't know, green = know).

Seed opportunity areas from Days 1–2

User & team onboarding Infrastructure requests Service discoverability Self-service workflows DevSecOps friction Operational transparency Knowledge management Internal developer portal Support & incident response

Disagreement is the product of this session. When two people place the same card in different quadrants, don't resolve it immediately — ask why. That tension is the signal.

Session 7: Where Design Creates Leverage

2:35pm 40 min Dot vote + discussion

Vote Prompt If UX could only invest meaningfully in three areas in the next year, which three would create the most impact for the most people?

3 dots per person (can stack). After voting, score top 5–7 against: size of user pain · users affected · strategic importance · cross-functional appetite · design influence.

Session 8: Write the Opportunity Statements

3:15pm 30 min 5 groups of 3

Statement Format [User] struggle to [do / understand / access] [something] because [root cause or structural condition].

Timing (30 min): Assign each group one of the top-voted opportunity areas. 10 min to draft → each group reads their statement aloud (2 min each = 10 min) → 10 min full-group refinement and read-back. Target: 5 statements leave the room.

Examples

Engineers and teams struggle to understand which infrastructure services they need because documentation is fragmented across teams and tools.
Security requirements are experienced as blockers rather than enablers because expectations surface too late in the workflow.
New engineers require excessive peer support during onboarding because critical knowledge is distributed and difficult to find.

Specificity test: Could someone read this statement and know immediately who to talk to and what to ask? If not, it needs more work.

Closing & Next Steps

3:45pm15 min

Name a single owner for the opportunity portfolio before the room leaves. Confirm when synthesis and photo documentation will be shared back (within 5 business days). End with one word from each person: how they feel leaving the room.

Workshop Outputs

Four Artifacts Leave the Room

Everything else is process. These are the deliverables that matter after the offsite.

1

Current State City

A shared, photographed model of how ISTS works today — annotated with fault lines and evidence levels. The baseline everything else is measured against.

2

Future State City

A shared vision of what a model ISTS organization looks like in 3 years. Focused on experience and relationships, not technology platforms.

3

UX Opportunity Portfolio

Opportunities categorized by horizon and readiness. The input for design team planning after the offsite.

Quick Wins

High readiness + real pain + under 6 months

6-Month

Moderate complexity + cross-functional appetite

Strategic Bets

1–2 year horizon + high business value

Research Needed

Strong assumption + thin evidence — don't design yet

Breakout Groups

User Journey Map & Group Assignments

Groups are organized by user journey stage, not by team ownership. Each group builds from the resident's perspective — not the city planner's. Domains are seeded across groups to ensure cross-functional perspective in every build.

The User Journey — 5 Moments

1 — Get Started
New project, new hire. Access, env setup, certs, tooling, data provisioning. Highest friction for developers who don't know the system yet.

2a — Build: Backend
Daily dev loop: write → CI → security scan → artifact. Also: AI-assisted dev (Claude) — access, trust, integration with internal context.

2b — Build: Mobile
Mac build agents, code signing, device lab, simulator. App Store review = third-party gate. Can't hotfix once shipped.

3 — Change & Deploy
Change request, approval chain, deployment, rollback. Where enterprise friction concentrates. The Thompson Center moment.

4+5 — Run & Learn
Alerts, incidents, MTTR, postmortems. Plus: data access, ML builds, model deployment. City wasn't designed for what it's being asked to do.

Group A

Getting Into the City

Onboarding & Access

"Moving into a new apartment. Keys exist — but some doors take weeks to open."

First-week and new-project experience for both backend and mobile developers. Where do they wait? What do they give up on? What have they learned to work around before anyone else notices?

Infrastructure Services Security ✓ Developer Tools Mobile Dev Tools

Group B

Building in the City

Backend & Platform

"The roads and transit network. Faster and more reliable = less anyone thinks about them."

Backend daily dev loop: CI/CD speed, build reliability, security scan integration, pipeline failures. Also the AI-assisted development moment — is Claude accessible, trusted, and connected to internal context?

Developer Tools Infrastructure Services Observability Security ✓ Claude Product Owner ★

Claude product owner note: Pair with someone who has friction with the current AI tooling experience. The build question is what the experience looks like for a developer using Claude inside ISTS today — including what doesn't work.

Group C

Building in the City

Mobile

"Construction sites on the edge of town. Different rules, different equipment, answer to a landlord the city doesn't control."

Mac build agent availability, Xcode build times, code signing reliability, device lab access, App Store review gate. What does it feel like to be a mobile developer waiting for a build — or waiting for Apple?

Mobile Developer Tools Infrastructure Services Security ✓ Developer Tools (shared)

Present back-to-back with Group B. The contrast — backend ships on merge, mobile ships when Apple approves — is one of the most productive tensions in the room.

Group D

Changing the City

Change & Deploy

"The Thompson Center. Designed for oversight and transparency. Experienced as a maze."

Change request process, approval chains, deployment mechanics, rollback. This group should feel the gap between how fast a confident engineer could ship vs. how long the process actually takes.

Incident / Change Mgmt Infrastructure Services Security ✓ Observability

Group E

When the City Floods

Incidents + Data & AI

"The flood channels and new neighborhoods — infrastructure the city is still figuring out."

Two pain zones that share a theme — the city wasn't designed for what it's being asked to do. Incident response (alert → triage → resolve → learn) and the data/AI user journey (access → build → deploy → monitor).

Observability Incident / Change Mgmt Data Lake AI / ML Ops Security ✓

Composition Matrix

Domain	A — Get Started	B — Build (Backend)	C — Build (Mobile)	D — Change	E — Incidents + Data
Developer Tools	✓	✓	✓ (shared)
Mobile Developer Tools	✓		✓
Infrastructure Services	✓	✓	✓	✓
Incident / Change Mgmt				✓	✓
Data Lake	✓				✓
AI / ML Ops					✓
Observability		✓		✓	✓
Security	✓	✓	✓	✓	✓
Claude Product Owner		★

Security seeds one person per group — every journey stage has a security friction point, and that perspective is most valuable embedded in each group, not isolated in one.

LSP Full Facilitation Script

Word-for-Word Guide — Both Days

Exact challenge questions, storytelling rounds, reflection questions, timings, and landscape instructions. Use these verbatim or adapt to your voice. The city metaphor runs throughout — ISTS as a city its residents live and work in.

Introduction to the Method

9:00am 10 min Full group, before bricks are touched

Say this verbatim "Before we touch any bricks, I want to explain what we're actually doing today — because it probably looks strange from the outside.

LEGO Serious Play is a method for thinking through complex problems by building physical models. Here is the key idea: when you build something with your hands, your brain engages differently than when you talk or write. Ideas that are hard to say out loud become easier to show in a model. And when your model is sitting on the table next to ten other models, the differences in how we each see the same system become visible.

The method has three rules that I'll hold you to throughout both days. One: you build first, then talk. I will give you a prompt — you build silently, then we share. Two: only the person who built the model can say what it means. I will never interpret your model for you, and neither will anyone else. Questions are always directed at the model, not at you. Three: there are no right answers and no wrong models. The tallest tower is not the winner. The most complex build is not the winner. The model that says something true is the one that matters.

We're going to start with a very simple build to get comfortable with the bricks. Then we'll build something real."

Do not skip this. The introduction calibrates the room and prevents the two most common failure modes: people waiting to be told what to build, and people deferring to whoever speaks loudest.

Build 1 — The Tower

9:40am 15 min Individual · warm-up

Setup (1 min)
Distribute bricks. Do not tell them how many to use. Do not show examples.

Build time (2 min)
Silent. Say "start" and step back. Don't answer questions about how to do it — "just build what feels right."

Challenge question — read this exactly "Build a tower. Any tower. Anytime you like, as long as you're happy with it."

Storytelling round — 4 tables in parallel, 60 sec per person

Facilitator prompt to open sharing "When you're ready, go around your table. Each person: tell us about your tower. Not what it looks like — what it means to you. Why did you build it this way?"

Reflection questions (pick 1–2 per table)

"What did you notice about building that surprised you?"
"Did your tower change while you were building it — and if so, why?"
"Is there anything about your tower that you couldn't have said in words before you built it?"

Facilitation note: This build is not about towers. It is about establishing that everyone will share, that sharing is safe, and that the model carries meaning. A few people will build something elaborate. A few will build three bricks stacked. Both are fine — say so.

Build 2 — A Value That Matters to Our Team

9:55am 30 min Individual builds · table share · full room

Deconstruct towers first. Say: "Break down your tower — we're building something new." Wait until everyone has cleared their space.

Challenge question — read this exactly "Build a model that represents a value that is important for our team. What does your team stand for — or what should it stand for? Build it."

Build time: 8 min · silent · write the value on a Post-it and place it next to the model when done.

Storytelling round — within tables first (8 min), then full room

Table-level prompt "Go around your table. Tell us about your model — what does it represent? What does this value look like in practice?"

Full-room prompt (after table shares) "Each table: share one observation about what you heard. What value appeared more than once? What surprised you?"

Reflection questions (full room, pick 2)

"Which value, if we lived it more fully, would change the most about how users and teams experience ISTS?"
"Where do you see these values showing up in the city we're about to build? Where are they missing?"
"Is there a value that appeared in a model today that you've never heard named out loud in a meeting?"

Keep models on the table. They stay as a reference for both days. When the conversation gets abstract later, point back to them: "Which of these values is at stake here?"

Build 3 — Our Current City

2:15pm 90 min Individual → group merge

Challenge question — read this exactly "Build a model representing ISTS today — from the perspective of the people who live and work in this city. The developers. The infrastructure and ops teams. The security partners. The product teams. Everyone who files a ticket and waits. What does this city feel like to them? What works? What gets in the way? What's invisible until it breaks?"

Build time: 20 min · individual · silent. Use a visible timer.

Storytelling round — strict 2-min timebox, visible timer, every person

Opening the share-out — say this "We're going to go around the room. Each person has exactly 2 minutes. Tell us about your model — walk us through what you built. What is the city? Who lives in it? What does your model say about what it's like to use ISTS today? I'll keep time."

After each model — ask one of these "What is the strongest part of this city?" · "Where do people get stuck?" · "What is invisible until it breaks?" · "What did you put in your model that surprised you as you built it?"

Group merge — 20 min

Merge prompt — read this "Now — we have 20 individual cities. We need to build one. Push your models to the center of your table. What belongs together? What connects? This is not about tidying up — it's about finding out what your table collectively believes the city looks like."

Reflection questions (after merge)

"What disappeared in the merge that should have stayed — what got left out of the collective model?"
"What part of this merged city most closely resembles the Pritzker Pavilion — the infrastructure no one sees but everyone depends on?"
"If someone new to ISTS walked through this city for the first time, what would confuse them?"

Reliance Building callback: "Where is the steel frame in this city? What's load-bearing — the thing users and teams stand on without knowing it's there?"

Build 4 — Finding the Fault Lines

3:45pm 75 min 5 groups of 4 · by journey stage

Challenge question — read this exactly "You've built the city as it is. Now: if a major earthquake hit this city tonight, where would it crack first? Build the fault lines. Not the cracks that already show — the ones that are hidden, waiting. Where is the city most fragile?"

Each group finds fault lines in one stage of the user journey. Group A — Getting Started (onboarding, access, env setup) · Group B — Build Loop: Backend & Platform (CI/CD, build pipeline, AI-assisted dev) · Group C — Build Loop: Mobile (Mac build agents, signing, App Store) · Group D — Changing the City (change management, approvals, deployment) · Group E — When the City Floods (incidents, observability, data access, AI/ML). Build time: 20 min.

Storytelling round — 4 groups present to full room, 10 min each

Group presentation prompt "Group [A/B/C/D] — walk us through your fault lines. Point to each one. What is it? How do we know it's real — is this something we know, something we believe, or something we don't know yet?"

Reflection questions (full room, whiteboard clustering)

"Which fault line, if it broke, would affect the most people in the worst way?"
"Which of these did you suspect but have never said out loud in a meeting until today?"
"Which fault lines connect — where does Group A's crack run into Group D's? Where does Group C's release bottleneck show up in Group E's incident data?"

Build 5 — The User & Customer Journey

Day 2 · 9:15am 85 min 5 groups of 4 · one scenario each

Challenge question — read this exactly "You did your pre-work — you talked to a real user or customer before today. Build their journey through ISTS. Not the happy path. The actual path they take: what they need, where they go, what slows them down, what they give up on, what they've learned to work around. Build that journey as a model."

Each group builds one user or customer scenario from their pre-work conversations. Build time: 20 min · group · the whole group contributes.

Storytelling round — 3 groups present, 15 min each

Presentation prompt "Walk us through this user's journey. Point to each part of the model. Where does it go well? Where does it break down? What did your user or customer say that you couldn't have built until you heard it?"

Reflection questions

"Where in this journey does the city fail its residents most?"
"What is the one moment in this journey where a better-designed system would change everything?"
"What did you learn from your pre-work conversation that surprised you — that you wouldn't have assumed?"

Build 6 — The User We Rarely See

Day 2 · 10:40am 60 min Individual → full-circle share-out

Challenge question — read this exactly "Build a model of a user or customer we rarely design for. Someone on the margins of what we imagine our typical user to be — the new hire on their first week, the contractor working across five systems, the senior engineer who has built workarounds for everything and stopped filing tickets. Build who they are and what they need."

Build time: 12 min · individual · silent.

Full-circle share-out — every model gets a voice, 30 min

Share-out instruction "We're going to hear from every person. You have 90 seconds. Tell us: who is this person, what do they need, and what do we not know about them. Start with your model — point to it as you speak."

LSP Rule 3 — 100% participation: Every model gets a voice. Do not select or highlight only 3–4 models. Every person presents their own model — the builder always interprets their own build.

Reflection questions (full room)

"Who appeared in multiple models today — a user who keeps showing up that we don't design for?"
"What did you see in someone else's model that you couldn't have built yourself?"
"If this person — the one in the model that got the most sticky notes — used ISTS every day, what would we have to change first?"

Build 7 — The Future City

Day 2 · 11:40am 75 min 3 groups of 5

Challenge question — read this exactly "Build the city as it could be — three years from now. Not a wish list. Not a roadmap. A city that works for the people who live in it. What does it feel like to be a user in this city? What has changed? What invisible infrastructure now just works? Build that city."

Build time: 20 min · group. Each group focuses on one domain: infrastructure & reliability · developer experience & tooling · onboarding & knowledge.

Storytelling round — 3 groups present, 12 min each

Presentation prompt "Walk us through your future city. What is different? What did you have to let go of from the current model to build this one? What does a user experience here that they don't experience today?"

Reflection questions

"What part of this future city is already possible — and what is holding it back?"
"Which building from the Chicago tour this morning looks most like what you built here?"
"What would you have to stop doing to build this city?"

The Landscape — Collective Story

Day 2 · 1:30pm 30 min Full group · models stay whole

LSP Rule 7: Super stories and landscape models incorporate every participant's contribution. Models remain whole — they do not get broken apart or merged. Each model keeps its integrity inside the collective story.

Landscape prompt — read this exactly "We're going to build one city out of all our individual future cities. Each group: bring your model to the center. Do not dismantle anything. Your model stays whole.

Now — decide together where your city belongs in relation to the others. What is adjacent? What is upstream or downstream? What supports what? You're negotiating the map — take 10 minutes to place everything."

Shared model instructions (Advanced LSP)

Step 1 — Place. Each group carries their model to the center table and places it in relation to the others. Talk to each other. Negotiate position, proximity, orientation. There is no right answer — the negotiation is the point.

Step 2 — Connect. Using new bricks (not from existing models), add connections between models that represent real relationships: shared dependencies, handoffs, points of friction, points of support. These are new bricks — nothing is removed from any model.

Step 3 — Walk. Everyone takes three steps clockwise to see the landscape from a different angle. Ask: "Does anything look different from here?"

Step 4 — Name. Ask the room: "What is this city called? Give it a name that captures both where we are and where we're going."

Reflection questions (landscape)

"Where in this landscape is the Pritzker Pavilion — the thing that makes everything else possible but nobody sees?"
"Where is the fault line we found yesterday — does it still exist in this future city, or did we design past it?"
"What would a user say if they could walk through this model — what would surprise them most?"

Facilitator close for the landscape "We're not going to dismantle this. Take photos — every model stays whole. What we built here is the shared picture we've been working toward. Now we turn it into decisions."

LSP Rules Review — Compliance Check

This plan reviewed against the 9 LSP rules. Flags and resolutions below.

Rule	Status	Note
1 — Warm-up first	✓ Compliant	Tower build precedes all challenge questions
2 — Build → story → reflection	✓ Compliant	Every build above follows this exact sequence
3 — 100% participation	✓ Compliant	All scripts say "every person shares"; no volunteers-only language anywhere
4 — Only the builder interprets	✓ Compliant	All reflection prompts are directed at "your model" and asked to the builder
5 — No right/wrong models	✓ Compliant	Introduction explicitly names this; no competitive framing anywhere
6 — Individual before shared	✓ Compliant	Builds 1–3 are individual; group builds (4–7) come after individual models are established
7 — Landscape models stay whole	✓ Compliant	Landscape instructions explicitly state "models stay whole"; new bricks added for connections only
8 — Realistic timings	⚠ Watch	With ~20 people, 2-min timeboxes are tight but workable. If the room runs slow on Build 3 share-outs, cut reflection questions — never cut individual sharing time. Landscape at 30 min may need 40 if the room engages deeply with placement.
9 — Don't fill gaps with generic activities	✓ Compliant	Every session is purpose-designed for this specific challenge. No generic icebreakers or team-building substitutes.

Facilitation Guide

Running the Room

For the workshop lead and any co-facilitators. Read before the offsite. Bring it with you.

The Facilitator's Core Job

Your job is not to teach, present, or guide people to the right answer. Your job is to:

Protect the process — keep people building and storytelling, not presenting and debating

Surface what's real — ask questions that expose genuine insight, not rehearsed positions

Hold the evidence bar — keep pressing on whether things are known or assumed

Keep the room safe — create conditions where someone can say "I don't actually know our users" without career risk

LSP Method — Three Things to Know

1. Build first, talk second
Every exercise: prompt → quiet build → share-out. Never skip the build. If someone starts talking instead: "Before you tell us — can you show us?"

2. Respond to models, not people
You are asking about the object, not evaluating the person. Always: "Tell us about your model" — never "What did you build?"

3. Silence is building time
You'll feel the urge to fill silence. Don't. If someone is stuck: "Start with one piece that feels right and see where it goes." Then walk away.

Phrases to use vs. avoid

Use"Tell us about your model."

Avoid"What did you build?" (too closed)

Use"What does this piece represent?"

Avoid"That's interesting." (evaluative)

Use"What happens if we remove this?"

Avoid"I like that." (evaluative)

Use"Who else is in this story?"

Avoid"Right." / "Exactly." (signals correct answer)

Pre-Tour Briefing — Success: people leave curious, not briefed. Avoid overloading with LSP theory. Just frame it as fieldwork and let the city do the work.

LEGO Warm-Up — The room should be laughing by the end of the duck. Senior leaders sometimes resist — say: "The duck is non-negotiable. It's 3 minutes and it removes the part of your brain that thinks building has to be serious." The third exercise (biggest frustration) is where real content starts. Listen carefully.

Session 1: Current City — Failure: everyone builds an org chart. Prevent it by emphasizing "from the perspective of the people we serve." If you see boxes and arrows: "Where are the people we serve in this model? What are they doing right now?" The group merge is where politics surface — if one person's model dominates, redirect: "Before we add that — what does [quieter person]'s model contribute here?"

Session 2: Fault Lines — The earthquake metaphor gives people permission to criticize systems they helped build. Apply the evidence test to every fault line as it surfaces. If most things land in "we believe" and "we don't know" — that is a finding, and a useful one for positioning UX.

Session 3: User & Customer Journey — Watch for models that are too smooth. If the journey is a clean flow with no friction: "Where does the user not know what to do next? Show me that moment." Handoffs are usually the most important finding.

Session 4: User We Rarely See — Success: at least 2–3 models generate genuine uncertainty. Watch for the confident build — probe it: "When did you last talk to someone like this? What did they tell you?" The goal is not to embarrass anyone. It is to show where UX research closes the gap.

Session 5: Future City — Most common failure: people build technology. Redirect: "What does a user feel when they use this? Can you add that to your model?" If people say the future is too ambitious: "It doesn't have to be fully built in three years — but the shape of it should be visible."

Session 6: Opportunity Landscape — Disagreement is the product of this session. Watch for everything clustering toward "high readiness" — apply pressure: "Is this actually ready to act on, or do we wish it were?"

Session 7: Leverage — If voting is fragmented (everyone votes for their own domain): "Vote for the problem that affects the most people in the worst way — not the problem in your domain."

Session 8: Opportunity Statements — Push for specificity. If a statement is too broad, ask: "Which user or team? What specifically can't they do? What specifically causes that?" Read statements aloud before the session ends — hearing reveals vagueness that reading doesn't.

The single most important facilitation tool in this workshop. Use it consistently throughout both days — every time someone makes a claim about user behavior, user problems, or organizational challenges.

How to introduce it (Day 1, Fault Lines session) "Every time we identify a problem or insight, we're going to ask: how do we know this is true? We have three categories: we know — evidence, data, or direct research. We believe — strong assumption, no formal evidence. We don't know — a genuine gap. None of these is wrong. 'We don't know' just tells us where we need to do more work."

Sample language

"How do we know this is true?"
"Is that a 'we know' or a 'we believe'?"
"What would we need to see to move this from 'we believe' to 'we know'?"
"The fact that we don't know that — is that a problem?"

At the end of Day 2: The "we don't know" bucket is your research agenda. Name it explicitly: "These are not failures. These are the places where UX research can change what ISTS knows about its users before it builds something."

Facilitation Guide

Managing Group Dynamics

The Dominant Voice

One or two people — usually senior leaders — will tend to speak for everyone. Don't ask them to yield. Redirect.

"What does your model say about that?" — directed at someone who hasn't spoken. Physical positioning: stand near the person you want to hear from next.

The Quiet Expert

The person with the most actual user knowledge often says the least. Individual contributor in a room of managers.

"Your model had something the others didn't — can you walk us through this piece again?" Watch for models that are more detailed and grounded than others.

The Skeptic

Someone will think this is silly. Don't argue. Don't convert. Use it.

"Can you build that for me? What does your skepticism look like as a model?" Skeptics almost always engage once their hands are moving.

The Solution-Jumper

"We should just build a unified portal." Usually technically oriented. Skipping the problem to get to the answer.

"Before we get to solutions — can you build me the problem? What does the developer experience look like right now, before the portal exists?"

The Manager Who Speaks for the Team

"Our users all say that…" / "Developers don't really care about…"

Apply the evidence test consistently: "How do we know that? Is this something we have data on, or a strong belief?" Do this without singling anyone out — the room starts applying it to themselves.

The Person Who Won't Share

"Mine is pretty simple / basically the same as what X said."

"Every model gets a voice. What did you build?" Then wait. Do not fill the silence.

Facilitation Guide

Common Failure Modes & Recoveries

What happens	Why it happens	Recovery
People describe what they'll build instead of building	Verbal comfort zone; executives especially	"Before you tell us — can you show us?"
Share-outs become slide presentations	Room shifts back into meeting mode	"Tell us about your model" — return focus to the object
Shared city gets dominated by one domain	Power dynamics surface in the merge	Physically reposition less-represented pieces; ask what's missing
Nobody votes differently from the senior leader	Political safety	Anonymous dot voting — put dots on table, everyone places simultaneously
Opportunity statements come out too vague	People revert to strategy-speak	"Who specifically? What specifically can't they do? What specifically causes that?"
Energy crashes after Day 2 lunch	Happens in every workshop	Keep Opportunity Landscape active and physical — people moving, placing cards, disagreeing
Stakeholder derails Future City with constraints	Solution-mode resurfacing	"In this city, we're not worried about constraints yet. What would we build if we knew it was possible?"
Workshop ends without clear next steps	Nobody owns the output	Name a single owner before the room leaves. The output dies without one.

Before you walk in the room: Know who in the group knows their users well, who may be uncomfortable with the method, who is the most influential voice, and whether there are unresolved political tensions that could surface during the merge activities. You cannot control group dynamics — but knowing them going in means you are not surprised by them.

Pre-Work & Planning

Everything Before the Room Opens

6–8 weeks before

Logistics & Materials

Book architecture tour — call CAC at 111 E. Wacker Dr. If group >20, book a private tour
Confirm 10:00am start time and accessibility needs
Order LEGO: LSP Identity & Landscape Kit (part #2000414) — 1 per person minimum. Not in retail stores — order from LEGO Education. 6-week lead time.
Book workshop venue for both days (moveable tables, 2 whiteboards, wall space, projector)
Confirm facilitator and co-facilitator

4 weeks before

Communications

Send stakeholder invitation email (see Email Templates)
Send separate design team briefing email
Send virtual attendee email with Miro link and metaphor context (see Email Templates → Virtual Attendee)
Confirm catering for both days

2 weeks before

Pre-Work

Send participant pre-work email to everyone
Confirm final headcount for architecture tour
Order remaining materials: sticky notes, markers, dot stickers, index cards, masking tape

1 week before

Facilitator Prep

Hold 60–90 min walkthrough with co-facilitator — say each prompt out loud
Agree on evidence framework language and consistent application
Identify 2–3 participants who might resist or dominate; plan responses
Print all materials (observation cards, metaphor reference cards, session prompts, evidence poster)
Plan opportunity mapping wall — where, what cards, when to reveal
Brief tech host on their role — test video call, camera, and room audio together
Confirm virtual attendees have Miro access and can edit the board

Day before

Room Setup

Tables in groups of 4–5 (not one large meeting table)
LEGO sets at each seat + extra bricks in center
Sticky notes and markers at every seat
Metaphor reference cards at each seat
Observation cards at the front (distributed at 9:30am, not in advance)
Evidence framework poster posted on wall
Session prompts set aside — post as each session begins
Opportunity mapping wall prepared but blank until Day 2 afternoon
Send day-before logistics email to all participants

Email Templates

Communications

Four emails — ready to copy, customize, and send.

Subject: [ISTS Offsite] Designing the City Behind the City — [Dates]

To: Business stakeholders

Hi [Name],

I'm writing to invite you to a two-day offsite focused on one question: how do we support ISTS users who depend on our services and tools so they can do their best work?

This isn't a design workshop in the traditional sense. We're not going to spend two days looking at wireframes or sitting through presentations. Instead, we're going to use a method called LEGO Serious Play — a structured, research-backed approach that uses physical building and storytelling to surface insights that rarely come up in meeting rooms.

We're combining it with something a little unusual: a guided architecture tour of Chicago's iconic buildings on the morning of Day 1.

Here's what we're trying to accomplish together:

- Build a shared picture of how ISTS delivers services and what that experience is really like for the teams and customers who depend on us
- Surface the biggest opportunities for meaningful improvement — not incremental fixes, but the areas where a more intentional, user-centered approach could change things fundamentally
- Leave with a clear portfolio of problems worth pursuing, prioritized by user impact and organizational readiness

Why Chicago architecture?

Chicago is one of the best places in the world to study the challenge we face: how do you build systems that serve people without making the infrastructure visible? How do old and new coexist? How do you design something that a first-time user can navigate without a manual?

We're going to walk through buildings from the 1890s through today and use what we see as a lens for thinking about our own systems. The parallel is closer than it sounds.

What I need from you before we meet:

I'll send a short pre-work assignment about two weeks before the offsite. It will take about 30 minutes. It's designed to help you walk in ready to contribute something specific — not to prepare a presentation.

Details:
- Date: [Date]
- Day 1: Sessions begin at 1:00pm at Union Station Conference Room, 525 W. Monroe St., 5th Floor. Water Taxi departs at 5:30pm.
- Day 2: 606 Conference Room, 525 W. Monroe St., 5th Floor — ends at 4:00pm CT
- What to wear: Comfortable shoes for Day 1 (we'll be walking for about 2 hours)
- What to bring: Yourself and whatever you actually know about the people who rely on ISTS every day

Please confirm your attendance by [date].

[Your name]

Subject: Offsite briefing — what we're trying to accomplish and how you can help

To: Design team only

Hi team,

Before the offsite, I want to give you more context so you can play an active role rather than just participating.

The real goals of this workshop:

The explicit goal is to identify where UX design can have the most impact across ISTS. But underneath that, we're trying to do something harder: build the conditions for a longer-term partnership between design and the business. That means:

1. Helping stakeholders experience design thinking by doing it, not by hearing about it
2. Understanding how much these stakeholders actually know about their users — and where the gaps are
3. Getting everyone into the same problem space before anyone starts proposing solutions
4. Leaving with a shared language for talking about user problems and design opportunities

Your role during the workshop:

You are participating as peers alongside the stakeholders. Your design instincts are valuable, but use them as questions, not corrections.

When a stakeholder describes a user problem, your most powerful move is not "here's how we'd solve that" — it's "how do we know that's true?" and "what would we need to understand before we could help?"

A few specific things to watch for:
- Who in the room knows their users genuinely well vs. who is speaking from assumption?
- Which problems appear in multiple models independently (this signals something real)?
- What vocabulary does each stakeholder use for users? Do they use names, roles, specific scenarios — or do they say "the business" and "our customers"?
- What fault lines exist between teams that nobody is naming directly?

After the workshop:

I'll synthesize the outputs within a week. I'll need your help connecting what we heard to existing research or identifying where we need to start new research. Come prepared to connect dots.

[Your name]

Subject: [ISTS Offsite] Pre-work — 30 minutes, before [date]

To: Everyone — stakeholders and design team

Hi [Name],

We're two weeks out from the offsite. Before you arrive, I'd like you to do one thing. It should take about 30 minutes and it will make your time there significantly more useful.

Your pre-work assignment:

Between now and [date], have one conversation with someone who uses or depends on ISTS services. This could be a developer, a platform engineer, a product owner, a security partner, or a support engineer — anyone whose work involves interacting with the systems, tools, or processes your team provides.

Ask them one question:

"What is the most frustrating or confusing part of working with [the specific thing your team provides]?"

Then listen. Do not explain, defend, or fix. Just write down what they say — ideally in their words, not your interpretation.

Bring those notes to the offsite.

If you genuinely cannot have that conversation before we meet, come prepared to answer this question yourself: What do I know — with evidence — about the people who depend on ISTS, and what am I assuming?

That's it. No slides, no preparation, no reading list.

One more thing:

Day 1 sessions begin at 1:00pm. Water Taxi departs at 5:30pm for dinner in Chinatown.

See you [date].

[Your name]

The pre-work is intentionally light. The goal is not to brief people — it is to activate curiosity and give them something specific to contribute. People who walk in with a real quote from a real user change the quality of the room.

Subject: [ISTS Offsite] Joining virtually — what you need to know

To: Virtual attendees only · Send 1 week before Day 1

Hi [Name],

You're joining the ISTS offsite virtually, and I want to make sure your experience is as close as possible to being in the room.

Here's everything you need to know before we start.

What you'll be doing:

The workshop uses LEGO Serious Play — a structured method where you build physical models and tell stories about them. Since you'll be remote, we've set up a Miro board version so you can participate in every session. You'll build using a digital brick library, share your screen during share-outs, and work in the same shared frames as in-room participants.

Your Miro board: [LINK]
Please open this before Day 1 and verify that you have edit access. If you get a view-only prompt, reply to this email so we can fix it before the session.

What to do before Day 1:

1. Complete the pre-work assignment (see separate email) — same as everyone else.

2. Review the Chicago metaphor context below. In-room participants will walk through Chicago architecture on Day 1 morning as a metaphor for ISTS systems. You'll skip the tour, but you need to know the metaphor going in.

   Key parallel: The Pritzker Pavilion in Millennium Park has a distributed speaker grid running under 36 acres of lawn. No one who sits on the lawn knows it's there — but without it, no one hears the music. That is what ISTS provides: infrastructure that disappears when it works and becomes a crisis when it doesn't.

3. Do the observation exercise independently: read the prompts below and write 3–5 answers before Day 1.
   - What makes a city usable for the people who live and work in it?
   - What infrastructure do people rely on but never think about?
   - Where does old and new coexist — and where does that create friction?
   - What would a first-time visitor find confusing or invisible?

When you join:

Day 1: Join at 12:30pm CT. The morning is an in-person architecture tour. I'll share photos from the tour in Miro at lunch so you have the same reference points.

Day 2: Join at 9:00am CT. You'll be in every session.

Video call link: [LINK]

A few practical notes:

- Keep your video on during share-outs when you're presenting — it helps the room see you and makes the conversation feel less one-directional.
- When you want to speak, use the raise-hand function or type in chat — someone in the room is designated to watch for virtual hands and flag them to the facilitator.
- During build phases, your audio can be muted. Unmute when sharing.
- You'll be assigned to working groups the same as in-room participants. Your group will coordinate with you directly.

See you [date].

[Your name]

Send this in addition to the standard pre-work email — virtual attendees need both. The Miro link and metaphor context here replace the in-person tour briefing.

Subject: Tomorrow — logistics for Day 1

To: Everyone · Send evening before Day 1

Hi all,

Quick logistics for tomorrow:

Morning:
- Arrive at [location] by 9:00am sharp — we walk at 9:30am
- We walk to the Chicago Architecture Center (111 E. Wacker Dr.) as a group
- We walk at 9:30am — late arrivals cannot join mid-tour
- Wear comfortable shoes; the route is flat and about 2 miles round trip
- [Add weather note if relevant: bring a layer / umbrella]

Afternoon:
- We return to [workshop venue] for lunch at approximately 12:30pm
- Workshop sessions run until 5:30pm
- Bring any notes from your pre-work conversation

Evening (everyone):
- Water taxi departs at 5:45pm — plan to join, this is part of the offsite
- Dinner in Chinatown at 6:30pm — reservation is for the full group

Day 2:
- Meet at [workshop venue], [address]
- Start time: 9:00am
- End time: approximately 5:30pm
- Lunch is provided

If you have questions or can't make it, contact [name] at [contact].

See you at 9:00.

[Your name]

Checklist

Materials

🧱 LEGO

LSP Identity & Landscape Kit (#2000414) — 1 per person (preferred)
Or Window Exploration Bag (#2000409) + supplement with standard sets
Extra base plates for city-building sessions
Extra loose bricks in center of each table

🖨️ Print

Observation cards — 1 per person, double-sided
Chicago metaphor reference cards — 1 per person, stays on table both days
Session prompts — large format, posted as each session begins
Evidence framework poster — large enough to read across the room

🏠 Room

Large moveable tables (groups of 4–5, not fixed boardroom)
2 whiteboards or 1 whiteboard + flip chart
Wall space for opportunity mapping (Day 2)
Projector or screen for Day 2 morning (Day 1 photos)
Catering: Day 1 lunch, Day 2 lunch + coffee/snacks

✏️ Supplies

Sticky notes — at least 3 colors, multiple pads
Markers — thick enough to read from 3 feet
Dot stickers — 3 colors (vote dots, red = don't know, green = know)
Index cards for opportunity mapping wall
Masking tape for 2×2 axes
Camera or phone for documentation

💻 Hybrid Tech

Miro board created, all sessions framed — share link with virtual attendees 3 days before
Wide-angle camera on tripod covering LEGO tables — tested day before
USB conference speaker/mic (Jabra, Owl, or equivalent) — audio tested from far corner of room
External room speaker so virtual audio reaches full group
Video call link confirmed and tested — separate from Miro
Tech host assigned (not the facilitator) — monitors virtual attendees throughout
Phone or second camera designated for photographing physical builds and uploading to Miro

Print Materials

Participant Cards

Print one of each per participant. The observation card is distributed at 9:00am on Day 1. The reference card stays on the table for both days.

Observation Card — Tour

Front / Back · Half-sheet

Chicago Icons: Connecting Past and Present
Your fieldwork prompts — one observation per sticky note, collect at least 5

What makes this city usable for the people who live and work in it?
What infrastructure do people rely on but never think about?
Where does old and new coexist well — and where does it create friction?
What would a first-time visitor find confusing, overwhelming, or invisible?

What you're looking at and why

Building	ISTS parallel
Reliance Building (1895)	Invisible foundational infrastructure
City Hall (1911)	Governance and approval processes
Thompson Center (1985)	Designed openness vs. actual usability
Marina City (1964)	Unified platform ideal — everything in one place
Daley Plaza	User-facing interfaces that require interpretation
Pritzker Pavilion	Hidden services that enable experience
LondonHouse	Legacy system modernization

Chicago Metaphor Reference Card

Full-sheet · Keep on table both days

Designing the City Behind the City

City element	ISTS equivalent
Historic buildings	Legacy systems and processes
Infrastructure	Invisible services that support everything
New architecture	Innovation and modernization
City residents	Developers and internal users
Urban planners	ISTS leaders
Architects & designers	UX and product teams
Utilities & transportation	Infrastructure platforms, DevSecOps, tooling

Evidence framework — ask this about every insight

Label	What it means
We know	Evidence exists — data, research, direct feedback
We believe	Strong assumption — not yet validated
We don't know	Genuine gap — research needed before acting

Designing the CityBehind the City

What We're Here to Do

Five Goals

Facilitator's North Star

The Metaphor: Chicago Architecture

Running with Virtual Attendees

What Stays the Same

What Changes

Virtual LEGO — Miro Board

Before the workshop

During sessions

Room A/V Requirements

Architecture Tour — Virtual Attendees

Send before Day 1

During the tour and at lunch

Session-by-Session Hybrid Notes

Day 1 — Discovery

Pre-Tour Briefing

Observation card prompts

Chicago Icons: Connecting Past and Present

Lunch + Informal Debrief

LEGO Warm-Up

Value directions for this group

Super Story Extension (+15 min — plan for this)

Session 1: Build Our Current City

Discussion questions

Session 2: Finding the Fault Lines

Capture on whiteboard — cluster into

Session 3: Day 1 Synthesis + Reflection

10 min — Reflection round

Evening — Water Taxi to Chinatown

Dinner — Chinatown

Day 2 — Direction

Opening & Day 1 Recap

Session 3: The User and Customer Journey

One scenario per group — drawn from pre-work conversations

Discussion questions (full group, after all 5 present)

Session 4: The User We Rarely See

Session 5: Build the Future City

Discussion questions

Lunch

Session 6: Opportunity Landscape

Seed opportunity areas from Days 1–2

Session 7: Where Design Creates Leverage

Session 8: Write the Opportunity Statements

Examples

Closing & Next Steps

Four Artifacts Leave the Room

Current State City

Future State City

Top User Problems

UX Opportunity Portfolio

User Journey Map & Group Assignments

The User Journey — 5 Moments

Getting Into the City

Building in the City

Building in the City

Changing the City

When the City Floods

Composition Matrix

Word-for-Word Guide — Both Days

Introduction to the Method

Build 1 — The Tower

Storytelling round — 4 tables in parallel, 60 sec per person

Reflection questions (pick 1–2 per table)

Build 2 — A Value That Matters to Our Team

Storytelling round — within tables first (8 min), then full room

Reflection questions (full room, pick 2)

Build 3 — Our Current City

Storytelling round — strict 2-min timebox, visible timer, every person

Group merge — 20 min

Reflection questions (after merge)

Build 4 — Finding the Fault Lines

Storytelling round — 4 groups present to full room, 10 min each

Reflection questions (full room, whiteboard clustering)

Build 5 — The User & Customer Journey

Storytelling round — 3 groups present, 15 min each

Reflection questions

Build 6 — The User We Rarely See

Full-circle share-out — every model gets a voice, 30 min

Designing the City
Behind the City