Loops and Cycles, so far, is exploring concepts to help make sense of the activities that drive design in an organizational context. “Design” in this case is taken in the broadest sense — all of the activities that bring ideas to life, which in our case is most likely ‘shipped as a production offering.’

Sequence and Scale

Two key ideas we've been exploring are the sequence of activities and the different levels of scale they occur at, notably in:

• Process vs. Sequence [LC02], invoking Alexander’s view of sequence
• Three Levels of Scale [LC04], pulling on the original “Loops and Cycles” piece
• Sequence: Concierge MVP [LC08], trying to show concrete steps
• Strategic Levels of Scale [LC21], evolving from 3 to 5 levels
• Sequence and Scale [LC23], blending the two concepts to draw a unified picture

With one exception, we’ve been discussing what happens in sequence and what happens at different levels of scale in generic and abstract terms. LC08 went in the right direction, trying to show specific activities in a rough sequence.

Getting to Concrete Steps

This is the key to clarity: the actual units of effort we take on, and how we choose what to do at any point in time. Ideas like sequence and scale are frames — productive ones, I think — that help us consider and identify what we ought to do next. We’ll refer to that concrete unit of work, what we do next, as a step.

If good design is an adaptive, “step-by-step” process, then what concrete kinds of activities, at each level, might make a step? Here are some candidate examples, organized over our five levels of scale from LC21 and LC23. Each is meant to be a concrete and observable activity, that we will see recur and repeat over time, more frequently up top, less frequently as we go down the list.

Example steps at Initiative scale:

• Sketch a user flow
• Write the document (PRD, one-pager, project brief)
• Interview a user or customer
• Update a shared assumptions map
• Send a slack message to request information
• Wire up a prototype in Figma
• Write a set of tests for new functionality
• QA test functionality across multiple mobile platforms
• Have an individual conversation about an idea
• Draw a conceptual model of the system
• Prepare materials for the next meeting
• Record a bug or an issue
• Backchannel an idea with an influential leader
• Create a dashboard for a new area of attention

Example steps at Team scale:

• Bound and define an upcoming initiative
• Review changes to the assumption/risks/confidence index
• Prioritize the next team initiatives to take on
• Commit to specific efforts to adapt the offering
• Kick off a projects cross-functional stakeholders
• Run a shaping workshop for upcoming work
• Consolidate customer research and analytics insights
• Triage incoming requests for priority
• Identify risks and assumptions for an upcoming concept
• Create on an update for an all-hands meeting
• Run a retrospective of prior efforts
• Communicate project status outward
• Present the current initiative at a product review meeting

Example steps at Offering scale:

• Model customer needs and context for a product area
• Prioritize customer needs and problems
• Define goals and focus areas for the coming quarter
• Launch an experiment or A/B test
• Run a beta program for experimental feature
• Maintain and scale high-traffic infrastructure
• Launch a new capability to existing market
• Launch existing capability to new market
• Resolve unexpected failures, issues, or incidents
• Incorporate new components into design system
• Operate recurring gate reviews

Example steps at Organization scale:

• Inventory existing capability and performance
• Orchestrate recurring product planning cycles
• Operate all-hands meetings
• Communicate urgent news and information
• Set up recurring gatherings and retreats
• Create an annual strategic plan

Example steps at Ecosystem scale:

• Identify external technological trends
• Map organizational and competitive evolution
• Prioritize areas of strategic opportunity
• Commit to strategic gameplay

This isn't exhaustive, merely illustrative. Each item represents a specific activity that is a potential step in the ever-evolving web of organizational activity.

These steps define sequence. Each step is something we can begin and something with an end. We can scope a step in advance of taking it, not always knowing what will result, but understanding what kind of thing will unfold. We can anticipate which signals to look for, and many of the viable options for what we’ll do next when the step is complete. This is true for steps at every level of scale.

Steps also define the cadence at each level of scale. There is no “Initiative level of scale” independent of the set of activities that constitute it. The interval between each step — how quickly one move can lead to another at the same level, or how quickly we can iterate on the same step — is what ultimately defines the cadence at each level. That same level will move at different speeds between different organizations.

Each step is necessarily composed of steps at every level below it, all the way down to Initiative. The myth of the strategy-execution divide is a willful ignorance of that cascade. There is no step without individual, fast-cycle actions that compose their containing effort.

Concrete Steps Constitute Good Work

Working together well and driving healthy design means we take the right next step at the right time. I'm writing this update because that's much easier said than done.

How can we get a hold of that right next step, no matter where we are in our work?

Seeing the concrete activities that constitute steps, plus understanding them in sequence and scale, are necessary but insufficient precursors for getting there.

Other things of Note

1. Lisa Koeman, in Unflattening Practice, thoughtfully approaches the tension of commoditization in research practice before and during the AI hype. I prefer that we consider quality before we pray to the altar of efficiency.
2. I enjoyed John Cutler's How and Why We Help, where he highlights Peter Block's emergent and relational view of consulting: "In Block's view, the consultant's role is not to bend the model to fit the context but to help people within the system see that they ARE the context and that change emerges through their engagement with it. ... The consultant doesn't apply a solution to the context—they help the solution grow out of it." Here is a wonderful frame for a kind of consulting that does not make the system dependent on the consultant's intervention.
3. Before I started DRC-v1 in Denver, Colorado, my dad gave me a copy of Peter Block's Flawless Consulting. I was not so receptive to his wisdom: I was already an expert at UX research and design strategy... why did I need to become a flawless consultant? It's been over 7 years since then. I believe it's time to revisit the book.