Appreciative Inquiry Design Phase: Social Architecture

The Appreciative Inquiry Design phase turns a preferred future into arrangements people could actually use. Social architecture concerns how roles, relationships, authority, information and routines support that future. It asks what must be different in ordinary work, rather than assuming that a compelling proposition changes responsibilities by itself.

Coachful is our #1 recommendation for organizing the coaching inquiry and follow-through around that design. Worksheets can preserve useful stories and distinguish decisions from assumptions; sessions support the conversation; tasks and client records can carry agreed actions and actual review. The platform does not authorize organizational changes, create receiving capacity or turn a future-state statement into an achieved result.

This guide develops the conceptual work and an original fictional service-design case. The team rejects an unaffordable meeting arrangement, completes a practical operating agreement, tests fourteen requests and revises a failure in its response process. Every name, date, figure and event in the case is invented. The example is a learning case, not evidence of customer results.

Locate Design within the wider inquiry

The university-hosted Appreciative Inquiry Commons describes Design as bringing Discovery stories together with Dream's imagined possibilities. Discovery examines valued experience and the conditions that supported it. Dream develops a preferred future. Design considers the arrangements that could support it, while Delivery or Destiny concerns embedding action and continuing learning.

The Commons also describes Define as a later addition to the original four phases. Different accounts use different cycle names and adaptations. A coach should explain the actual scope being offered rather than imply that a short Design discussion completes the whole change process.

A team may already have a desired direction and useful Discovery material. It can focus on design while checking those foundations. If the preferred future is imposed, or nobody can identify evidence behind a supposedly shared strength, that gap remains. Moving to an operating plan does not repair an absent conversation automatically.

For the full context, see the Appreciative Inquiry 4D coaching guide. This article focuses on what must become usable between an aspiration and its implementation.

Understand social architecture as connected arrangements

The US EPA's Appreciative Inquiry participation guide places meaningful social architecture and strategic design elements in the Design phase, alongside organizational preferences and propositions. Its planning guidance also emphasizes representative participation, experience with the method and the staff effort needed for the process.

In practical terms, social architecture includes who can decide, whose input matters, how people exchange information and how work is supported and reviewed. It is connected to technical arrangements without being identical to them. A shared queue may show a request, but someone still needs responsibility and time to respond. A calendar may show a room as available while another team retains authority over its use.

Consider the desired experience, “People get a usable next step without chasing several departments.” The design might require a named intake owner, a defined response promise, clear exception rights, access to current information and a review route when a reply is late. Omitting any one can undermine the others.

This is why a team should examine relationships among choices. Giving an intake coordinator ownership without permission to obtain an answer creates accountability without influence. Giving them authority without boundaries may create risk. Adding checks without removing other work may increase delay. The architecture should make these tensions discussable rather than hide them behind a value such as collaboration.

Keep a proposition distinct from an operating agreement

A proposition can describe a preferred state in present-tense language to make it vivid. That does not make it a factual claim. “Every requester has a named owner and a usable next step” is an aspiration until the arrangement and actual evidence support it.

An operating agreement needs a different level of detail. Which requests? What counts as usable? When is a response due? What is the owner's authority? What happens when the decision belongs elsewhere? The proposition supplies direction, while those questions make the direction examinable.

Do not use positive wording to suppress a report that the arrangement failed. A requester's account of chasing an answer may reveal a condition the preferred future needs to address. Safety, legal rights and real contractual duties require their appropriate processes; they do not become optional because a workshop is appreciative.

Different participants may support the direction and disagree about how to achieve it. Distinguish consultation, recommendation and approval. The person with authority should explain the decision and the reasons a suggestion cannot be adopted. Do not describe attendance as consent to every subsequent responsibility.

Examine four connected design areas

The following four areas are an original practical aid, not a canonical four-part Appreciative Inquiry instrument. They help the coach ask whether the proposed arrangement can survive ordinary work.

Decision rights and roles. Name the person who owns a routine choice, who can approve an exception and who implements the result. Distinguish a recommendation from permission. Include a route for uncertainty, and avoid assigning someone the duty to obtain an outcome they cannot control.

Information and workflow. Define the event that starts the process, the minimum information required, the next recipient and what counts as completion. A notification is not necessarily a usable response. Check access to the information and how corrections reach people who relied on an earlier version.

Participation and relationships. Identify who will experience the arrangement and how they can influence it. Include people who receive work, people who make requests and people affected by exceptions. Offer suitable contribution routes. Sharing a personal success story is not a condition of having a legitimate operational concern.

Resources and learning. Count time, technical support, attention and review effort. Ask what existing work stops or changes. Define criteria for keeping, revising or stopping the design and an owner for reviewing unintended effects. A promising small trial is not automatic permission for wider rollout.

Trace the fictional design back to real strengths

A small internal training service wants requests about rooms and session arrangements to move without repeated chasing. Coordinator Nora, operations manager Luis, technical owner Nadia and representative requester Evie join the coaching inquiry. Nadia participates for the technical boundary discussion rather than committing to every meeting or request.

The team examines two earlier useful episodes. In one, Nora collected the date, group size and fixed constraint before approaching the room owner. In the other, Luis gave an explicit answer about a cost exception rather than leaving the coordinator to negotiate without authority. Requesters valued knowing who held the decision and what happened next.

The success had hidden support: Luis had protected time to consider exceptions, and the room information was current. A design that copied only Nora's helpful tone would miss those conditions. Nora also describes an unsuccessful episode in which she owned the communication but nobody had accepted responsibility for the technical decision. The group retains it as a limit the new arrangement must address.

The preferred future becomes: “For the requests in this service, the requester knows the responsible owner and a usable next step by the end of the next working day.” It does not promise that every exception is approved or that a complex issue is fully resolved in that time. Luis confirms that distinction before anyone designs around a false promise.

Reject an attractive but unresourced arrangement

One suggestion is a fifteen-minute daily meeting with all four roles. Over five working days, four people attending fifteen minutes would require three hundred person-minutes. The pilot has only 150 staff minutes allocated for request handling, special decisions and its closing review. The meeting proposal fails before considering the request work itself.

Nadia also declines a standing daily commitment because of already accepted technical duties. Her refusal is not treated as resistance to collaboration. Luis accepts that the design needs another route and authorizes a small asynchronous request log, bounded manager review and a fifteen-minute closing conversation with Nora.

Luis makes the capacity real by deferring a nonurgent internal reporting item for this pilot. Nora accepts the intake work and Luis accepts the exception role. Nadia agrees that named technical requests may be referred for an actual capacity decision; she does not promise unlimited immediate answers. Evie checks whether the proposed replies would help someone who does not know the internal organization.

The team chooses a one-week service pilot, 4–8 March 2030, with correction and closing review on 11 March included in the 150-minute budget. It does not label the arrangement a permanent new governance structure.

Complete the operating agreement before the first request

The fields are useful only if people can apply them. The team walks through a routine room change, a request exceeding room capacity and a new technical-tool request before opening the pilot. Nora correctly distinguishes a room that is physically empty from one whose owner has released it. Luis confirms that the written boundaries match his actual authorization.

They also test the response definition. “We are looking into it” does not name the next usable action or a specific update arrangement. Evie rejects that as insufficient even when it arrives on time. The group records her objection and retains the stronger definition rather than counting any acknowledgment as success.

Follow the actual requests and their different outcomes

Fourteen requests arrive. Ten fit the routine rules and are completed. Two of those need an extra clarification from the requester, which Nora obtains rather than guessing. Her routine authority does not include charging for an out-of-hours slot or moving another team's allocation.

Of the four exceptions, one group of eighteen cannot use a room with capacity twelve. Luis obtains the relevant room owner's answer: a larger released room is available on 15 March, not the original date. Nora offers that specific alternative, and the requester accepts it. The actual reservation is changed; the future session's attendance or usefulness is not claimed.

A second requester wants an out-of-hours slot that would add an £80 charge. The pilot permits no new spending. Luis declines the cost exception and offers the existing daytime arrangement. The requester confirms that they will retain it. The budget rule has been checked against a real cost, not merely mentioned in the brief.

A third request conflicts with another team's retained allocation. The owner refuses the proposed move, Luis accepts that boundary and the requester withdraws the change rather than pursuing another slot. This is a completed decision, not a successful reschedule.

The fourth exception asks to use an unapproved technical tool. Its initial response reveals the design's most important failure. The other thirteen requests receive usable next steps within the response window; this one does not.

Show the missed promise and actual repair

The technical request arrives on Thursday 7 March. Nora records herself as communication owner and asks Luis about the approval route. By Friday at 17:00 UTC she has no confirmed technical decision or update arrangement. She sends, “We are looking into it.” It is an acknowledgment on time, but it fails the team's own usable-response definition.

On Monday 11 March, Nora acknowledges the miss to the requester: “I did not give you a usable next step by Friday. The new tool is not approved. Nadia owns the technical decision and has agreed to review the request on Tuesday at 15:00 UTC. For the planned session, the existing telephone arrangement is available if that meets your needs. Would you prefer that route or to wait for the technical decision?”

Nadia has actually accepted the named review after a five-minute triage conversation, not merely been nominated by Nora. Luis confirms that the existing telephone route is permitted. The requester replies that morning accepting the telephone arrangement for the session. Nora confirms the joining details. The new tool's technical approval remains pending; the accepted interim route does not approve it.

The case therefore has ten routine completions, two confirmed exception alternatives, one withdrawn change and one pending technical approval with an accepted interim arrangement. The final category stays visible. Reporting fourteen resolved requests would hide both the retained approval question and the missed response promise.

The timely usable-response count is thirteen out of fourteen. Nora's later correction does not retrospectively make the original deadline met. Equally, a missed promise does not mean the corrected information is worthless. The team can preserve both facts and learn from the difference.

Count the actual architecture's work

The original handling plan allowed forty-two coordinator minutes for fourteen intakes at three minutes each, twenty minutes for ten routine completions at two minutes each, twenty-eight manager minutes for four exceptions at seven minutes each, and thirty person-minutes for the fifteen-minute two-person closing review. That totals 120 minutes, leaving thirty within the 150-minute allocation.

Actual coordinator work is sixty-two planned minutes plus five minutes obtaining the two additional clarifications and six minutes repairing the late technical response, seventy-three minutes. Luis uses twenty-eight planned exception minutes plus eight on the ambiguous technical route, thirty-six. Their closing review uses thirty person-minutes, and Nadia's actual triage adds five. Total effort is 144 minutes, leaving six.

The account includes the Monday correction and close, as agreed. Discovery and Design workshop time is separate from this limited request-handling budget. It is not presented as a complete running cost for an organization or a saving against an unmeasured baseline. Participants' time making requests and the later technical assessment are outside this pilot account and not claimed free. The Tuesday review is still future work whose time and authorization must be managed separately.

At the close, Luis retains the small scope and refuses immediate expansion to other teams. Six spare minutes do not establish that the design can absorb a larger caseload. Nora says the explicit decision boundary helped, while the technical exception still made her feel responsible for producing an answer she could not authorize.

Revise the design rather than blame the coordinator

The team changes the escalation rule: if a named decision owner and update time are not confirmed by 14:00 UTC on the response-due day, Nora alerts Luis. Luis must choose an accepted update arrangement, a permitted interim option or an explicit statement that the requested service cannot yet be offered. Nora still owns communicating the actual decision.

Luis accepts that responsibility and Nora accepts the revised trigger. Nadia confirms that the rule must not promise a technical review time before she or another authorized owner accepts it. Evie checks the revised reply example and says it now explains what a requester can choose. That is feedback on an example, not proof the revised rule will prevent the next miss.

They schedule a further small test and a review after it. Its results are not yet available. The current Design output is a corrected operating agreement with accepted roles, a resource account and a known unresolved technical decision. The pilot supplies early Delivery learning without being mistaken for a completed organizational transformation.

Facilitate and record Design in Coachful

1. Bring the evidence and direction together. Share an original worksheet with useful episodes, enabling conditions, preferred experience and limits. Do not copy a proprietary workshop pack or require a personal story from every participant.
2. Clarify actual influence. Record who contributes, who recommends and who authorizes each decision. Agree suitable written or spoken participation routes and check access to the materials.
3. Complete the practical fields. Use roles, information, workflow, participation and resources to examine the arrangement. Keep an aspiration, a proposal, an accepted commitment and an actual result distinct.
4. Use the actual review and feedback routes. Coach review on supported submitted worksheets is private to the coach team. It does not deliver feedback to the client; send the actual explanation through the agreed client conversation with its authorized staff audience.
5. Assign controllable actions. A task can record Nora's request, Luis's decision or the review preparation. It cannot make Nadia accept a technical review or grant room authority.
6. Close the loop with actual evidence. Record fourteen outcomes, the missed deadline, corrected reply and 144 minutes, alongside the future unknowns. Do not mark the revised rule tested before it is used.

If recaps are used, they send automatically by default. For a review-first process, use Sessions settings, Session AI, Session recaps and Approve before sending, checking session-type overrides. Remove language saying everyone consented or the proposition was achieved when the evidence says otherwise. Keep the recap private where appropriate and review suggested tasks separately.

For a related inquiry into participation and decision authority, see building a dialogue container. The Coachful features support the coaching process while organizational work remains in its approved operational systems.

Troubleshoot before increasing the scope

The design is only a positive sentence. Ask what a person would actually do when a request arrives, who can authorize it and how someone knows the work is complete.

Participation produces no influence. Explain which decisions are open, invite relevant alternatives and give reasons when an option is refused. Do not call a predetermined choice co-designed merely because people attended.

A successful episode depends on invisible effort. Ask who supplied time, expertise or informal favors. A design that transfers the visible process without those conditions may transfer the burden instead.

A trial looks successful until exceptions appear. Include ambiguous and refused cases in review. Fast routine work does not establish an effective escalation route, and a later repair does not erase a missed deadline.

Frequently asked questions

What does social architecture mean in this guide?

The connected arrangements through which people work together: roles, rights, relationships, information, routines, resources and learning. The practical four-area aid is original, not a universal AI instrument.

Is a Design proposition an achievement?

No. It describes a desired state. An accepted operating agreement and actual evidence are separate. Here the response promise is missed once despite the shared direction.

Does Design require restructuring the organization?

No. A bounded arrangement can reveal important dependencies. Changing one process still requires the appropriate authority, resources and attention to wider effects.

Can we keep difficult stories in an appreciative process?

Yes. In this application, a failed handoff reveals a condition the preferred future needs. Appreciation does not justify ignoring harm, rights or contradictory evidence.

What should happen after the first pilot?

Review actual outcomes, workload and participant experience, then keep, revise, stop or request a different authorized scope. This team retains a limited arrangement and schedules another test without claiming its future results.