How I work
6D.
I wrote this process for the practice I lead. Six stages, and the first two are where most projects are won or lost.
Why it exists
Consulting teams under deadline pressure start sketching on day three. It feels like progress, it is easy to show a client, and it skips the part of the work that decides whether any of it was worth building.
6D exists to make that skip visible. A team cannot move to the third stage until it has understood the business context and spoken to actual users. The structure does the arguing, so an individual designer does not have to.
It is now the standard method across the practice, and it has survived contact with joint delivery plans where a partner firm brought its own methodology.
Business context, stakeholder goals, operational realities. What is actually true before anyone has an opinion.
Research with real users. The problem stated in a way the client may not have expected.
Experience pillars and concepts, made with the client in the room rather than presented to them.
Information architecture, flows, wireframes, visual system. Reviewed by engineering before the client sees it.
Prototypes tested with people who match the personas, then iterated.
Specs, assets and the handover, plus the support that makes a build match its design.
What it looks like in practice
On the banking project, three months and a fixed go-live date meant nothing could run in sequence. Research ran in five parallel streams during Discover and Define: a heuristic audit, a nineteen-bank benchmark, a dive into the bank’s own usage data, fifty customers surveyed in branches, and persona validation.
That produced a finding the brief had not anticipated. The app opened in under two tenths of a second and people still abandoned it, which meant the problem was comprehension rather than performance. Dream turned that into three experience pillars, each traceable to a line of research, and those pillars then settled arguments all the way through Design.