I have never liked starting with screens.
People open Figma, draw a dashboard, add a few cards, put a button in the corner, decide where the navigation goes, and somehow believe they are designing a system.
They are not. They are designing a picture of a system they have not thought through yet.
The screen is not the product. The screen is one interface into a process.
If you start with the screen, you can easily end up designing around whatever fits neatly in a card, modal, table, or form. Then later you discover the workflow underneath is fragmented, the state model is wrong, permissions have been bolted on after the fact, exceptions are ugly, and users have to adapt themselves to the interface instead of the interface adapting to what they came there to accomplish.
I tend to go the other direction.
Before I think about what a page looks like, I want to understand why somebody is there and what they are trying to accomplish. I want to know what state they are in when they arrive, where they are trying to get to, and what has to happen between those two points.
Then I think through the process itself. What information has to persist? Where can the process fail? What happens if the user leaves halfway through and comes back tomorrow? What happens if they change their mind? Who has the authority to move the process forward, and under what conditions?
By the time I get to the screen, I already understand the system the screen is supposed to expose.
That is the system.
The screen comes later.
We Used to Have Names for This
None of this is particularly revolutionary. Years ago, we routinely separated Functional Specifications from Technical Specifications. There was a reason for that.
The Functional Specification described what the system needed to accomplish from the perspective of the business, the process, and the people using it. It forced us to think through workflows, rules, expected outcomes, exceptions, dependencies, and the conditions under which one thing became another.
Only after that did the Technical Specification address how we were going to make it happen. What data would be required? Where would it live? What components were involved? What interfaces had to communicate? How would security work? What happened when something failed? What authorities were required? How were transactions handled? And most importantly how would the system preserve the state necessary to continue the process?
The two documents were related, but they were not the same thing.
That separation mattered because what a system must do and how a system will do it are different questions.
The user interface emerged from both.
Somewhere along the way, a lot of software development started treating the visual representation of the proposed system as if it were the system specification itself.
It isn't.
A wireframe can be tremendously useful after the process is understood. It can reveal usability problems, navigation problems, missing information, poor sequencing, or unnecessary friction.
But it is a terrible substitute for understanding the process underneath it.
Newer Is Not Necessarily Better
Technology has an odd habit of assuming that whatever replaced the old thing must automatically represent progress.
Sometimes it does. Yet sometimes we simply changed vocabulary, changed tools, made prettier diagrams, shortened the development cycle, and quietly discarded disciplines that existed because generations of people had already discovered what went wrong when you skipped them.
Functional and Technical Specifications could become bloated. Anyone who worked on large projects twenty or thirty years ago remembers documents that became enormous, bureaucratic, outdated before they were finished, and occasionally read by almost nobody.
Getting rid of that waste was sensible.
Getting rid of the thinking those documents forced us to do was not.
There is a difference.
Agile development did not make process analysis obsolete. Figma did not make system architecture obsolete. React did not eliminate state modeling. APIs did not eliminate business rules. AI coding assistants certainly do not eliminate the need to understand what the software is supposed to accomplish.
We can write less documentation without thinking less.
We can move faster without skipping the problem definition.
We can replace a 300-page specification with something much leaner while preserving the discipline that specification was originally trying to enforce.
That is where I think some modern development practices go wrong.
They correctly rejected heavyweight process and accidentally rejected structured thought along with it. But newer is not necessarily better.
Sometimes the old guys were doing something for a reason.
Start With Intent
A visitor doesn't arrive at a website thinking, I hope this company has designed a really attractive three-column card layout for me.
They arrive because they are trying to do something.
They may want an answer, buy something, publish an article, register for an account, retrieve information, solve a problem, or simply find out whether something worked. The interface should make that objective easier to accomplish, which means the process has to be understood before the page is designed.
Take the design of an affiliate program as an example.
I could start by drawing an attractive affiliate dashboard showing clicks, sales, commissions, and payout history. It might look terrific, but I still would not have designed the affiliate system.
I first need to understand how someone enters the program and what happens after that. A referral has to be associated with an affiliate somehow. That attribution has to survive long enough to matter. If the customer encounters more than one affiliate, there has to be a rule for which relationship controls. A sale may create a commission, but the commission probably should not become payable immediately because the underlying transaction can still be refunded or charged back. Eventually those commissions have to be grouped into a payout, reconciled, and retained as part of the financial history.
Once I understand that flow, the underlying state starts revealing itself naturally. I can see which relationships need to persist, which events change the state of the process, and where the system has to preserve enough history to explain later why somebody was or was not paid.
At that point the dashboard is no longer inventing the system.
It is simply showing the affiliate the parts of an already understood process that matter to them. That is when the screen becomes useful.
Why My Mind Goes to the Database
This is also why, when somebody describes new functionality to me, my mind tends to move toward the database fairly quickly.
It is not because I think every problem should be solved with a table. I am usually trying to understand what the application has to know about reality in order for the process to continue correctly.
If an affiliate refers a customer today and that customer buys something three months from now, the system has to preserve enough of that relationship to recognize what happened. If a commission is generated and then the purchase is refunded, the system needs to know both events occurred and how the second one affected the first. If authority changes halfway through a workflow, the application needs some reliable representation of the current state rather than simply assuming that whatever was true when the screen first loaded is still true now.
That is why data follows process so naturally for me.
Once I understand what the user is trying to accomplish and how the process moves from one condition to another, I start seeing the information the system has to preserve and the relationships it has to understand. Then I can decide where that data belongs, what should remain in application logic, how authority should be resolved, and eventually what part of all of that needs to be exposed through the interface.
So when I describe my own mental progression as:
Intent → Process → State → Authority → Data → Interface
I am not describing six boxes I mechanically work through.
It is really one continuous line of thought. Understanding the intent exposes the process.
Understanding the process reveals the state that matters. State raises questions of authority and persistence. Only after those are reasonably clear does the interface begin to make sense and take shape for me.
If I start with the screen instead, I am letting the easiest thing to draw constrain the hardest thing to understand.
That is the problem I have with wireframing first.
The Interface Should Reveal the Process, Not Invent It
There is nothing wrong with beautiful interfaces.
A terrible interface can ruin a beautifully engineered system. UX matters enormously.
But good UX should reveal and simplify an already coherent process. It should make the valid next action obvious. It should provide the information someone needs at the moment they need it. It should preserve context. It should make recovery understandable when something goes wrong. It should keep users from having to understand implementation details that have nothing to do with their objective.
What it should not do is become the place where the team first discovers what the underlying process is supposed to be.
That discovery should have happened earlier.
There is a significant difference between asking:
What should we put on this screen?
and asking:
Why is this person here, what are they trying to accomplish, and what must the system do to make that possible?
One question produces a screen.
The other produces a system.
That is why I do not wireframe first.
And maybe the larger lesson is this:
We should be careful about throwing away an old discipline simply because we invented a newer tool.
Sometimes the terminology changes.
Sometimes the artifact changes.
Sometimes the 200-page specification deserves to disappear forever.
But the thinking that made good systems possible?
That part was never obsolete.
When Appearance Starts Replacing Reality
There may be a larger reason this way of building software has become so attractive, and I don't think it begins with software.
We live in a culture that increasingly rewards immediacy. People want to see something, ship something, get a reaction, put it in front of users, demonstrate progress and move on to the next thing. A wireframe fits naturally into that environment because within a few hours there is something everyone can look at. It resembles a product, which makes it psychologically satisfying in a way that spending the same afternoon working through transaction states, authority rules or failure conditions simply is not.
The problem is that much of the work that determines whether a system actually functions is invisible. Nobody gets particularly excited looking at a state-transition diagram. Figuring out what happens when a user leaves halfway through a process, when a payment succeeds but another operation fails, or when an authorization changes before execution does not produce something pretty to show in a meeting. Yet those questions may matter far more than where the button goes.
This connects to something I have written about and we can all observe and its been years in the making in education, institutions, media, law, corporations and eventually AI. I keep finding the same structural problem: the representation starts gaining authority over the reality it was supposed to represent.
In education I have written about what happens when subjective interpretation, feelings, identity or immediate validation begin displacing external anchors. The important point has never been that feelings do not matter. Of course they matter. The problem begins when internal coherence becomes sufficient evidence of external truth, because then the uncomfortable process of testing what we believe against something outside ourselves starts disappearing.
That habit of thought does not stay inside a classroom.
People carry their way of understanding the world into every institution they eventually occupy, including software development.
That is the connection I had not really explored before.
When the Same Pattern Reaches Software Development
Software architecture is ultimately an expression of somebody's model of reality. Before there is code, there is an idea of how something works. There is a user with an objective, a process that changes something, information that must survive those changes, authority governing who may do what, and consequences when any of those assumptions turn out to be wrong.
If the person designing the system is accustomed to testing those assumptions against external constraints, modern tools are enormously powerful. They shorten the mechanical distance between understanding a problem and implementing a solution.
If that structural model is missing, though, the same tools can do something very different. They can make an incomplete idea look finished before the incompleteness has been discovered.
That is why the movement toward immediate visual development interests me so much. Someone can describe an application today and have a remarkably convincing version of it on the screen within minutes. The navigation works, the forms open, the buttons respond and perhaps there is enough data moving around to make the whole thing appear real.
Once that happens, human nature takes over. People begin discussing the thing they can see.
Now decisions about the process start getting made around decisions that were already made in the screen. The database gets shaped around what the interface expects. Permissions get inserted into an existing workflow instead of authority being considered when the workflow itself was designed. Exceptions become special cases because nobody thought about them until an actual user encountered one.
That is how the representation quietly becomes the reference frame.
The problem may remain hidden for quite a while because the happy path works.
Eventually something happens that was not in the picture. A customer returns tomorrow to something they started today. Two people touch the same underlying record. A transaction succeeds in one system and fails in another. Someone retains access after the relationship that granted the access has changed. An action that was valid when a process began is no longer valid when the system is ready to execute it.
At that point the screen has nothing useful to say, because the screen was never the system.
Reality has finally reached the parts nobody designed.
Vibe Coding Makes This Much More Interesting
This is where vibe coding enters the picture for me, because I use AI to write code constantly and I have no interest in pretending these tools are somehow bad for software development. Quite the opposite. I can take an architectural idea and move it into working code at a speed that would have seemed ridiculous earlier in my career.
The question is what happened before I asked the AI to write anything.
When I think about a new function, I normally start thinking about the process. Why is the person there? What are they trying to accomplish? What state exists before they begin and what state should exist when they are finished? Somewhere in that reasoning I usually find myself thinking about the data, because I need to know what the system has to remember and what relationships have to survive between one action and the next. Authority and failure conditions come into that same thought process because they affect which transitions should ever be permitted.
None of that means I have every technical answer before development starts. I don't. Building something often teaches me something about the architecture, and I change it. But there is already an underlying model against which I can judge what the AI produces.
That difference matters.
If I ask an AI coding tool to implement a process and it collapses two states that I know have to remain separate, I can see the problem. If it puts an authority decision in the browser when the server has to remain authoritative, I know it is wrong even if the interface works beautifully. If it stores information in the wrong place or creates a workflow that cannot recover from a partial failure, the generated code does not become correct merely because it compiled.
Someone without that underlying model is in a much more difficult position. The AI produces something, it resembles the requested application, and the visible result itself becomes evidence that the idea worked. The faster and more convincing these systems become, the easier it is to skip the period when the assumptions behind the application would otherwise have been challenged.
That is what concerns me about vibe coding. Not the coding and certainly not the speed.
It is the possibility that we have compressed implementation so dramatically that we also compressed away part of the interval where people used to discover that they had not actually thought the system through.
Twenty or thirty years ago, implementation imposed friction whether we wanted it or not. Even getting a mediocre application running took enough work that unresolved questions tended to surface along the way. Nobody should romanticize that inefficiency, and I certainly don't want it back. But some of the friction happened to occupy the same space where thinking occurred.
We have become very good at removing the friction.
We have to be careful not to remove the thinking with it.
That is where the cultural and educational connection becomes important to me. If someone has already developed a habit of accepting immediate internal coherence as sufficient confirmation, a tool that turns an idea into a convincing artifact almost instantly can reinforce that habit. The person sees what they imagined and receives immediate confirmation that the idea was right before external reality has had much opportunity to challenge it.
Vibe coding did not create that cognitive pattern.
It simply gives it an extraordinarily efficient way to become software.
Software Eventually Touches Reality
This might be relatively harmless if software remained inside the screen.
It doesn't.
Software moves money, changes records, determines access, establishes identity, controls equipment, communicates with other systems and increasingly gives AI agents the ability to take consequential actions without somebody manually performing each step.
That changes the consequences of sloppy reasoning.
If I make a bad visual-design decision, somebody may find the application annoying. If I misunderstand the process by which authority should change, the same application may permit something that should never have happened.
The deeper we move into autonomous systems, the less tolerance there is for confusing a convincing representation with a coherent underlying process. An AI agent does not care that the workflow diagram looked sensible when it was approved six months ago. At the moment of execution the system still has to determine what is true, what authority currently exists, what state has changed and whether the proposed action remains valid under the conditions that exist now.
Those are process and architecture questions.
A prettier screen cannot answer them.
Visible Velocity Can Be Misleading
There is also a very practical incentive behind all of this. Visible work is easier to reward than invisible thought.
A prototype can be demonstrated to leadership. A founder can put it in front of investors. A product manager can show the team that three new screens were completed this week. There is something tangible to point at.
Compare that with telling someone that the architecture team spent several days examining a transaction path and discovered that the original authority model could not safely support one of the proposed workflows.
Which one looks more productive on Friday afternoon?
The answer is obvious, even though the second discovery could prevent months of technical debt or a serious operational failure.
That is how speed becomes confused with progress. A team producing screens can appear to be moving much faster than a team still working through the structure underneath them. You may not discover which team actually made more progress until six months later, when one system survives contact with reality and the other has to be rebuilt around assumptions nobody challenged at the beginning.
Maybe We Threw Away the Wrong Part
This brings me back to Functional and Technical Specifications.
I do not want the giant documents back. I remember those too. They became bureaucratic, duplicated information, took forever to update and frequently contained pages nobody ever read.
Fine. Get rid of them.
What I think we should have been much more careful about was separating the artifact from the discipline behind it.
The Functional Specification forced us to articulate what the system was supposed to accomplish before we disappeared into implementation details. The Technical Specification forced another round of thought about how that process would actually exist in technology. You could argue with the answers, revise them, simplify them or throw half the document away, but at least the questions had been asked.
Modern development can preserve that separation without resurrecting the paperwork.
In fact, AI should make it easier. There is no reason a team needs three hundred pages to articulate a process clearly anymore. We can document the intent, workflow, important state transitions, authority rules, data relationships and failure paths in a fraction of the time it once took.
That would be genuine progress: keeping the useful thinking while eliminating the mechanical burden that surrounded it.
Instead, in some places we appear to have done the reverse. We eliminated the cumbersome artifact and quietly allowed the thinking associated with it to disappear as well.
Then we replaced it with something much more gratifying.
A screen.
The Faster We Build, the More This Matters
I am not arguing against Figma, Agile, rapid prototyping, AI coding or vibe coding. I use modern tools precisely because they let me move faster.
But speed magnifies whatever precedes it.
If the process is coherent, faster implementation gets that coherence into the world sooner. If the underlying model is confused, the same acceleration gets the confusion into production sooner.
That may be one of the most important changes AI introduces into software development. It does not merely make programmers faster. It shortens the distance between somebody's mental model and an executable system.
That makes the quality of the thinking upstream more important, not less.
We can generate the interface in thirty seconds now. That is remarkable.
The user still arrives with an objective. The process still has to make sense. State still has to survive. Authority still matters. Failures still happen, and reality still gets the final vote.
The tools changed.
The need to understand the system did not.
That is why I do not wireframe first.
