Your R&D doesn’t need to be flashy

Some of the most impactful engineering breakthroughs likely make for very boring marketing demos.

Over several decades spent leading development teams, I have seen firsthand how tempting it is to focus engineering efforts on highly visible, flashy new features. I’ve known many developers who get bogged down by the pressure to package every software update with a supremely marketable new element or two that’ll get people talking.

But in my experience, the features that most enhance a user interface are often completely invisible to users.

Performance, reliability and security are not the sexiest features, but they’re crucial elements to a satisfactory user experience. That’s especially true when you’re engineering for users working within complex vertical industries – such as architecture – who count on simple, dependable technology to bring their daily work to life as seamlessly as possible.

My foundational philosophy is that the absolute best software is the kind you can dig into without ever needing to pick up the user manual. Users shouldn’t have to spend valuable time fighting to navigate complex menus, acting as manual data routers who must convert one format to another just to connect the dots. When professionals can focus on using their tool as solely a means to an end rather than a puzzle they have to solve, that is when you know you have done your job well as a developer.

The unsung heroes of successful software: Speed, reliability and security

R&D teams often must fight to justify investing in foundational software improvements because they simply aren’t as visually marketable as shiny new capabilities. But performance is a hidden expectation that great developers cannot afford to ignore.

As a Chief Technology Officer guiding design software development for AEC professionals, I’ve learned modern users have incredibly high standards for speed. This is especially true for younger users just entering the workforce. If they have to wait more than a few seconds for their tool to function as directed, it will come at a cost to their sustained attention and workflow.

Reliability is also paramount for modern tech professionals, particularly as we integrate more automation and artificial intelligence into our workflows. When we implement automation to handle boring, repetitive tasks, our users need to know that the system is worthy of their rock-solid trust and can execute those tasks flawlessly.

To use an example relevant to my market, imagine you’re an architect designing a highly complex, multi-million-dollar project for a new hospital with thousands of rooms. You’re collaborating with dozens of other engineers from multiple disciplines, both structural and electrical, and all of you are working on the same model. If you direct the software to automatically update the wall weights across all the bathrooms in the entire hospital, you’re investing your absolute trust in that software accomplishing the task exactly right without interfering with other modeling being done simultaneously.

If the program is unsuccessful or hinders other parts of the project, the user loses trust in the software and the greater team loses trust in the user. That kind of trust is hard to build back.

And if the mistake is not addressed quickly, it could prove costly – potentially pouring significant additional spend into the project budget and contributing to the $2.1 trillion in project cost overruns that occur globally each year. What starts as a simple glitch in software performance can end with significant damage, the kind that could prevent users from ever going back to that tool.

For a similar reason, security is another pivotal foundational element developers must prioritize. In fact, data protection must be prioritized above all else – especially in fields like architecture where you’re dealing with a lot of precious intellectual property. A software user could not care less if an incredible new, time-saving feature is unveiled if, simultaneously, the software environment isn’t secure and their files are vulnerable to corruption.

Developers must focus primarily on protecting the complex digital assets and sensitive information handled with their software. To bring back our hypothetical architect, imagine a project to upgrade a government intelligence facility, with building floor plans that reveal the locations of secure rooms, surveillance locations, emergency exits and other privileged intel that, if put into the wrong hands, could jeopardize the safety of those working on-site.

Ensuring data is never lost, providing redundant storage and keeping sensitive information safe is our absolute baseline responsibility to users. While we might only briefly mention security enhancements in marketing collateral, it is a continual investment in a secure, reliable environment that keeps good software good.

Learning when what glitters isn’t gold

To measure the true return on investment for our R&D efforts here at Graphisoft, we rely heavily on product telemetry to see what users actually engage with. We recently introduced a brand-new, AI-ready data platform that allows us to analyze anonymized usage logs to see exactly which functions are being used and which are being ignored. This data is essential because if the product team convinces us to build something they believe is vital, we can calculate the development cost and then track if it delivers real value to our users.

A while ago, we unveiled a highly visual, flashy tool for our BIM software platform, Archicad, called the AI Visualizer. We were really proud of this tool. Essentially, users could start with a basic drawing or photo of random objects, such as a stack of boxes on a desk. They could then ask the AI Visualizer to create a skin based on the image or drawing, and the software would generate a high-tech office building or a beautiful wooden structure mimicking those shapes. It was an incredibly enjoying tool for creative work at the very beginning of a conceptual design phase.

Based on our continuous usage data analysis, we determined changes were necessary to retain long-term interest in the AI Visualizer – prioritizing enhancements that advanced open standards and seamless collaboration, rather than focusing too heavily on flashy UI additions. The biggest frustration they face is a lack of multidirectional collaboration capabilities and the tedious manual work required to transfer data between closed systems. So, in response, our team homed in on an open, cloud-agnostic environment where our users never feel trapped or dependent on a single provider.

Openness isn’t a flashy UI button, but allowing users to seamlessly connect their dots, export to any format and integrate with any technology is a massive differentiator for user satisfaction.

As a developer, you want users to choose your software every day because it is excellent – not because you have them locked into a closed ecosystem.

The future of intent-based software

I believe we are currently experiencing a paradigm shift away from traditional, click-heavy interfaces and toward what we call “intent-based design” that allows architects and engineers to specify a destination and letting the software itself figure out how to get there.

Across most vertical industries, R&D teams are building toward an AI-native nervous system that digitalizes common knowledge, allowing software to continuously learn and execute tasks based on a massive internal knowledge graph. This trend will contribute to increased intent-based design – and I believe that even in the near future, the user manual will become obsolete.

Rather than having to manually execute against each step in the engineering process, intent-based workflows allow a user to convey a vision and prompt the software to bring it to life based on the low-level functions and knowledge already built into its system. In architecture, for example, that means prompting your BIM modeling software to design a house within the specific parameters of Frank Lloyd Wright’s architectural style, rather than manually guiding it through each of those individual parameters yourself.

An argument for “boring” R&D

My ultimate goal is for our software to act as a quiet partner to great work. I think about it the same way as working with a great human colleague who you don’t have to over-explain every tiny detail to; instead, they understand where you’re headed as soon as you’re halfway there, understanding you in half the words and getting to work in half the time.

I want our software to behave the same way with, for example, intuitively predicting a user’s next step, seamlessly guiding them through new features without requiring any training. Our goal is to handle boring, repetitive tasks so users can remain fully immersed in their creative flow. With that we can provide immense value while demanding minimal attention, prioritizing what’s functional over what’s flashy.

When it comes to R&D, the sexy new features might get people in the door, but it is the invisible strength, the relentless reliability and the quiet partnership of the software that will keep them loyal.