8 - The Final Goal: Users Shouldn’t Need to Know How to Use 5D+
It sounds a little strange.
I have spent years building hundreds of tools, dialogs, buttons, shortcuts, and workflows for 5D+.
And yet, one of the goals I am now working toward is:
One day, architects may not need to know how to use most of them.
Not because those tools will disappear, but because there may be a new layer between what the architect wants and the tools that make it happen.
Architects should think more about architecture than software
This idea has always influenced how I develop 5D+:
Architects should spend more time thinking about the building than thinking about the software.
An architect thinks:
“Create the second-floor plan.”
But software makes us think:
Which tool? Which dialog? Which option? Which Tag? Which Scene? Which Section Plane? What scale?
We start with an intent, then have to translate that intent into many software operations.
This was actually one of the reasons I created the original One Click workflow in 5D+. But it also created another problem: many users didn’t understand what 5D+ was doing behind that one click, and customization still required learning the system.
AI made me ask a different question:
Why should the architect have to do that translation at all?
Imagine saying:
“Create all the basic plans, elevations, and sections for this building.”
An architect understands that immediately.
Instead of the user manually creating Scenes, Section Planes, cameras, visibility states, grids, dimensions, annotations, and labels, what if another layer could understand the request and call the right 5D+ tools?
Then the workflow becomes:
Architect → Intent → AI → 5D+ → Result
The architect says what they want. AI figures out which actions are needed. 5D+ performs those actions accurately.
AI should not do everything
This distinction is very important to me.
I don’t want AI freely guessing how to modify the Model.
AI is very good at understanding language and intent. But 5D+ has accumulated years of logic for Scenes, Dimensions, Annotations, Classification, IFC, Drawings, Export, Paper…
So I see the responsibilities differently:
AI understands what the user wants.
5D+ knows how to do it.
AI doesn’t replace 5D+.
AI becomes a new way to communicate with 5D+.
And when Project Data is connected as well, this becomes much more interesting. An architect could ask about project information, find the related objects in SketchUp, create a schedule, place it on a Sheet, or update the affected documentation.
The Model provides Geometry. Project Data provides information. 5D+ provides the workflow logic. Paper provides presentation. AI connects all of them to the architect’s intent.
UI will not disappear
I don’t believe the future is only about prompts.
Architects still need to look, select, drag, adjust, and directly interact with the design.
The Touch & Feel I talked about at the beginning of this series is still extremely important.
Some things are much faster to say.
Other things are much faster to grab with the mouse and move. 
So I don’t see AI replacing the UI. I see it as another interaction layer.
Prompt to create.
Mouse to adjust.
UI to control.
Data to manage.
All working with the same system.
Intent First. Tools Later.
This brings me back to the ideas behind this whole series:
Draw First. Define Later.
Don’t let data structures interrupt creativity.
Model Data ≠ Project Data.
Don’t make the Model a bottleneck for information.
Output ≠ Project.
Don’t spend human effort maintaining outputs that can be regenerated.
One Continuous Creative Flow.
Don’t let Paper interrupt the architect’s way of thinking.
And now:
Intent First. Tools Later.
Don’t force architects to think in the language of software if the computer can understand the language of architects.
Maybe one day, an architect can simply open SketchUp and say:
“Let’s continue working on Level 3 today.”
And the system already understands the project, what has changed, which drawings need attention, and which sheets are affected.
At that point, perhaps the architect is no longer really “using 5D+.”
They are simply:
Doing architecture.
And 5D+ is quietly doing its job in the background.
I think that would be a beautiful destination for a piece of software.
The best tool may eventually be the one you no longer need to think about.
And if 5D+ can get closer to that, then all the tools, dialogs, APIs, Data Bridge, Paper, and MCP I am building today are ultimately serving the same goal I had from the beginning:
