Canvas-based engineering
A practical approach to collaboration and documentation
As a system architect for a contract manufacturer, I help customers design their products such that they can actually be made. Our customers range from university start-ups to multinational OEMs, while the products we manufacture are usually mechatronical products like machines or modules for the semiconductor, scientific or aerospace industry.
Collaborating with such a large variety of customers, I see (and have to deal with) a multitude of product development and systems engineering methodologies. Recently, I realized there is a pattern that everybody — from managers to mechanical, electrical, or software engineers — tends to naturally fall back on in times of crisis.
This article describes this natural tendency, suggests embracing it from the start of development, and provides a practical guide to integrating it into the way of working.
Product development
All product development or systems engineering essentially consists of just two activities:
- Work → Any solo activity
- Communication → One-to-one or one-to-many
This is an extreme simplification, yet it holds even across domains. If more than one person is needed to develop a product or system, there must be some division of labor. On the interface of those divisions, communication is needed.
Note that the results or deliverables of work is extremely broad. It is really the collective activities of product development, ranging from spreadsheets with budgets to lines of code, finite element analysis, 3D CAD drawings, etc.
The common problem
Depending on the preferred methodology of the company, all work is done according to some defined way of working. Usually, this is based on the V-model framework, but waterfall approaches or even “just winging it” are used (yes, even in huge companies).
Regardless of methodology, the basic pattern is just the following flow many times over, both in series and parallel.
In the early phase of product development, work usually consists of trying to understand the customer and shaping the project (technical requirements, product breakdown, division of labor, budget allocations, etc). Later on, work is usually more defined and may consist of designing a particular hardware or software module with given constraints and functional needs.
Now, the common problem is that both objectives and work are often communicated poorly, leading to misunderstanding, irrespective of the quality of the work itself.
To understand why this happens, it is useful to realize that there are two roles in this flow: the creator and the viewer. In other words: requirements are the result of someone else’s work. The next sections should therefore be read as two perspectives of the same activity: communication.
Objectives & requirements
In my experience, requirements are usually either too short or too long. Some “requirement providers” (e.g. customers, colleagues or managers) appear to assume mind-reading abilities of the receiving party. In these cases, requirements tend to be vague and incomplete. The receiving party may resort to assumptions, only to realize later that it was not exactly what was meant.
This does however work reasonably if all parties know and trust each other. It may only take some additional design iterations to get there. However, as time goes by, when the team grows or changes members, the original instruction is forgotten and never documented. As a result, tracability is non-existent and the product becomes unmaintainable.
On the other end of the spectrum, there is an instruction overload. Endless Word documents with jungles of text, giant tables and tiny low-resolution images. Even when done “right”, the rapid-changing nature of product development guarantees a permanent burden of playing catch-up.
Attempts to formalize phrasing, using templates or even relational databases are sold to managers as a ‘solution’. Unfortunately, this is not true. The fundamental flaw is the assumption that requirements must be captured in words.
The irony of engineering companies who enforce such “text-first” methods, is that they often end up with the former situation. Anything that is written down, is generally bloated, out-dated and not rapidly understandable for anyone except to those who wrote it. As a result, the real objectives are not understood by the receiving party because they are unpresentable.
Not rapidly understandable content is unpresentable
Off course, the advent of model-based systems engineering and its software tools are slowly becoming more mainstream, but the legacy of the printing press and its modern equivalent is still prevalent in most companies.
Work & documentation
What exactly entails work? This is a super abstract and broad question. It helps to make a separation of three sub-activities: production, presentation and documentation.
Here, production could be Python code, 3D CAD models, a set of requirements for someone else to interpret or anything the project needs. Since the end result of work is so broad, the question to ask is:
Is the work (self-)presentable?
And here we touch upon the other perspective of the same activity as stated earlier: communication. In teams, and in particular multidisciplinary teams, cross-domain communication is essential to work together effectively. There is always a critical-path dependency that requires exchange of information.
I’ve seen countless of times where team members or managers assumed similar mind-reading abilities, and people just did not understand each other. In almost all cases, they were not showing presentable information but instead just showed their production directly.
The common problem is that production by itself is almost never self-presentable. Just look at someone else’s spreadsheet, code or complicated CAD assembly. If you did not make it, it is much harder to understand without any context or explanation. Ironically, even most documentation is not presentable. Yet, most companies insist on those endless Word documents.
The natural tendency
Ever had a crash-meeting? Something critical happened that needed immediate attention and action. Prototype exploded, production halted, angry customer, retreating investors, etc. Everyone is affected by it, and solutions are sought in all domains.
Schedules are cleared. The team is gathered in a room. What now?
While that email with the bad news is still shown on screen, someone gets up and walks towards the whiteboard in the room and starts scribbling.
“Alright everyone, how the heck are we gonna approach this?”
Almost three hours later, an action plan is ready. While some people get up to take photos of the scribbles on the whiteboard, others sit back down looking at what was written down — everyone knows what needs to be done.
“OK. I think that’s it. Thanks everyone. We’re not out the woods yet, but we got a plan. Let’s get to it!”
What just happened? The urgency of the external event combined with the magnitude of the problem forces the team into a session where immediate and efficient cross-domain communication is needed. In order to get everyone up to speed quickly and work together towards a solution, a common and universal “language” is needed that everyone already speaks.
The natural tendency is to resort to simple means: pen and paper, a flip-over or whiteboard and markers.
I wondered why we only resort to such efficient means of communication in times of crises. Why not all the time? And can this somehow be formalized?
Consequently, I’ve been gradually integrating what I call “canvas-based engineering” into the regular way of working with my teams and some customers. It provides a lighter, more accessible alternative to MBSE, or can be used complimentarily.
It’s proven quite succesful, which is why I wanted to share it with a wider audience.
Canvas-based engineering
The main gist of canvas-based engineering is to only communicate via prepared or live-generated canves to ensure a single source of shared truth. Use diagrams, pictures and visualizations generously, but text sparingly. Keep the contents complete but neat. Prevent ambiguities and direct the viewer to minimize their effort. Maintain a simple structure and ensure traceability to the work while using proper versioning.
Ok, I’m just going to coin it: Canves (/canveez/) is a better word than canvasses.
There are three main aspects that make up canvas-based engineering, each with properties that are explained in more detail in the next sections. When done right, the canves become presentation and documentation in one:
Content
→ Use diagrams, pictures and visual abstractions, assisted by few words
→ Free-form for experts, use wireframe templates otherwise
→ Use visual cues to direct and guide the viewer: minimize their effort
→ Present unambiguous and complete information. Omit irrelevance
→ Every element must contribute. Scale and crop appropriately
→ Arrange contents neatly and uncluttered using ample space
→ Use clickable elements to other content and auxiliary information
→ Place comments, issues and decisions directly onto the canves as “post-its”
Structure
→ Use fixed-size canves in landscape orientation with white background
→ Ensure a single source of information (access-controlled repositories)
→ Maintain a logical order, e.g. similar to a product breakdown structure
→ Keep hierarchy as flat and simple as possible, prevent deeply nested canves
→ Use short, descriptive and precise canvas titles (like Wikipedia articles)
→ A thumbnail canvas is a good visual element to orient, navigate and refer
→ Keep work and canves together in one place or create permanent links
Usage
→ Meetings are primarily done keynote/cinema style, looking at a canvas
→ Pragmatically switch back-and-forth to show work or otherwise if needed
→ Comments, decisions, changes, etc are added live as much as possible
→ Each canvas or deck therof has one owner with sole writing rights
→ The canves must be easily retrievable and searchable
→ Use suitable software tooling to create, view and maintain the canves
→ Adopt good versioning systems and best practices
Content
The contents are essentially free-form, but this often induces blank page syndrome. Therefore, it helps to use or create a wireframe template before committing to the actual content.
So what to put onto the canvas? One way to look at the process, is like a highly compressed zip-file. You can easily spend 100 hours on something that requires just a single canvas to explain back to the team once you get it. And that is totally fine. In fact: you are the compression algorithm. Collaboration is all about explaining your contribution such that others can build theirs upon yours and vice versa. The more efficient this is done, the more time to build and contribute.
Use diagrams, pictures and abstractions generously. Screenshots are perfectly fine and so are pictures, but make sure to crop and label them wisely. There is nothing wrong with text, but use words sparingly. Diagrams are extremely powerful, and this article is too short to explain the full benefits. An excellent resource for system architecting diagrams can be found here.
Another aim is to direct the viewers eyes. This can be done using numerous visual techniques like contrast, colors, arrows or detail bubbles. A bad and good example of a simple objective are shown below. This example seems trivial, but it happens all the time that the viewer has no idea where to look.
Also, make sure to guide the viewer, which means to take them by the hand into the storyline. Think of how you are guided in a cartoon, or how you would explain something to an interested 10-year-old. This seems silly, but it’s the fastest way to bridge the knowledge gap between creator and viewer.
Strive for at-a-glance clarity
As I’m writing this section, I realize that it really deserves its own article. For now, I will leave you with the following goal: Strive for at-a-glance clarity, i.e. unambiguous and immediately apparent: don’t create a Where’s Waldo. In a future in-depth article, I can provide more examples to clarify.
Structure
The canvas itself works best as a fixed-size landscape orientation with white background because this is the overwhelming standard orientation of monitors, and thus allows for full-screen presentation. It also captures the viewers focus effectively by offering content one finite frame at a time.
More often than not, the information does not fit onto just one finite-size canvas. It seems tempting for the creator to use an infinite-size canvas. Unfortunately, our brain can’t grasp this format at-a-glance. We are much better at storing and processing fixed-size images. This is why we easily remember thousands of pictures or memes with intricate details, but get lost in fractals or Prezi.
The goal is good orientability. A thumbnail of another slide works well because our brain stores fixed-size images so well. The viewer can easily orient themselves relative to the bigger picture with just a thumbnail one or two higher “level” canves. Alternatively, diagrams of the canvas structure are used.
It is best to create a deck of canves on the same subject, and just click through one canvas at a time using a listed order or just a “next” link. It also helps to add links to go back to higher level(s) for very complex topics where sometimes going back-and-forth is needed to grasp the full situation.
The hierarchy must be as simple as possible. Sometimes I see companies create deeply nested directories and files in an attempt to “create structure”. This achieves nothing, except for productivity reduction because information is diluted and retrievability suffers. If Wikipedia can manage a flat structure for all human knowledge, then surely it is possible to maintain a shallow structure for your project.
Strive for low-order retrievability of information
I like Adam Savage’s first-order retrievability approach to tools, which I think can be applied to information just as well. Although first-order might be unpractical, it is definitely wise to strive for low-order retrievability. This is achieved by proper naming and making everything clickable that needs to be.
Finally, it is crucial to maintain a single source of information and have just one owner with sole writing rights at any given time. If there are multiple files (“truths”), tracability is lost and confusion ensues very quickly. The same result happens if someone other than the owner edits a canvas. Moreover, this may break trust of ownership which is highly damaging to the team vibe.
If one insists on changes, an option is to leave contrasting (signed) “post-it” notes to add remarks, questions or comments directly onto the canvas.
Usage
The key is to communicate primarily via formalized visually-oriented canves rather than via the work or entirely verbal. This ensures a shared truth, captured in a universal, rapidly digestable “language” and prevents most sources of miscommunication. For reference, the fundamentals behind communication is beautifully captured in a landmark thesis called A mathematical theory of communciation by C.E. Shannon.
During a communication event (i.e. meetings), everyone is thus always seeing a (digital) canvas that is either prepared by the owner or live-generated during the meeting. A physical whiteboard or flip-over is fine to use, but it is the canvas owner’s responsibility also to capture whatever was generated into digital form according to a formalized data structure.
Usually, there is one person presenting, and the others are observing and interacting — via the canvas. Pure verbal communication would be prone to significant misunderstanding because every human forms their own mental construct based on past experience, and therefore the understanding would inevitably be hugely variable.
In canvas-based engineering, the goal is to capture the creators mental constructs and work into a tangible, presentable format: the canvas. Since humans can digest and store such information really well, communication can be very efficient.
In the process, the creator (owner) becomes a viewer alongside his audience and any misunderstanding is resolved on the spot. This is best achieved by the viewer explaining their interpretation back to the creator, and the creator making live changes. Once there is alignment, the work may continue for everybody until there is another communication session.
In practice, there is currently no perfect-fit software for this approach. That having said, canvas-based engineering only requires simple software tooling (contrary to MBSE) and as such can easily be integrated into existing PLM systems. While I have some ideas on this perfect fit, in practice, some team discipline and exchanging Word for PowerPoint gets you 80% underway.
I am aware of the irony of explaining this topic on a writing platform :). However, I do offer a corresponding training that is itself canvas-based.
Also, I realize this turned out much longer than anticipated, yet I still feel like there is more to write on this subject. Please let me know in the comments if and which areas you’d like to see more in-depth articles.
