Back in 1998, I was a university student embedded in a small team building software for field engineers. The application analysed the performance of gas and oil wells, and the engineers were the ones who had to live with what we built. They complained early, often, and loudly that the interface was too complicated to operate.

To be fair, I wasn’t the designer. There was no designer. We were a team of engineers building whatever features the users said they needed. Each request was a reasonable response to an isolated problem, but stacked together they formed a lasagna of an interface that nobody had ever looked at whole.

My job was writing the application logic. But out of self-preservation, I kept returning to the Data Flow Diagram we used as a blueprint, trying to locate where the burden on the user was coming from. I found it: a dense sequence of steps that could be broken apart and spread across a gentler flow. I drew a transition diagram to show how the steps could be reorganised, roughed out some crude UI blocks on paper to give the team a visual target, and they built it.

The engineers stopped complaining. If you know engineers, silence is a standing ovation. My role shifted quietly, without a title change or a pay raise, from application logic to user logic, what the team started calling the GUI layer.

That was my first encounter with design as practice. I had studied it in theory: Man-Machine Interaction and User-Centred Design were both part of my Software Engineering curriculum. But they lived there as subject matter, concepts to memorise and regurgitate on an exam paper. The oil well application was different: a real complaint, a real diagram, a real team that needed to see the answer on paper. The theory became legible only when the problem was live.

The door varies. Engineering, marketing, research, a bootcamp, a design degree, a different career altogether. Designers arrive from all directions. But the standard waiting on the other side is the same: the industry hires portfolios. It judges work on craft execution, the artefact on screen. Whatever path you took in, training of any form optimises for making things well.

The capacity to make something well is the foundation everything else rests on. But craft alone, however deep, doesn’t cover what practice actually requires.

Three things that no training route reliably addresses:

The brief, reading it more than executing it. Recognising when the problem you have been handed is the wrong problem, and having the judgement and standing to say so.
Influence: moving decisions made by people who didn’t hire you, don’t report to you, and are under different pressures than you are. This is the everyday condition of design inside almost any organisation.
What to develop next: knowing when to go deeper into craft, when craft stops being enough on its own, and what to invest in instead. There is no syllabus for this. Most designers hit the plateau not because they stopped working hard, but because they kept working hard at the wrong thing.

None of these show up in a portfolio. Training doesn’t touch them because training optimises for what it can assess. Reading the brief takes judgement through critical thinking. Influence takes empathy and persuasion. Knowing what to develop next spans craft, structure, and people, and is the question this whole book tries to answer.

This book identifies the parts of the job that no training route addresses and gives them structure, so you can develop with intent instead of accumulating experience and hoping the gaps close themselves. It is not a replacement for craft, but a framework for everything practice demands beyond making.

The Gapwhat design training teaches versus what practice demands