On communicating design
A "research" project exploring the line between the "why" and "how" for digital product design
Over the latter half of the past year, I've been thinking a lot about the discipline of design—specifically, digital product design. As conversations about design systems and "no-code" tools have matured, new questions have emerged from the discourse. Why do we focus so much on the distinction between "design" and "code"? What is the line that divides these two, and why does it exist?
Having been designing for quite some time, and about to wrap up my computer science degree at UCLA, I've always questioned why we've drawn the line where the text-editor starts.
On the surface, it seems clear that design and engineering are simply two separate disciplines. You wouldn't have the chefs of a restaurant taking everybody's orders, and you wouldn't have the waiters cooking up meals.
However, software is a unique case. As software is simply a medium, and not the service itself, the roles of design and engineering in software are abstracted to a more indirect level of responsibility. Design is primarily revolved around the constraints of people, while engineering primarily looks at the constraints of computers and computation.
It goes without saying that for different types of products, these responsibilities manifest in vastly different ways. Designing a social network requires asking very different questions than designing an open-source framework.
The two functions of design and code are just two sides of the same coin, both needed to build any software. Replace "code" with "engineering" and you have the two disciplines that behind any product—the "why" and the "how".
Therefore, it would make sense that design "ends" where decisions being made no longer influence the end-user. Why should a designer have to worry about a database schema? Conversely, why should an engineer worry about the copy used to explain a product's feature?
Realistically though, the line that separates the two is quite difficult to pinpoint. On the visual level, the designer's decisions of composition, color, and typography require engineers to implement repeatable patterns to scale properly. Engineering decisions of component hierarchy require designers to know which patterns to re-use when iterating on solutions. Discussion in the industry has come around to this mutual understanding in what seems like the first (almost) universally-accepted joint responsibilities of design and engineering—design systems.
One constraint that design systems have had since their fruition was the ability to communicate them. Often times, the "blame" for this often falls on the tools available. Why do I need to maintain representations of the same component over and over again, when copy is the only changing variable? How do I indicate that acting on a component redirects conditionally, given whether a previous action has already been completed?
Looking at the history our tools, most of digital product design tooling is derived from graphic design. We use the linear system of layers for representing presentation priority, draw rectangles with absolutely defined units, and use eye-dropper tools to match colors between objects.
Yet, we all know that the systems we define and the experiences we craft in the products we make are more complex than the arrays of screens we put together in these tools. "Invisible" concepts like state machines and the passing of time are unable to be communicated, without vague, hacky solutions.
The communication of digital product design decisions has been inherently constrained by their visual representation.
photo credits to @markdalgleish
There have been tools that attempt to circumvent this, the most well known being "prototyping". However, these tools often build on top of a visual paradigm, adding complexity on top of decisions that were made in a previous fidelity level. Would it not make more sense to define interaction parallel to their conception in the design process, rather than after?
So, here I ask the question I've been thinking about for around six months now:
Could there be a better process/tool/framework/something for designing and communicating interaction, independent of visual design?
Within this question itself, there lies several assumptions and further questions. Should design systems consist of interaction patterns to start with? Does it make sense to communicate design without visual representation, and if so, in what scenarios?
I've been endlessly curious about this topic, and so for the next six months (minimum!) I will be diving deep, researching this problem and writing about my findings. Regardless of whether I find a "solution", the goal of this project is to consolidate thought on this topic, so that perhaps myself or some other person may find it useful in the future. After all, with six months of college left, I figure this is a good opportunity to take on a project of unknown uncertainty and depth.
It would be ignorant of me to not mention currently existing thought in this area, with folks like Kevin Lynagh, Ryan Lucas, and Bryn Jackson having started many conversations about design representation. Furthermore, there is the entire world of interaction design academia that has most definitely approached this problem or its derivatives in some form. Ideally, through this project, I hope to identify relevant academic literature, surface these prior conversations, and ideally spark discourse for the role of design in 2020. If you'd like to stay updated on my journey, enter your email below and you'll get the next update in this journey as I document it!
Special thanks to Parker Henderson for helping me formulate my thoughts and encouraging me to get this started!