Quick Comm

Pick one — and only one

• A case study that tries to be all four says nothing. The strongest portfolios commit to a single thesis per story.
• If two genuinely apply, that's usually a sign there are two case studies here.

Four distinct problems. They are rarely the same.

• User problem — what people actually experienced. Use the form “users were trying to ___, but ___ made that difficult”, not “users wanted a seamless experience”.
• Product problem — what the product failed to enable.
• Business problem — what the business needed.
• Operational problem — inventory, fulfilment, delivery, timing, support. Quick commerce is constrained by physical operations, not just interface. This is the layer most portfolios miss and the one that will make yours credible.
• Don't invent an operational constraint. If you're unsure whether something was a real constraint, leave it out.

Ownership language

• Your labels: I owned · I led · I partnered with · I coached · I influenced · I reviewed · I designed · the team explored · another designer led.
• Avoid “we” where personal contribution matters, and avoid “I collaborated with” entirely — it says nothing.
• Name the other designers and what they owned. A strong manager says “my designer designed this, here is how I helped them get there.”

Answer these

• What did you and the team think the problem was at the start?
• What was the original request, and who made it?
• Why was that initial understanding incomplete — if it was? If it turned out to be right, say so; not every story needs a reframe.

Answer these

• What specifically changed the understanding — a data pull, a user conversation, an operational reality, a competitor, a failed experiment?
• For each insight, use the form: observed behaviour → underlying need → product implication.
• If there was no research, say what you used instead. “We had no time for research so I used support tickets and my own order history” is a credible senior answer.

Also reconstruct the options you rejected

• For each direction considered: what it was, what problem it tried to solve, what it improved, what it made worse, what it cost in design, engineering, operations or business, and why it was rejected.
• Your knowledge base calls this out specifically: “this is where the seniority story becomes visible.” It's right.
• At least one decision should be about what you chose not to build.

Answer these

• How did you create clarity out of the ambiguity?
• Which designer explored what, and how did you challenge or guide them without taking the work over?
• Where did you disagree with Product, Engineering, Ops or the founders — and how did that resolve?
• What did you push for on quality, and where did you consciously accept a compromise to ship?
• Your knowledge base's model: ambiguity → you create clarity → team explores → you challenge and guide → cross-functional alignment → team executes → product learns → outcome. Where in that chain did you change the trajectory?

Send artefacts and I'll lay them out

• Every screen should answer “why does this screen exist?” rather than “what does it look like?” Give me one sentence per artefact and I'll caption them that way.
• Evidence hierarchy for this page: the product tension first, then the key decision, then the experience or system, then supporting screens, then the outcome. Not a gallery.
• Early messy thinking — a problem map, a state diagram, a flow sketch — is worth more here than polished UI.
• If motion or animation mattered, say so. Your knowledge base notes you considered freelance motion support for a Firstclub project, but doesn't say which — so I haven't assumed it was this one.

Which of these did the work actually address?

• How much information is shown at once, and how hierarchy is established.
• How quickly someone can understand the current state.
• How uncertainty is communicated, and how the product sets expectations.
• How the interface handles waiting, and how it handles failure.
• How much control the user gets, and how speed is balanced against reassurance.
• How operational complexity is translated into user-facing states people can act on.
• Only claim the ones the work genuinely did. This section is powerful because it's specific — it stops being powerful the moment it becomes a checklist.

Answer these

• What actually went live, and when?
• What was cut from the first release, and what was the plan for it?
• What surprised you after launch?

Any of these that are real

• Product: adoption, conversion, retention, order frequency, basket size, repeat rate.
• Business: revenue, margin, cost or effort avoided.
• Operational: fulfilment accuracy, support volume, time to resolve.
• User: a behaviour that changed, and how you know.
• Team: what the design team can now do that it couldn't before.
• Your knowledge base marks Quick Comm metrics as unrecovered. If you don't have numbers, say what changed and how you know. Never estimate.

One honest paragraph

• What did you get wrong, or realise too late?
• “We brought Engineering in too late, which cost two rounds of exploration” is a good answer. “I learned communication is important” is not.
• This section is read most carefully and is the easiest one to fake — which is exactly why an honest one lands.