Every design thinking project starts with a simple question: what problem are we actually trying to solve? The Initialize stage exists to answer that question before you invest time in research, ideation, or prototyping.

Skip this stage and you will regret it. Teams that rush into empathy research without first framing the challenge tend to collect unfocused data, interview the wrong people, and end up three weeks later with a wall of sticky notes that don't add up to anything useful.

Five essential components to define before beginning any design thinking project

Why Initialization Matters

Most design thinking frameworks start with "Empathize." We add Initialize as a distinct first stage because, in practice, the difference between a productive design thinking project and a frustrating one almost always comes down to how well the challenge was framed at the start.

A well-initialized project gives your team three things:

Shared understanding of what you are (and aren't) trying to solve.
Clear boundaries so research stays focused and actionable.
Success criteria so you can evaluate solutions against something concrete rather than gut feeling.

Think of it as drawing the edges of the puzzle before you start filling in the pieces.

The Four Components of a Good Project Brief

1. The Challenge Statement

The challenge statement is a one or two sentence description of the problem space you want to explore. It should be broad enough to allow discovery but narrow enough to be actionable within your timeline and resources.

Here is what a bad challenge statement looks like: "Improve the customer experience." That is too vague. Improve which part? For which customers? What counts as "improved"?

A better version: "Reduce the friction that first-time users experience when setting up their account in our mobile app." That gives you a specific user (first-time), a specific context (mobile app setup), and a specific focus (friction/difficulty).

Notice that the challenge statement does not prescribe a solution. It does not say "redesign the onboarding flow" or "add a tutorial." It describes the problem space and leaves the solution open. That openness is intentional. If you already know the solution, you do not need design thinking.

2. Target Users

Who are the people affected by this challenge? Be specific. "Our users" is not specific enough. You need to identify which segment of users you are focusing on and why.

Useful questions to answer at this stage:

Who experiences this problem most acutely?
Who are you designing for, and who are you explicitly not designing for?
What do you already know about these people? What do you assume but have not verified?
Where can you find these people for research interviews?

You do not need full personas yet. That comes later, during the Empathize stage. Right now you just need enough clarity to plan your research.

3. Constraints and Context

Every project operates within constraints. Acknowledging them up front prevents wasted effort later. Common constraints include:

Timeline: How long do you have? A two-week sprint and a three-month engagement require very different approaches.
Budget: What resources are available for research, prototyping, and testing?
Technical limits: Are there platform, infrastructure, or regulatory restrictions?
Organizational reality: Which stakeholders need to be involved? What has been tried before and why did it fail?
Industry context: What domain are you working in? Healthcare, education, fintech, and retail each have their own norms and regulations.

Constraints are not obstacles. They are design parameters. Some of the most creative solutions emerge precisely because of constraints, not despite them.

4. Success Criteria

How will you know if your solution works? Define this before you start, not after. Success criteria keep you honest and prevent the common trap of declaring success based on how much effort you invested rather than how much impact you created.

Good success criteria are specific and measurable:

"Reduce first-time setup abandonment rate from 40% to under 20%"
"Increase the percentage of new users who complete their first task within 10 minutes from 30% to 60%"
"Achieve a System Usability Scale score above 75 in post-task surveys"

If you cannot define measurable criteria yet, that is fine. Start with qualitative goals ("Users should feel confident navigating the setup process without help") and plan to refine them as your understanding deepens during research.

Running an Initialization Workshop

If you are working with a team, spend 60 to 90 minutes in an initialization workshop. Here is a simple format:

Context download (15 min): The project sponsor or stakeholder shares what they know about the problem. What triggered this project? What data exists? What has been tried?
Assumption mapping (20 min): Each team member writes down their assumptions about the problem, the users, and potential solutions. Post them publicly. This surfaces where the team agrees and where there are blind spots.
Challenge framing (20 min): Collaboratively draft the challenge statement. Debate scope. Is it too broad? Too narrow? Does everyone agree on what "in scope" means?
Research planning (15 min): Based on the challenge and assumptions, plan what you need to learn during the Empathize stage. Who will you talk to? What will you observe? What questions matter most?
Alignment check (10 min): Read back the challenge statement, target users, constraints, and success criteria. Does everyone agree? If not, resolve it now, not three weeks into the project.

Common Mistakes

Starting too broad. "Reimagine the future of healthcare" might sound inspiring, but it gives your team nothing to act on. Narrow it down. You can always widen the scope later if research reveals a bigger opportunity.

Starting too narrow. "Add a progress bar to the signup form" is a solution, not a challenge. If you have already decided what to build, you do not need design thinking.

Skipping constraints. A team that does not discuss constraints up front will inevitably propose solutions that cannot be built, funded, or shipped. Surface the constraints early so creativity happens within realistic boundaries.

Not involving stakeholders. If someone with decision-making power was not part of initialization, expect them to challenge your direction later. Get alignment early.

What Comes Next

With the challenge framed, users identified, and constraints documented, you are ready to move into the Empathize stage where you will talk to real people, observe real behaviors, and challenge every assumption you wrote down during initialization.

The brief you created is a living document. Expect it to evolve as you learn. The point is not to get it perfect. The point is to get your team aligned and your research focused.