It Takes Two to Build the Right Thing
Conversation not instructions is what we want
About a year ago, a site coordinator came to me with a request. Let’s call him Marcus.
He was confident, specific, and he knew exactly what he wanted. That’s actually a rare case. Most of the time, people know they have a problem but they don’t know what they need to solve it.
Marcus wanted a script that colours panels in a Revit model based on their installation status. His company was installing panels across a few storage warehouses and he wanted to know the statuses of the panels. The current workflow was every day, contractors on site would update an Excel sheet with that status. Marcus would then review that status but it was hard to know where those panels actually were. I mean they had IDs but how do you know where those panels actually are ?
So, he wants a script to read it and update the colours in the model.
I remember thinking, oh, this is straightforward. He’s already done the thinking, I just need to build it. The problem was clear and the solution made perfect sense. We signed. And a week later, I showed him the script.
Marcus nodded. “Yeah, that’s cool and all, but how do I see what the panels the contractors last installed? I need to see if we are on schedule”
I replied, “Uh.... you don’t. This reads the Excel sheet and colours the model. Like you wanted.”
“Okay, but I need to see which panels were installed before and which are installed today”
It turns out what Marcus actually needed was a way to retain the history of installation not just show the status of the panels. He wanted to see movement and statuses over time, not just update the model with the latest information.
The script worked perfectly. It just solved the wrong problem.
It would have been easy to blame Marcus for not communicating properly. But I also never asked why he needed to see the install statuses in the model. I didn’t ask why he wanted that information. He only told me after seeing the script for the first time.
I got lucky though. The rework was a straightforward addition. But if Marcus had wanted the site contractors to run the tool, or if there were more complex requirements buried in that brief, I would have been rebuilding from scratch. And I would be having an awkward conversation with Marcus about the fee.
Subscribe to CodedShapes and I’ll send you my free guide on how to actually do that.
Walking Into the Middle
This is, unfortunately, a more common experience that I would like.
Digital projects almost never start from a blank slate. Normally, someone already has some ideas about what should happen but they may not communicate that to you because it’s “common knowledge”. And if we take them at face value, we might end up building something completely off the mark.
I remember another time where I walked into the middle of a client’s political debate to switch from using Solidworks to Tekla Structures. I was told to write two proposals for two different programs because they wanted to understand the impact of switching programs.
To them, it made sense. Get the expert to vet the processes and then figure out which is the better option. But they wanted two proposals written up in a week without any additional meetings. They said “it’s all common sense”, so this should be easy.
But I am not apart of their processes, what may seem like common sense to them are assumptions and decisions that I don’t know. So, it was damn near impossible to come up with accurate requirements.
There’s always more than meets the eye
The better the work looks, the easier it seems. And the easier it seems, the more likely you will build the wrong thing.
“Just add this” is never just adding a feature. If something sounds too good to be true, we have to stop and assess whether there are any other hidden complexities behind it.
Of course, we won’t be able to predict everything but we can’t be too reductive about complexity. Especially, when we aren’t steep in their environment.
It takes two to build the right thing
I had another client who wanted a plugin in Tekla. The brief was was also clean, go from a quotation spreadsheet to a 3D model. And their instinct, like Marcus’s, was to fast track things. Give the fee, the timeline, approve it, and let me handle it.
After having learnt my lesson with Marcus, I reined it in and asked more questions.
It was uncomfortable because it seemed like I was skeptical but it was actually because they didn’t have a clear picture of what a Tekla plugin meant for their workflow. I was worried that they were developing their workflow and plugin at the same time, which is never a good idea. A good plugin needs to be embedded into a process not a new one.
After some pushing and prodding, we finally agreed to a discovery phase first. We went through the spreadsheet together. We explored what deployment would look like. We even checked if another program was a better fit.
And two things came out of that phase that we couldn’t have found on our own.
First, they were already working on a new version of the spreadsheet. If I’d built the plugin to the existing one, it would have broke within months.
Second, they had only one Tekla license, which meant only one person needed to run it. That cut the deployment complexity significantly because I didn’t have to worry about company wide IT policies yet.
We ended up waiting two more months to build the plugin. And, I’m glad that we did because it ended up being more stable and much closer to the workflow they wanted. The overall delivery was slower but it was more intentional and more valuable to everyone.
You want a discussion not instruction
The best tool or script isn’t one person building exactly what the other person asked for. If you want that, LLMs are getting really good at that.
It’s actually, two people figuring out what should actually be built given the situation and the problem.
That starts with a client who’s willing to share the context, not just the brief. And a digital person who’s willing to ask, not just build.
If you’re thinking about bringing computational design into a project, I’m happy to talk through how you’re framing the problem and if it’s the right solution.