Design Development and the WYSIWYG Trap, Part 3: LOD, and the current state of software UX modeling tools

Applications are digital spaces. What can the software industry learn from architecture and construction workflows? This is the end of a three-part article, so please start with Part 1.

Levels of development (LOD) and the model path

In the previous section we started exploring Autodesk’s toolchain based on a publicly available class presentation. The same presentation offers one more useful concept that can be translated to software, the “LOD” or Level of Development:

When you’re surveying stakeholders about whether your new internal app should even exist, you’re at LOD 000. When you’ve got wireframes or Sketch renderings of your new app, you’re at LOD 100. When your developers are actually compiling code, you’re at LOD 400. When your app is live, you’re at LOD 500.

This scale neatly illustrates the tooling gap. How do you manage the transition from LOD 200 to 300? Let’s take a look at what is Autodesk’s proposed app offering for the construction industry:

The icons are unlabeled and require some explanation. On the left there’s Google SketchUp — a convenient tool for 3D architectural sketching, but one that doesn’t produce construction-ready models. (You can mentally substitute Sketch here with minimal effort; it even has almost the same name.)

The middle one is Autodesk FormIt. It’s described as a “BIM-powered architectural modeling software” that “enables architects to sketch, collaborate, analyze, and share early-stage design concepts.”

The rightmost one is Autodesk Revit. This software is the core of Autodesk’s BIM workflow. It has tools for architects, structural engineers, MEP engineers, and construction professionals. It’s the information hub where everyone working on design development meets.

Together FormIt and Revit cover the LOD 100–300 range, allowing you to move from a roughly “LOD 100” SketchUp design up to something like a “LOD 150” FormIt model, then bring that into Revit for LOD 200–300 work.

Here’s a comparison of the different levels of development. A conceptual sketch is on the left, and the two images on the right are from design development stages through FormIt and Revit:

The FormIt model (top right) is roughly blocked and focuses on functional units. Note the complete lack of finished form. In software terms, this is like a UI wireframe — but with one very important exception: it’s a model rather than a drawing.

It’s hard to overemphasize just how much the lack of models hurts today’s software development process. When your design documents are either drawings or code with nothing in between, there’s no automatic path for transitioning between different LODs (levels of development). Digital models solve this problem for the construction industry, and they could do the same for software if we choose.

The Autodesk class presentation makes one important point about this model transitioning path:

“Garbage in is still garbage out.”

If we want to have smart LOD-aware tooling for software development, we need to accept that it will take more rigor than exists in today’s Sketch-made UI designs. If you’re a conceptual designer, you can’t send an unannotated stack of vector graphics layers to the next guy and expect to somehow get working code at the end. Design systems and component hierarchies are going to be key to avoiding this kind of “garbage in” process clog. The new tooling for software design will need to understand and integrate these design systems at every step, just like Autodesk’s BIM applications share common model libraries.

Current state of design development / AIM tools

By now you’ve noticed that this article has a refrain: “We need new tools”. Where is the software industry currently on this? This topic is large enough to warrant an article of its own which I’m going to write next. The short summary is this: unfortunately, despite some great efforts by brilliant people over the past forty years, we’ve made almost no progress in getting this kind of tooling into active use within the industry.

In the 1980–2018 timeframe, the construction industry’s software solutions have advanced from early drafting-oriented CAD tools (like the original AutoCAD) towards the comprehensive BIM vision represented by Revit and the suite of applications around it. Digital models are being used at every stage of development. Meanwhile software developers are still debating ancient 1970s tropes like “Vim or Emacs — which is the better text editor?” or “dynamic or statically typed languages?”, and designers are stuck working in tools based on pen-and-paper metaphors (Illustrator/Sketch) that have no modeling path.

I spent years working on Neonto’s design development tool suite which you can try for yourself as React Studio (free but macOS only). If you’ve heard of Framer X, you know most of what React Studio is about. Rather than shill for the product, I’d like to discuss a key failing of our approach that needs to be better addressed if React Studio — or any other app — is going to be a viable tool for the “Application Information Management” space.

Traditionally there are two major problems with visually oriented development tools. The first is the “walled garden” lock-in effect. GUI apps that model software concepts tend to be always deeply coupled with a specific development environment and runtime framework. There are several successful companies that sell such tools to the enterprise market. (Analyst firm Gartner calls this category “low-code / no-code”.)

Practically everyone in this market forces strict lock-in. You bought a “low-code PaaS” system from Enterprise Vendor X and they happen to use Angular.js deployed on their own cloud servers? Two years later, if you want to convert those apps to React managed by your own developers, good luck… That’s the walled garden. At Neonto we actually solved this with the Design Compiler approach. In fact, React Studio is just one expression of a modeling suite that also has targets for many other languages and platforms (e.g. iOS+Obj-C and Android+Java). That fixes one major problem — at least from the point of view of an enterprise buyer — but leaves another failing that makes adoption of these tools difficult.

This second problem can be described as “the WYSIWYG trap”.

What You See Is What You Get is an acronym that has long been held as a gold standard of digital editing tools. Among the “low-code / no-code” vendors, everybody has been trying to make these software modeling tools look and feel like graphic design tools so that the user (i.e. the “design developer”) could manipulate display objects that look exactly like the finished application as the eventual end user will see it.

That’s probably the wrong paradigm. Look at this screenshot of Autodesk Revit:

This is not “WYSIWYG”. The structural 3D view shows abstracted internal detail — it’s not a rendering of the building as the eventual end user will see it. If a Revit user wants to render a high-fidelity photorealistic visualization of the building, it’s of course possible, but the primary working interface doesn’t operate on photorealistic elements.

My own work on React Studio had a serious flaw: the product’s UI ended up in an uncomfortable place somewhere between full WYSIWYG and what I’d call “exposed” modeling à la Revit. The software looks close enough to Photoshop/Sketch that graphic designers expect they can pick it up and start working immediately. But that’s not the case — there’s a number of abstract concepts related to UX modeling and dynamic data that you need to understand before you can get full use of React Studio. This situation is not that different from architectural software. Take a 3D artist with experience making animation character sketches and sit them in front of Revit — I guarantee they won’t have any idea what to do, even though it’s still nominally “3D modeling”. Nobody expects an animator to become a construction design expert immediately, yet in the software industry there’s quite a lot of people who assume that a graphic design background is sufficient qualification to design software experiences or what I call “digital spaces”.

Another problem with the superficial, misleading ease of WYSIWYG is that it hides the importance of getting everybody on your team on board with “Application Information Management” thinking, i.e. the software equivalent of BIM. What you’re doing in a wannabe-AIM tool like React Studio is in fact Design Development work. It’s a new stage of the development process and needs to be supported by a workflow where your conceptual designers and developers are also on board. (Remember “Garbage in, garbage out” in the Autodesk slides earlier? That applies perfectly to the issues I’ve seen where users tried to make use of React Studio’s Sketch importer on non-structured designs.)

So what can be done? Realistically, backing out of the “WYSIWYG trap” is not something that can be immediately solved at this point for React Studio. It’s already a free product built by a team with no money, whereas competitors like Framer have tens of millions in venture capital to spend on development and marketing. (Remember that VCs always come in with the expectation of 10x-100x returns for their money. A VC-funded company isn’t going to get that big simply by selling $99 software licenses. The real game for Framer and others is in creating a walled garden: to lock you into their software frameworks so that your work can be increasingly monetized later.)

Probably the best step for React Studio would be to go fully open source and adopt a community-driven development model. I’m envisioning that React Studio could eventually become the “Blender of UX design”. If you’re not familiar with Blender, it’s an open source 3D modeling package that offers impressive competition to commercial apps like Autodesk’s Maya. It took quite a long time for Blender to get there, but the community model is truly paying off now. Long-standing issues with Blender’s complex UI have been alleviated, and new features are created in response to community needs faster than a commercial company could do it. That seems like the best possible future for React Studio, a product whose “no lock-in” philosophy was always fundamentally incompatible with commercialization anyway. (If you have an opinion on this proposal, I’d love to hear it — sound away in the comments!)

Thanks for reading all this way. I know your time is valuable, so I hope you found some kind of worthwhile takeaway here. If there’s anything you’d like to see further expanded or discussed from a different angle, I’m always happy to take ideas for a follow-up article.