JavaScript Disabled

To enjoy the full experience available to this page, please enable JavaScript for this browser.

A UX Design Process with ADDIE

First published by : July 2017

ADDIE (Analysis, Design, Development, Implementation, Evaluation) is a dynamic, non-linear, and evaluative instructional design cycle closely related to how we learn and how we think. ADDIE considers our end-users' performance and not only their tasks, which fits the needs of user experience (UX) design well. Our digital marketing will benefit too!

ADDIE is just one design processes perhaps based on similar work to Herbert Simon's 1969 decision making model and other works traceable back to John Dewy. You may be familiar with the "UX Design Process" of Research, Insights, Design Concepts, Test Prototypes, Develop; or "Design Thinking" of Empathise, Define, Ideate, Prototype, and Test? Each is based on similar, if not the same cognitive models.

I find ADDIE the most comfortable to apply across a range of situations and the easiest to share with our team. It is notable for the emphasis on cyclic formative evaluation through each stage of the process and its flexibility in application. As a process of iterative and continual improvement rather than a linear model of progression, it fits Agile Scrum and (UK) Government Digital Standards (GDS) methodolgies well.

The process label aside, designers facilitate the engineering and development a product needs to be accessible, usable, learnable, and useful. We are our users' advocate and their champion. The process must begin with our users...although our enterprise should learn what its goals are too!

Shared Learning

If you think this content is useful to your Friends, colleagues, or connections, then please consider flagging it to them.

I love to Experience Learning Too. Your feedback is welcome.

A process

ADDIE (Analysis, Design, Development, Implementation, Evaluation) follows a familiar cognitive and cyclic process model.

Research is essential to the ADDIE process and is far more efficient than you might believe. Research is reusable across related design cycles. Perhaps we should refer to (R)ADDIE?

Each stage of the process is a cycle or eddy that inter-relates to or disrupts other stages in the process.

The ADDIE process related to Agile software development
My Research, Analysis, Design, Develop, Implement, Evaluate product design process

Analysis should be one of our greatest efforts. Scrimp here, and quality will suffer.


Analysis ☝





Close The Accordions

Considering the user journey

At each stage of the ADDIE process, I ground the work to the basic user journey and the enterprise's values, aims, and objectives.

The basic user journey
At each stage of the ADDIE process I consider the user journey: Needs, Tasks, Input, Output, and Review the implications
The Basic User Journey Stages
Journey Stage Concept
Wants Wants give context to the user journey and enterprise aims. What our user and our enterprise want may not match what is needed.
Needs Needs may indicate requirements, or preconditions that must be met to complete the journey.
Tasks Tasks are discrete objectives formed from needs, against which success may be measured on completion of the journey.
Input What our user and enterprise must actively do or to provide to achieve tasks set during the journey.
Output The result of performing  tasks such as knowledge acquisition, product orders being processed, or giving feedback on journey progress, etc.
Review An overview of the status of a task or journey, of any further activity required or set in motion; perhaps an event history or time-line with which to track task or process progress, etc.
Recycle There may be two or more phases: first, that our user and enterprise may access and repeat the journey or tasks as necessary, and second to review the success of each task or journey with a view to identifying improvements that can be made.

Note: See an application of the Basic User Journey that enabled an 'eleventh hour' rapid understanding of, and design update of a failing UI.

Conflict and change

Conflict between designers can appear 'bloody' and at times damaging. But the benefits can outweigh the emotional wounds, which should be shrugged off by next breakfast anyway.

Conflict tests habits, ideas, and perceptions. It invigorates debate and encourages learning and change.

Designers will almost always conflict over something or other. At times the conflict will be trivial and at others you may see cataclysmic exchanges including salvoes of id. But as long as it is not only the loudest voice or largest ego that wins, and the outcome is positive to the enterprise, then it can be encouraged*.

Designers know that conflict is healthy. And they should know when it is not. Team managers need to be aware that conflict generally has a cause - and right or wrong, that cause may feed vital insight into a design.

*Caution: never leave two instructional designers on their own in a room together for longer than half a cup of coffee. (At least, not armed with tea spoons 😂)


There's no one-size-fits-all design process. ADDIE outlines the general flow. Each designer and enterprise will follow what works for them. It is only essential that whatever the analysis is, that it is thorough and not overly compromised by low resources.

It is important for the designer takes ownership of their design and support its development and implementation closely. They must be available to make informed decisions quickly when issues arise with it. Designers are a resource too.

It's the thought that counts?
Meme: It's not a bug - it's a feature

❮ Portfolio UX Workflow ❯

Sponsored Ads

Ads collated  by Google Ad Sense. Click away..!