Design Development and the WYSIWYG Trap, Part 1

Applications are digital spaces. What can the software industry learn from architecture and construction workflows? This is the start of a three-part article that dives deep into existing and proposed software solutions.

Last year I wrote about how vector graphics drawing programs like Sketch are too limited to describe software UX concepts because they’re designed around an antiquated “pen-on-paper” metaphor. In this post, I’d like to explore other modeling approaches using comparisons with the world of physical construction and architecture.

Essentially, today’s applications are digital spaces for people. A person enters the space with a purpose in mind. Within the space they interact with fixed elements of the space, as well as with other people who may or may not have a shared purpose for using the space. Just like architects, software designers must be conscious of how people of different abilities and experience levels can operate and feel comfortable within the spaces they create.

Architects and construction professionals have literally millennia of experience in figuring out how a constellation of professionals can work together to create physical spaces. They have also been at the forefront of adopting digital workflow methods through CAD (computer-aided design) and BIM (building information management). There’s a lot that we can learn from this industry.

This approach is not without danger, as analogies are a slippery kind of mental tool. They can be both supremely enlightening and supremely misleading, and that boundary can easily become blurred once your thinking has been anchored by a metaphor. In this case, I feel that the analogy to architecture is useful and justified due to the spatial nature of modern software.

There’s one huge difference that needs to be acknowledged upfront to make the analogy work. In physical architecture, construction is usually much more expensive and labor-intensive than design. In software, the construction phase is essentially free and requires no labor. I’ll explain this in more detail shortly.

The intersection of analog and digital design is close to my heart. My mother is an architect, and my father was in the enterprise software business. When I was around seven years old (circa 1987), my mother would often take me to the studio where she worked. I got to admire rows of drafting tables with huge sheets of paper, intricate balsa wood models, and other artifacts of advanced design craft. In one corner stood the first herald of an impending digital revolution, a brand new AutoCAD station; everywhere a quiet concentration filled the air.

On the other side of town, my dad’s office was the opposite. Deep inside a corporate building, tall IBM mainframe tape decks whirred and clanked in rooms filled with heat and noise. In the trunk of his car, my dad would sometimes bring work home in the form of big stacks of matrix-printed hardcopies of COBOL code. (The old-school version of today’s “git pull” command!)

At the time it certainly would have seemed that those dense pages of all-caps COBOL code don’t have a lot in common with the floor plans intricately penciled on delicate sketching paper that were produced at the studio where my mom worked. Yet over the years a convergence has emerged, and it centers around what I call “digital spaces” — although most people would file it under “user experience” or UX.

There’s a certain fog of confusion that surrounds the role of UX design in relation to other software creation tasks. Are UX designers the same as product designers? (Nick Finck thinks so, and has a good point.) What’s an interaction designer — maybe someone who creates delightful animations triggered by interactions? (Alan Cooper would absolutely disagree.) What do you call a graphic designer who works on user interfaces? Should designers code? Should UX designers code HTML? Should front-end developers design interfaces? Should web component developers contribute to design systems? Should back-end developers design brand guidelines? Ok, on that last question, everyone agrees that the answer is a resounding “no” — but the others are honest questions asked by real people trying to make sense of how to best organize their work. This reveals that we’re a young industry still struggling to discover how to reliably repeat its successes.

There’s a lot of names and tacked-on ambitions for what I’d call the “conceptual designer” — but others would call a product designer, UX designer, or interaction designer depending who you ask —that is, the design professional who gets engaged first onto a software project and who primarily interacts with users and stakeholders throughout the process. This is obviously a very important role, but it’s still only a small part of the labor that must actually go into designing software that works and makes sense. For the rest of the roles involved, we mostly don’t even know what to call them.

One obstacle is the stubborn old assumption that creating software divides into two parts called “design” and “development”. This hard dichotomy limits our understanding of the process, and in the past has reduced it to a caricature where someone labeled “designer” draws pictures of the imagined software and hands them over to someone else labeled “developer”. Everybody recognizes that to be a horribly information-starved and inaccurate way to transfer design intent; yet most solutions so far have focused on improving that so-called “handoff” experience by adding annotations and animations to those pictures, or extracting near-homeopathic amounts of developer-ready information from design files. But no amount of tinkering with handoff utilities can fix fundamental process failures. We need to add new, better delineated responsibilities and to educate old or new team members to take on roles that are currently missing — and we need new tools to help with that.

Architectural design workflows have all this worked out already. Exploring their solutions through properly calibrated analogies allows us to reflect proposed new processes against an established industry that already has a $50 billion software tool market to support it. Software companies like Autodesk have solved these processes for other design industries. The time is nigh for the software industry to finally be the shoemaker who lets his kids wear shoes too.

How buildings are made

Getting software made can be like trying to budget witchcraft: just ask the enterprise CEOs who spend billions each year on corporate IT projects that end in failure. Physical construction projects also suffer budget overruns and disappointing outcomes, but rare is the $10M office building that collapses like a sandcastle before it’s even completed. Yet in software, that’s a regular occurrence. How do architects and constructors turn ideas into buildings without such risks?

We don’t need to guess because the construction industry publishes guidelines that outline the workflow that everyone in the field agrees to follow. (As a software practitioner, that already sounds pretty incredible. When was the last time software people agreed on anything?)

“The CSI Project Delivery Practice Guide” is a practical guide to the construction professional. It’s created by The American Construction Specifications Institute (CSI); other countries have their own practices, but the CSI guide will work great as a baseline for us. If you check out the table of contents linked above, you’ll find it fairly understandable to the layperson. Specifically chapters 8 to 11 have direct analogies to software.

We find the following phases defined therein:

• Design Concept
• Schematic Design
• Design Development
• Product Selection and Evaluation
• Construction Documents
• Procurement
• Construction

For a great readable overview of what these phases mean, we’ll turn to Moss Design, a Chicago-based architecture studio: they provide a super-clear outline of the architect’s process on their website.

The crucial ones to understand are Schematic Design, Design Development and Construction Documents. Go ahead and read those, I’ll wait… And when you come back, we’ll work backwards from construction to schematics to see how it applies to software.

Please join me in Part 2 for that!

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 356,974+ people.

Subscribe to receive our top stories here.