Design (Lifecycle Activity) Explained (ITIL® 5)
Preparing for the ITIL® 5 Foundation exam? Design is the second activity in the ITIL® Product and Service Lifecycle, and it's easy to confuse with Discover or with the actual building work. This guide draws the line clearly.
Quick Answer
Design is the lifecycle activity focused on turning a confirmed need into a solution — creating specifications, architectures, and prototypes that describe what will be built, before any actual building happens. It comes after Discover confirms the need is real, and before Acquire and Build turn the design into something real.
What Is the Design Activity?
Design takes whatever Discover confirmed as a genuine need and turns it into something concrete enough to build from — a specification, an architecture, a prototype, or some combination of the three. It's the planning and blueprint stage, not the construction stage.
Design work can range from a simple wireframe and a short requirements document to a detailed technical architecture, depending on the scale and complexity of what's being created. Either way, the goal is the same: reduce ambiguity before resources get committed to Acquire and Build.
Where Design Fits Between Discover and Acquire
Discover confirms the need is real. Design decides what the solution should actually look like. Acquire then obtains whatever is needed — people, technology, suppliers — to bring that design to life. Skipping or rushing Design tends to show up later as rework during Build, when it turns out the specification was too vague to actually build from.
Real-World Example
After Discover confirms customers genuinely want shipment-tracking notifications, the Design activity produces a short specification: what triggers a notification, what channels it goes out on (email, SMS, in-app), and a rough wireframe of what the notification looks like.
That design gets reviewed with stakeholders before anyone starts acquiring a notification service or writing code — catching a disagreement about whether SMS is in scope now, rather than after a developer has already built it.
Why This Matters
Understanding Design matters because:
- It reduces costly rework by catching ambiguity and disagreement before Build begins
- It gives Acquire a clear enough picture to know what resources — people, tools, suppliers — are actually needed
- It creates a shared reference point stakeholders can review and agree on before real investment happens
Common Exam Mistakes
The most common mistake is treating Design as optional for small changes, assuming it only applies to large, formal projects. Even a lightweight specification or sketch counts as Design — the activity scales with the size of the work, it doesn't disappear for small work.
A second mistake is confusing Design with Build. Design produces the plan — specifications, architecture, prototypes. Build is where that plan actually gets coded, configured, and assembled. Conflating the two blurs the point where planning ends and construction begins.
Memory Trick
Think:
Discover asks "what's needed?"
Design asks "what will it look like?"
Build asks "let's actually make it."
If you're sketching, specifying, or prototyping, you're in Design.
Key Takeaways
- Design is the lifecycle activity that turns a confirmed need into a specification, architecture, or prototype.
- It sits between Discover (confirming the need) and Acquire (obtaining what's needed to build the solution).
- Design work scales with the size of the change — even small changes benefit from a lightweight specification.
- Rushed or skipped Design work tends to surface later as rework during Build.
- This activity is part of the eight-activity ITIL® Product and Service Lifecycle, a frequently tested area of the ITIL® 5 Foundation syllabus.
One Practice Question
Which statement best describes the Design lifecycle activity?
- It is the activity where code is written and tested.
- It is the activity that turns a confirmed need into a specification, architecture, or prototype before building begins.
- It only applies to large, formal projects, not small changes.
- It is identical to the Discover activity.
Show Answer
Correct Answer: B
Design turns a confirmed need — established during Discover — into a concrete specification, architecture, or prototype, providing the blueprint that Acquire and Build then act on.
Frequently Asked Questions
Does Design apply only to large projects?
No. Design scales with the size of the work — even a small change benefits from a lightweight specification or sketch before it's built.
How is Design different from Build?
Design produces the plan: specifications, architecture, or prototypes. Build is where that plan is actually turned into working code, configuration, or assembled components.
What happens if Design is rushed or skipped?
Ambiguity that should have been caught during Design tends to surface later as rework during Build, when it becomes clear the specification wasn't detailed enough to build from confidently.
Is this topic tested on the ITIL® 5 Foundation exam?
Yes. The eight lifecycle activities, including Design, are part of the Product and Service Lifecycle, a significant and frequently tested area of the ITIL® 5 Foundation syllabus.
Ready to Test Yourself?
Now that you understand what Design covers, the next step is seeing how it connects to Acquire and the rest of the lifecycle. Take our free diagnostic quiz at PassTheFoundation.com to test yourself, or continue exploring the other ITIL® 5 lifecycle activity guides.