Context

A three-week redesign for a five-person startup is different from the same redesign inside an enterprise with compliance, legacy systems, and many stakeholders.

Same task. Different context. Different level of work.

Many case studies treat context as a short introduction and rush toward the solution.

But context explains why the solution was difficult, why the decision made sense, and why the result mattered .

Situation — what was happening?

Stakes — what would be affected if nothing changed?

Constraints — what real limits shaped the work?

Why It Mattered — why was this problem worth solving?

Give enough information for a stranger to understand the system, users, team, and current state.

Keep only what affects the decisions that follow.

Stakes may include revenue, deadline, trust, compliance, adoption, team capacity, or reputation.

Without stakes, importance remains unclear.

Limited budget, short deadlines, legacy code, weak data, many stakeholders, hard policies, and technical debt shape decisions.

Constraints reveal judgment because not every option remains available.

“Conversion increased 8%” may be modest or exceptional depending on baseline, traffic, timeframe, and business model.

Context should not become a place to blame constraints or defend weak results.

Its purpose is to help people evaluate decisions and contribution fairly.

Each Project should include a context block that can stand alone for a stranger or AI: what the project is, who it serves, the problem, stakes, and constraints.

Then move into role, contribution, evidence, and result.

Before explaining what you did, help people understand the world in which the work existed .

Situation → Stakes → Constraints → Why It Mattered.