Audio article narrated by OpenAI
The pattern I kept tracing across this conversation is one the AEC industry hasn’t yet named: the designer who applies product thinking without ever reaching for the vocabulary. Noushin Radnia, Manager of Design Technology at Hart Howerton, runs a technology function within a firm whose business model is qualitative, whose projects are irreducibly bespoke, and whose experienced designers still work in trace paper. She has built a more coherent product model than many people who hold the job title. What follows is a conversation about what product thinking actually looks like when the product is a human experience rather than a feature set, and when the market is a 60-year design legacy rather than an addressable segment.
About Noushin Radnia
Noushin Radnia is Manager of Design Technology at Hart Howerton, a certified B Corp interdisciplinary design firm specialising in luxury hospitality, resort, and master planning across 30+ countries. Originally trained as an architect in Iran, she holds dual master’s degrees in architecture and information technology from UNC Charlotte, as well as a master’s in interior and environmental design from Texas Tech. A creative technologist working at the intersection of architecture, computational design, and emerging media, she has an independent practice that spans cross-disciplinary collaborations with architects, artists, and musicians across exhibitions, installations, and museum contexts; her firm role is where those hypotheses are applied at scale.
—
“The most profound human experiences are biological: the way we blush, the way we get goosebumps, the sudden calmness of being able to breathe deeply. However far we push the technology, that remains the measure. It’s what we’re designing toward, not away from.” Noushin Radnia
—
When design thinking is product thinking, unnamed
There is a particular tension that arises when designers move into technology roles: they import the intellectual tools of design (empathy, iteration, prototyping) but rarely bring the vocabulary of product management along. The result is practitioners who do the work without claiming the frame.
Noushin is precise about the distinction. When asked whether her role at Hart Howerton amounts to a product mission statement, her answer is careful:
“Sometimes I think architecture, especially the design technology world, is very related to product management – the thinking, the approach, even the syllabus. And sometimes I’m like: no. I’ve come to see my role as redefining Product Management for complex, context-specific environments. In my world, the ‘product’ isn’t a standardised feature set; it is the augmented capacity of the designer. We aren’t rolling out one product for everyone; we are building a system that allows every project to be its own unique ‘start-up’.”
The “no” is revealing. It isn’t a rejection of product thinking; it’s a rejection of the assumption that product thinking means scalable, standardised, and metric-driven. At Hart Howerton, which has built a 60-year legacy in hospitality and resort design in some of the world’s most place-specific environments, efficiency is not the top metric. The firm measures success by the richness and qualitative satisfaction of the designed environment: a “day in the life of a place” rather than a delivery schedule.
This framing has a direct consequence for how Noushin thinks about technology. Every tool she introduces must fit into a design process that is intentionally non-repeatable. A workflow built for six designers on a single beach resort project may have no equivalent elsewhere in the firm. The point is not generalisation; it is bespoke fit. This is where her role diverges most sharply from the conventional product manager’s mandate and where the industry’s vocabulary begins to fail her.
The gap between naming and doing product thinking in AEC is not unique to Noushin. As I explored in an earlier piece on PM in AEC practice, the product manager role in AEC enterprises often suffers from an identity problem: “In a pure-software company everybody gets that; in an AEC enterprise nobody is quite sure what it is.” Noushin represents the inverse of that problem: someone who is quite sure what it is, and does it fluently, but has no particular interest in the label.
The bespoke ceiling: why scaling is the wrong instinct
The most contested question in AEC design technology is whether bespoke workflows should be scaled. The instinct is yes: if a tool works on one project, make it work on all of them. The reality, as the scalability illusion in computational design makes clear, is that the attempt to scale a workflow into a platform often destroys what made it valuable.
Noushin has arrived at the same conclusion through practice:
“Every workflow is so bespoke — you’re learning in this firm. Sixty years of working in the same domain doesn’t mean sixty years of the same solution. The typology is consistent; the place never is.”
This is not a complaint; it is a design constraint. The firm’s value proposition is that no two projects are alike, even within the same typology. A beach resort in Panama and a ski resort in Montana share a category but not a set of design priorities. View corridors dominate one; wind direction governs the other. Noushin tested the limits of parametric optimisation for massing early in her tenure and found that the variables shifted not just project by project but conversation by conversation:
“You are missing that actual human in the loop and the way they can prioritise it — and that can vary person by person, based on the latest article you have read or the magazine you have flipped through or the conversation you had with the client.”
Optimisation assumes a stable hierarchy of criteria. Experiential design assumes the hierarchy is negotiated fresh each time. These two assumptions are incompatible, and no amount of parametric tooling resolves the contradiction. The human-in-the-loop is not a limitation to be engineered around; it is the mechanism that makes the product worth having.
There is a deeper argument beneath the operational one. If a firm selling the irreducibility of place succeeded in fully standardising its process, it would produce the same optimised solution every time. That is precisely what a client paying for a resort shaped by its specific light, wind, and material context is not paying for. The homogenisation that results from successful standardisation is not a side effect to be managed; it is the product itself being destroyed. Bespoke is not a constraint the firm tolerates; it is the value the firm sells.
She is moving toward a central platform not as a means of standardising bespoke work, but as an aggregator that makes bespoke work accessible: a distribution point for scattered plugins and connectors, and a mechanism for harvesting insights from how tools are actually used. The platform doesn’t replace the bespoke; it holds it.
Word of mouth as the only adoption mechanism that works
Ask Noushin how tools spread through Hart Howerton, and she doesn’t describe a training programme or a top-down mandate. She describes a single mechanism: a successful project.
“The most successful factor — if you have it there even if it is a semi-working tool, it’s gonna take. The tools and workflows that have spread through our office have all been pollinated by word of mouth. Once one project uses it successfully — it doesn’t matter how difficult the integration is. You will just start hearing it: that team used it, and now this team wants it too.”
She identifies this as the ‘Golden Key’ to a Social Trust Loop – a deliberate adoption framework that prioritises peer-to-peer validation over documentation. Monthly workshops and training sessions run regularly, but they are maintenance, not drivers of adoption. Adoption happens when a tool succeeds in the field, and designers tell each other. Adoption in a high-stakes design environment isn’t a technical hurdle; it’s a trust hurdle,” Noushin explains.
This pattern is structurally consistent with what the broader AEC industry keeps rediscovering: top-down mandates for tool adoption routinely fail because the problem they’re solving isn’t a knowledge gap; it’s a trust gap. Industry data confirms this: a 2026 survey of more than 2,000 AEC professionals found that the biggest barrier to adopting new technology is not cost, which ranked fourth, but time: specifically, implementation and training taking too long. The second biggest barrier is the absence of a leadership mandate; that finding, read carefully, reveals the mechanism: when mandates exist without social proof, they address availability rather than trust. Architects and designers don’t adopt tools because they’re available or because someone ran a training session. They adopt tools because someone they respect used one on a real project and the project was better for it.
Noushin’s practical model for engineering that trust follows a precise product cadence, even if she doesn’t frame it that way: rapid prototyping of a point solution for an identified problem; a trusted group of users willing to test it; organic spread once results are visible; then deliberate scaling when the next wave arrives. The sequence is not accidental. It is the same logic that underlies early-adopter programmes in product development: the pathway from pilot to adoption runs through social proof, not documentation.
What makes this model coherent in her context is that Hart Howerton’s project structure provides a natural unit of validation. Each project is a contained experiment with clear outputs: client satisfaction, the richness of deliverables and whether the design team met all the criteria they needed to. A tool that helps a project team do that better becomes the recommendation for the next project. The firm’s bespoke culture, which might seem hostile to standardisation, is the very structure that enables this viral propagation of intelligence.
The analog-digital coexistence: advantage, not friction
One of the most counterintuitive observations Noushin offers is that Hart Howerton’s senior designers still work in trace paper and hand sketching, and she considers this an asset.
The conventional interpretation of a mixed-method firm is that it is transitioning: senior practitioners holding on to old workflows, junior designers pulling the firm forward. Noushin reframes this as a permanent and productive asymmetry:
“The analog part — the physical tangible part — has never been lost. While the broader industry may have moved toward purely digital workflows, I’m glad we maintained our focus on the hand-drawn.”
The practical mechanism she describes involves a designer named Owen and a principal named Michel. Owen is using AI-integrated rendering workflows; Michel is still directing vision from a designer’s instinct. While Owen jokingly describes himself as ‘Michel’s AI,’ Noushin views this role as a critical Human-AI Interface. In her framework, the technologist isn’t just running a tool; they are translating decades of spatial intuition into high-fidelity data. “We aren’t looking to replace the ‘Master Architect’ with a model,” she explains. “We are building the bridge that allows that deep expertise to steer the algorithm.”
That translation layer carries an unexpected feedback loop. One senior principal who began using AI tools that mimicked his hand-drawn marks discovered that precision mattered more, not less: the system was faithful enough that imprecision was amplified rather than corrected. The technology didn’t just serve his instinct; it sharpened it. The tool becomes a mirror before it becomes an amplifier.
This matters because it reframes the conversation about AI adoption. The question isn’t whether principals will adopt AI tools; it’s whether the firm can build a structure where their design intelligence is applied through people and tools who do. BIM 2.0, meaning web-based, file-format-agnostic access to models, is making this interoperability real without requiring everyone to change how they work. The principals or project managers who won’t open Revit can still review a design by accessing the model through a web interface. A project lead on a remote hospitality site can walk through the live model on an iPad without needing a workstation or a specific file format. The criterion that unifies these solutions is the same one Noushin applies to every tool she evaluates: Does the technology fade? A tool that forces designers to think about the tool displaces design thinking. The ones that succeed are the ones that disappear into the workflow. The friction disappears not because everyone converts but because the system becomes permeable.
This also has implications for what bespoke computational design tools can and cannot do. A workflow that is genuinely bespoke, built to match a team’s specific intelligence on a specific project, cannot be fully transferred to another context. What can travel is the structure that makes bespoke work legible: the central platform as aggregator, the translation layers between working modes, the review mechanisms that let design intelligence supervise without needing to operate every tool.
Measuring success beyond efficiency metrics
When Noushin describes how she knows a technology implementation has worked, she does not start with time saved. She starts with something more observational:
“It is this ambition and curiosity that you’re starting to see from the design team. The satisfaction of ‘it enabled me a new way of thinking or trying things I never thought I could try before.'”
The metrics she cites are qualitative: higher quality results delivered within the same time period; a broader range of deliverable types covered without sacrificing any; client satisfaction; and the number of media through which the firm can communicate the design. “Efficiency is our baseline, but Capability Expansion is our goal,” Noushin explains. “If we only use technology to do the same things faster, we’ve failed. We use it to attempt what was previously considered out of scope.”
This is a meaningful distinction. Efficiency metrics measure how much of the existing workflow can be automated. Expansion metrics measure whether the workflow itself has changed: whether designers are now attempting things they previously considered impossible or outside scope. The technology is succeeding not when it speeds up what was already being done, but when it changes what gets considered.
The distinction also explains why Noushin is selective about which AI tools qualify. General AI image generation produces what she describes as “believable but random” results: aesthetically plausible images whose geometry doesn’t correspond to an actual massing model, whose site scale is invented, and whose materials bear no relation to the specific location. For a firm working across 30 countries where the sight lines, wind patterns, and local material palette are the design, a convincing image that gets the architecture wrong is not an expansion of capability; it is a substitution of fiction for precision. The tools that pass her test are those that work from geometry outward, not from text inward.
Her example of AI rendering is instructive here. The historic method involved a gradual, controlled build-up of every material, texture, and light source; the designer maintained precision by accumulating detail layer by layer. AI rendering collapses that sequence. Because believable results arrive fast, designers begin thinking, in the concept phase rather than in execution, about details they previously deferred to later:
“You’re getting this direction of how that gutter needs to be built in this concept phase, because it showed up in that image. Those were not common objects to consider.”
The hierarchy of design attention has changed: decisions that previously existed in the execution domain are now being made during conception. AI rendering hasn’t just made rendering faster; it has pulled detail-level thinking earlier in the process. Whether firms are equipped to act on that shift, or simply absorb faster rendering into an unchanged workflow, is where the real adoption question lies.
The knowledge that resists capture
The conversation closes on the problem Noushin finds hardest: whether the design intelligence accumulated in a firm over sixty years can be preserved, transferred, or distilled.
Translating a design process into words or diagrams is already difficult. Translating the poetic quality of a place, the way light moves through a space, the sequence of sensory experiences that constitutes an environment, may be something else entirely:
“There is a poetic quality that is not necessarily experimental — you have to experience it to understand it. From sunset to what it is casting shadow on, to what is blowing against your face. It is a series of things creating that environment. I hope you don’t lose that.”
Technology, she argues, has democratised certain design skills by forcing their translation into communicable form: language, multimedia and process diagrams. If you cannot articulate your design logic, AI tools cannot reflect it back at you. The pressure to make thinking legible has a democratising effect: skills that were previously tacit and unteachable become partially transferable.
One mechanism that addresses the processual dimension, if not the poetic one, is what she calls the “digital trace”: the accumulated record of how a design moved from a first sketch through every iteration to a final render. The trace doesn’t capture the experience of light at a specific hour, or the sequence of sensory impressions that constitutes a place. But it does make the trajectory of decisions legible: a different kind of institutional memory, less concerned with preserving the answer than with preserving the reasoning that produced it.
What neither mechanism resolves is the deeper limit: the more the design intelligence approaches the experiential, non-linear, and irreducibly subjective, the more the translation fails. The manual can be replicated; the poetic sensibility is another matter entirely.
This sits at the edge of what any product system can hold. Joseph Tainter’s observation in The Collapse of Complex Societies that increased complexity carries increased costs per capita offers a structural warning here: the attempt to build systems that capture and transfer the full richness of design intelligence may cost more to maintain than the intelligence is worth to extract. The firm’s sixty years of design DNA may be best preserved not by documentation but by the conditions that allow the next generation of designers to develop it afresh, carrying it forward in directions the original practitioners could not have anticipated. The sensibility cannot be codified; it can only be cultivated. That is a different kind of technology problem entirely.
The method that precedes the name
What this conversation surfaces is not a new kind of product manager or a new model for design technology. It is something older: a practitioner who has learned, through the specific conditions of her environment, that the mechanisms of good product work (understanding users before building for them, measuring outcomes rather than outputs, letting adoption spread through trust rather than mandate) operate independently of the vocabulary used to describe them.
The instinct is to solve this by importing product management as a discipline: job titles, frameworks, OKRs, discovery cadences. That impulse is understandable. The risk is that the import is mistaken for the thing itself. What Noushin’s practice suggests is that the thing itself operates in firms with the right conditions: close collaboration between technologists and designers, a north star grounded in human experience, and enough respect for the bespoke to resist the pressure to standardise everything. The through-line is not a methodology but an awareness: the human experience as a reference point at every level, from which to test first, to how adoption spreads through a project team, to what counts as success when a design is done.
The vocabulary, when it arrives, will be useful. But the practice doesn’t wait for it.