Three Types of Designers
- Author: Marco Morales
- Framework type: Practitioner synthesis
- Status: Active — in use at Schema Education
- Last updated: April 2026
Designers trained in different environments develop different default operating modes — and those defaults create friction when left unstated. This framework names three modes: the Agile Designer, the Agency Designer, and the Academic Designer. Each reflects a different set of defaults around speed, process structure, and method selection. The framework's central claim is that experience moves designers toward the intersection of all three.
The Three Modes
| Mode | Training Origin | Default Speed | Default Process | Default Method Selection |
|---|---|---|---|---|
| Agile Designer | Bootcamp | Fast | Loose | Flexible / opportunistic |
| Agency Designer | Agency work | Deliberate | Structured | Mindful and varied |
| Academic Designer | University / HCI program | Slow | Structured and linear | Formal / research-gated |
These are defaults, not ceilings. A bootcamp-trained designer can learn to run structured processes; an academic can learn to move fast. The modes describe tendencies under pressure and in unfamiliar conditions — not permanent traits.
Mode Profiles
Agile Designer
Optimizes for speed and output; most comfortable in a build-test-learn loop.
- Strengths: Ships fast, comfortable with ambiguity, low process overhead, learns by making
- Risks: Skips discovery; jumps to wireframes before the problem is understood; produces iterative solutions to the wrong question
"When an Agile Designer is frustrated, they say: 'We're overthinking this — let's just build something and see.'"
Agency Designer
Optimizes for brief fidelity and deliverable quality; most comfortable when scope is locked before work begins.
- Strengths: Consistent output quality, clear project structure, strong ability to manage expectations and handoffs
- Risks: Over-invests in setup before execution; may block progress waiting for a complete brief; struggles when the brief is legitimately unknowable upfront
"When an Agency Designer is frustrated, they say: 'We can't start until we know exactly what we're making.'"
Academic Designer
Optimizes for research validity; most comfortable when a problem is fully understood before a solution is attempted.
- Strengths: Rigorous problem framing, strong research methods, defensible design decisions grounded in user evidence
- Risks: Analysis paralysis; difficulty moving to execution without user data; over-indexes on research rigor in low-stakes or time-constrained contexts
"When an Academic Designer is frustrated, they say: 'We haven't talked to any users yet — how can we design anything?'"
The Experienced Designer at the Intersection
The framework's most important claim is not that there are three types. It's that experienced designers don't default to one mode permanently — they calibrate mode to context. A senior designer might run an Academic-style discovery sprint on a novel problem, switch to Agency-style structured deliverables for client handoff, then use Agile-style rapid iteration during a prototype review.
The mode is a tool, not an identity.
| Context | Appropriate Mode |
|---|---|
| Ambiguous new problem, no prior research | Academic (research first) |
| Defined scope, client brief in hand | Agency (brief-driven execution) |
| Known solution space, rapid testing needed | Agile (build-test-learn) |
| Tight deadline, familiar problem type | Agile or Agency |
| High-stakes, novel domain | Academic or Agency |
How This Framework Applies
Reducing Team Friction
When team members don't know each other's default modes, they interpret process differences as incompetence or bad intent. Naming the modes makes the problem tractable: "We're running an Academic and Agency team on a project where the client wants Agile delivery" is a real coordination problem that can be solved. It's not a talent problem.
Identifying Composition Gaps
A team of all Agile Designers ships fast but produces iterative solutions to poorly-framed problems. A team of all Academic Designers produces excellent research and struggles to ship. The mode breakdown of a team predicts its failure modes as reliably as skill level does. A balanced composition — or a lead who can hold multiple modes — is the practical goal.
Informing Design Interviews
The framework is most useful in hiring when used to listen, not to filter. Ask candidates to describe their process on a past project and listen for:
- Which mode they default to and whether they can articulate why
- Whether they show awareness of the other modes — can they name when their default mode would have been wrong?
- Whether their "best work" story is single-mode or involves shifting between modes
Scoping Projects Realistically
Academic-mode projects require discovery time that Agile timelines don't budget for. Understanding the mode of both the team and the client avoids timeline surprises. A client who expects Agile velocity paired with a team with Academic defaults is a recipe for missed deadlines and mutual frustration — not a talent issue.
Supporting Evidence
Nielsen Norman Group — Design Thinking 101 (Sarah Gibbons, 2016) describes a six-phase framework — Empathize, Define, Ideate, Prototype, Test, Implement — grouped into Understand, Explore, and Materialize phases. This directly validates the Academic mode's research-before-solution principle, and the existence of a structured sequential process as a legitimate default. It also complicates the "Academic = rigid" reading: NN/G explicitly frames design thinking as adaptable scaffolding, not a fixed recipe — "Be a master chef, not a line cook." That nuance aligns with the intersection thesis, where experienced designers adapt mode to context rather than following any one approach mechanically. https://www.nngroup.com/articles/design-thinking/
IDEO U — Design Thinking documents the iterative, non-linear nature of design practice, emphasizing that teams cycle between phases and that flexibility is core to the methodology. This validates the claim that experienced designers blend modes rather than defaulting to one permanently. It also pushes back on characterizing Academic designers as inherently linear — contemporary design thinking (including academic traditions) explicitly rejects pure linearity in favor of iterative loops. https://www.ideou.com/pages/design-thinking
Nielsen Norman Group — When to Use Which User-Experience Research Methods maps 20 UX research methods across three dimensions: attitudinal/behavioral, qualitative/quantitative, and context of use. The existence of this map — and the expertise required to navigate it — validates method selection as a distinct craft skill, which is precisely what separates Agency and Academic modes from Agile defaults. Agile practitioners often skip this selection process entirely; Agency and Academic practitioners treat it as foundational. https://www.nngroup.com/articles/which-ux-research-methods-when/
The Organization's Design Research Maturity Model (UX Collective) documents how organizations vary in their approach to research rigor and process systematization, with a clear spectrum from ad-hoc to institutionalized practice. This validates the framework at the organizational level: the loose-to-structured process spectrum Morales describes in individual designers also appears in teams and organizations. It suggests the three modes may reflect broader industry patterns, not just individual training artifacts. https://uxdesign.cc/the-organizations-design-research-maturity-model/
Limitations and Open Questions
Scope of validation: This framework is Morales' original synthesis. No published academic research directly validates a three-type designer classification of this kind. The evidence cited supports components of the framework — the research/iteration/structure spectrum, the value of deliberate method selection, the contextual adaptability of experienced practitioners — not the framework as a whole.
- The three categories may be oversimplified. Many designers are hybrid by training — bootcamp graduates with prior academic backgrounds, agency professionals with formal HCI coursework — and don't map cleanly to one origin.
- Training origin may be less predictive than years of experience, specific project types worked on, or the dominant culture of past employers. The modes describe defaults, but defaults shift with context and time.
- The framework does not yet address designers-in-transition or junior designers who haven't yet settled into a default mode. An "unstable default" is probably a real condition worth naming.