Direct answer
A strong story shows the designer treating the constraint as a design problem: understand the real constraint, get the right people together, write down the trade-off, protect the most important part of the experience, and then check whether the compromise held up after launch. The example is an illustrative skeleton.
Structured elaboration (what to include)
- Structure of the conversations: one-to-one first to understand each function's constraint, then one working session with a trade-off table.
- Recording the decision: a decision log entry with context, options considered, decision, owner, what was given up, and a revisit date and trigger.
- Checking afterwards: success criteria and a tripwire agreed before launch, and a review a few weeks after.
Worked example (illustrative story)
Situation. We were redesigning sign-up. My ideal was one screen with a single "agree and continue" action. Three constraints hit: the launch date was fixed by a customer contract, engineering could not finish a new form component in time, and legal (compliance) required that consent to marketing (agreeing to receive promotional emails) be separate, unticked by default, and clearly separate from the required acceptance of the terms and privacy notice (the company storing and using the account details needed to run the service; under GDPR Article 6(1) that processing normally rests on the contract, not on consent, and Article 7(4) is why marketing consent cannot be made a condition of signing up; the rules are jurisdiction-specific, so confirm with legal).
Structuring the conversations. I met legal first to learn which wording and layout were mandatory and which were preferences. I met engineering to learn what could be built in the window. Then one session with all three and a shared table: options (one screen, two steps, expanded single screen), what each cost in time, and what each did to the user.
| Option | Build time | Meets legal? | Effect on user |
|---|
| One screen, single agree | Short | No | Fastest, but non-compliant |
| Two steps, existing component | About 1 week | Yes | One extra tap |
| Expanded single screen, new component | Misses the date | Yes | Cleanest, but late |
Decision. Two steps: required terms and privacy acceptance first, optional marketing consent second, reusing an existing component. I protected the most important thing for users: sign-up remained possible in just two short screens with clear language.
Recording. A decision log entry (a short dated record of what was decided and why) listing the ideal design, the three constraints, the chosen compromise, what we gave up (the single-screen flow), the owner, and a review date. For example: "Sign-up: two-step flow. Context: fixed contract date, no new form component, legal requires separate marketing consent. Options: one screen / two steps / expanded screen. Decision: two steps. Given up: single-screen flow. Owner: design lead. Revisit: four weeks after launch, or when the new component ships."
Checking afterwards. Before launch we agreed that if the sign-up completion rate dropped below the old flow's baseline (the measured rate before the change) by more than an agreed margin, we would reopen the design. That tripwire (a pre-agreed number that automatically triggers a review) was illustrative: baseline 62% completion, margin 3 points, so anything under 59% reopens the design. Four weeks after launch I compared completion with the baseline and reviewed support tickets and five recorded sessions. The compromise held, and the single-screen version stayed on the backlog for when the component existed.
Trade-offs and pitfalls
- Do not present the compromise as a defeat or a victory; show the reasoning.
- Undocumented compromises get relitigated. The log prevents that.
- Do not quote invented metrics.
