By Allie Ofisher and Sophia V Prater, originally posted on Linkedin

A traditional Design Sprint is built for divergence and speed. You’re generating new ideas, picking one to prototype, and testing it with users…all in a week. Which is a great fit for a contained feature or a fresh concept where the question is "which direction do we go?"

But what about when you’re building software that has complex requirements and tangled user permissions? Prototypes of screens easily glosses over complexity, leaving necessary requirements in individual team members' heads, and important disagreements between siloed teams go un-discussed.

A map of your system though, whose purpose is to visualize the underlying structure without screens, gives space for cross-team discussions, where you can settle disagreements once and document decisions with ease 😌.

That's the whole reason complex products need a different kind of Sprint.

What is an OOUX System Design Sprint?

The philosophy behind a System Design Sprint is Object-Oriented UX, or OOUX for short. OOUX is a way of designing a system around its objects—the real, nameable things people come to your product for, like an Order, a Vehicle, a Patient.

The process behind OOUX is ORCA. It asks four questions of your system:

• What are the Objects?

• What are the Relationships between those objects?

• What are the Calls-to-action, the things people can do?

• What are the Attributes, the details that describe each object?

Answer them and the fog starts to clear. When you run through ORCA with your team over a week, you've got a System Design Sprint. And yeah, we typically spend a FULL DAY on each of these questions. Monday is spent just getting to the right objects and creating shared definitions. More on this later.

By the end, a shared language has formed between a team and everyone can see how the pieces connect, without screens or prototypes.

What teams get out of it

The real power of this Sprint is the alignment it builds. You’re creating a literal shared language across groups that don't usually work side by side. Tribal knowledge comes out of people's heads and into artifacts the group co-creates. The conversation shifts from screens and features to how customers think about the domain and the system.

Here’s what teams say after using the ORCA Process for collaboration:

"Now I have a clear and organized roadmap, I have the best alignment with my developers I've ever had and the level of clarity has been game changing."

"OOUX brought my team together. It was the missing ingredient in finding common language to talk about complex concepts."

"OOUX feels like having a GPS that constantly shows your location on the map. You still get to choose where you want to go… but you're never left wondering how everything fits together."

Who's in the room

The single biggest driver of a good System Design Sprint is the right people in the room. You want decision-makers and people who understand the system well enough to make real calls, rather than observers taking notes.

That means bringing together:

• Product Owners who can say “That’s a priority for Q1”.

• Lead Technical Architects who understand the constraints and can say, “That will be difficult because…”.

• Subject-Matter Experts who hear the truth from your users—like your best salespeople, your researchers, and the customer-service reps—who know exactly what customers complain about and wish the product could do.

• Your systems-thinking designers who are ready to go deeper than screen-level UI

The real momentum behind the Sprint is the right people, working together, having real conversations, and building the map together.

(Psst: We’ve found that smaller groups under 12 are best. Any more and even the most skilled facilitator will struggle keeping the conversation focused.)

Is a Sprint right for your product?

A System Design Sprint earns its place when the domain is so wildly complex that handing it over to a siloed designer would unfairly result in designs with holes and painful rework. The information has to be pulled out of the people who know the system, the business, and the users best.

Most teams turn to a Sprint when encountering one of these three situations:

• Unifying several products into one after growth or an acquisition.

• Building something new, and you keep stalling.

• You've already built it, and now it's slow and expensive to change, which you’re paying for in every release.

AI comes in as one of the top reasons it feels urgent for teams to do a Sprint. A reliable AI feature has to stand on a clean system model. Build it on a messy one, and you just make the mess faster.

What the Sprint week looks like

Picture a room with every surface covered in sticky notes, color-coded by a system your team picks up in the first hour. Your sharpest people are on their feet, talking through the hard requirements together. By the end, a product that felt like fog now has a shared shape.

The week walks through ORCA one pillar at a time. Each day runs from about 9am to 4:30pm, with breaks and a proper lunch, so people can keep an eye on their usual work.

Monday = Objects

The team names the core things the product is built from and agrees on them, narrowing a big pile of candidates down to the ten or twelve that matter.

Your objects are the key building blocks that have value to the business and your users. They deserve clear terminology and shared understanding among the team.

Tuesday = Relationships

The team maps how those objects connect to one another, written as plain sentences anyone in the company could read. This helps further define the objects as elements in a system and plots out a plan for intuitive navigation. Win. Win.

Wednesday = Roles and actions

The team pins down who uses the system, and exactly what each role can do to each object.

This helps the group untangle sticky permissions questions as well as holistically visualize the functionality of the system. Another win-win.

Thursday = Attributes

The team fills in the details that describe each object, flagging what's new or no longer needed, and the full map of your system comes together.

Now, everyone in the room has a detailed picture of the structure of all the valuable concepts in your system. This is system design at its best — collaborative, rigorous, and devoid of any handwaving.

Friday =  Wrap-up

Typically a half-day to organize the post-it notes and document everything into a shared database. It’s good to schedule this day to reflect, recap, plan next steps, and of course celebrate!

What you'll walk away with

The key deliverable from the Sprint is the Object map. It’s the X-ray vision into your digital product's structure, allowing designers, developers, and product to work simultaneously from the same blueprint before wireframes even exist.

What a Sprint doesn't do

A System Design Sprint isn't detailed visual design, a design system, software development, user research, content strategy, or a roadmap. We build the conceptual foundation that makes all of those flow better. This process helps you get a clearer picture of where you could go, that future state “North Star” for a product’s design.

Could you run this yourself?

A team with strong internal OOUX expertise can run a Sprint on their own, especially if someone has gone deep on the method through the OOUX Masterclass or Certification, they can hold the room and walk everyone through the process of co-creating the system map. Plenty of teams do exactly that, but not every team has that person yet, or they do have one or even several trained OOUXers on the team but they need an outside guide with fresh eyes.

That's where Rewired comes in.

Your System Design Sprint experts

Hi! We're Allie Ofisher and Sophia V Prater. Sophia coined the term 'OOUX' back in 2015 and has been teaching it ever since. Allie came into Sophia's OOUX Certification program early on and the two just clicked. Together, we've OOUXed startups, hospitals, non-profits, forklift software, and even a religion (no kidding). When you bring us in, you get expert, experienced OOUX facilitators in the room with your team. And we're a ton of fun, too.

We relish prepping the hell out of a Sprint, spending about three weeks prior to the actual workshop series foraging your material into a working database, tagging candidate objects, drafting definitions, and capturing relationships and open questions. We become domain experts fast so we can hit the ground running on Object Monday.

What we need from you:

• The right people, in-person, for about 30 hours in a week.

• Access to your source material for prep (the software, past research, requirements docs, anything that helps us learn your domain before we arrive).

• A working space with plenty of wall and whiteboard room, so people are up and moving instead of stuck around one table.

Book a System Design Sprint with Rewired

If your product's future has felt like fog for a while, a System Design Sprint is a good place to start. We'll look at the slice of your product that's giving you the most trouble, talk through where it's stuck, and tell you plainly whether a Sprint is the right move yet. You'll leave with a clearer read on your own system either way, whether or not we ever end up working together.

Book an intro call with Sophia →

Learn more about Rewired →