Hi All,
I was recently responding to @cnr and @tomavatars’ thoughtful discussion about the request for a “Drawing on Canvas” feature in Coda (see here), and it sparked some deep thinking about the current state of affairs that exists at the intersections of no-code data modelling and visual thinking - and the extent to which this space may present critical value to Coda’s product and ux teams. I’ve tried to write these thoughts up below for others who may be also exploring these themes - such as my peers in the system’s design community. It’s a deep dive, so here’s the TL;DR - feel free to read further as interested!
TL;DR on my thoughts:
-
The Coda product teams interaction UX vision may want to deeply consider the domain of visual deliberation to unlock the doc creation potential of users. I’ll present some context and case for this and note that it can include both data driven and interaction driven visualization.
-
I agree with @cnr that there are some very interesting use cases for specifically data driven visual thinking capability in Coda. I’ll share an example of MVP experiment I explored some time ago.
-
There are some implications from the thoughts above on the field of strategic design. I outline them below.
-
Some additional considerations for Coda around the business value of considering this discourse for product strategy.
Diving into the Deep Dive
1. Considering the value of visual deliberation:
I think @cnr is absolutely right that Coda’s unique value is in its ability to facilitate no code data modelling and database management directly within the workflow. Leveraging this capability to build meaningful systems is a significant UX challenge in that it requires users to simultaneously envision their desired functional interaction and analyze their mental model of the domain to identify and frame the required underlying object-relation-function model.
I’ve come to realize that these models are likely to include (and attempt to bridge across) multiple layers of logical abstraction which probably won’t be immediately apparent to a user (natural language doesn’t include explicit descriptives for specifying abstraction in definition) - but are almost guaranteed to require translation and normalization elements within the model for the application to work. These are also likely to be brittle points that break whatever application the user builds in practice - particularly if they are trying to use their application for collaboration with colleagues (who have diverse mental models), and for integration across operational timescales and business functions (which is kind of the point of an intelligent system). Introducing users to simple architecture patterns like “master table and views, star pattern etc.” really doesn’t go very far in helping them address the real world challenge of building a system that can solve more painful problems over time.
HCI research on how humans solve these problems in practice points to an iterative and reflexive interaction process of “epistemic actions” (see the work of Karl Fast for more on this). In essence, the abstraction of the system model must be embodied through interaction to enable the user to simulate its behaviour and then understand its translation and normalization requirements (much of Bret Victor’s work looks at this). The system must also be calibrated to the real world operating environment, which will present alignment challenges for negotiation and concession - ultimately the model of the system will also impact the language and discourse of the surrounding user community, and these changes have to be considered thoughtfully. It’s a process of deliberation, pattern matching, consideration and decision making. Iteration itself means that the system is just as likely to break in the process of trying to improve it. Anything to create clarity about what is going on and what is needed will add meaningful value to the designer’s process. As it happens the entire field of interaction design (spanning all of product design, visual design, systems engineering), is basically defined by visualization methodologies where users leverage visual thinking to simulate system interaction scenarios and enable management of this iterative and deliberative process (see the work of Alan Cooper and Dubberly Design Office on this).
Speaking with folks on the Coda team, it’s clear that Coda’s users experience this process in a diverse variety of ways, and not all would prioritize visual thinking as their method of choice. Yet the deeper a Coda user’s system build goes, the more likely they are to be absorbing the cost of managing this kind of design consideration. Visual deliberation can be helpful for design at any system scale, but especially for many of Coda’s users who build complex systems, and are managing concerns of scalability, performance, usability and breadth of domain. For many of them interactive visual deliberation seems to be an essential aspect of the process (see @Paul_Danyliuk’s youtube channels such as coda tricks for many examples of this. It seems there is ongoing demand for support in this (as discussed by @Bill_French and @Sonny_Oaxus here ) It may even be argued that the doc map feature is an attempt to allow users to ‘see’ the implications of the model they are building even as they reason over it - But the UX for this is spotty at best.
I’ve noted this distinction of interaction driven vs. data driven visualization, and also intimated the role of deliberation in visual thinking. In addition to data and interaction - logic driven should also be included - (eg: some Figma plugins that scrape urls to build sitemaps, and tools which track and graph behaviour etc…) and intersections with computational simulation modelling should also be considered in the context of design intelligence (ie: system dynamics modelling , eg: vensim, anylogic etc…). There’s much more to be said about all of that - and in particular the rich and deep history of ongoing work trying to understand visual thinking, and the role of language specification in supporting more powerful visual communication (in particular for system design). I won’t go into it here as it’s another essay - but I will note that this history is wildly mixed in terms solution effectiveness, and that the integration of data driven and interaction driven visualization approaches is the critical need/opportunity to solve for. This may be the essential moment that we are in - if and when the Product and UX teams of system design platforms do the work to understand and consider the value of this kind of integrated visualization capability. This is the bridge between system architecture discourse (ie: interaction design, enterprise architecture etc. eg: ardoq, archimate etc…), knowledge graph and intelligence capability (e.g.: Neo4J, Roam research, Linkurius, RiskIQ etc…)., Strategic deliberation (eg: IBIS/Dialogue Mapping, Tom Graves, Alan Cooper, The work of folks in the Singapore and Taiwanese gov’s on mapping citizen discourse etc…) and general use business flowcharting (bpmn, etc…).
When I look at my customer’s miro boards, they basically amount to giant giga maps of knowledge that map across all these modes - but without data or computation support for the operational implications of all that sense-making… which we then have to translate into tools like Coda and custom software builds for business value - and once that translation is made, we still have to continue translating back into the sense-making space for ongoing design and system change. Sigh…
2. Exploring MVP’s for integrated data and interaction driven visualization and visual deliberation
Popular platforms like Miro have yet to really engage this issue, but there are some technical teams exploring solutions in this space with their API. Miro’s new “Clusterizer” feature is one example of this. It can also be argued that Coda’s api integrations with Figma could also be used to support some of this kind of sensemaking work when paired with Figma’s symbol management tools - but I have yet to see this in the wild.
For my part, some time ago I explored building an integration between Coda and Kumu - a relatively user friendly graph database tool for multidimensional network mapping and systems modelling. While I was exploring a number of functional uses, one example was the visualization of CRM data from coda as a social graph. The intent was to interactively build strategic foresight scenarios using CRM and Business operations data via a custom wizard workflow in Coda (ie: interactive deliberation), and then press an update button to have these scenarios visualized as network graphs in Kumu. It was clunky, but as a preliminary proof of concept I was able to make it work, and the results were promising. But to @tomavatars point, managing all this data and interaction across multiple tools was a royal pain.
3. Relevance to Strategic Design
Without dedicated and scalable support for this intersection of data, interaction, logic and computation driven visual deliberation, I wouldn’t expect any design team to integrate a true or rigorous enterprise intelligence practice into their work. At present the appropriate tools don’t exist, and managing the data pipeline with the tools we have is operationally impractical. But the opportunity for this value is here - as is the mandate.
Many designers are realizing that their discipline came from systems thinking - and are seeking to reintegrate core systems skills into design practice for design impact - particularly in the development of application solutions. Most design teams are implicitly tasked with managing an informal design intelligence capability, and simply can’t scale their tooling and ops to match the needs of their service domain in a way which compliments the speed, craft and deliberation requirements of their actual design practice and process. The need for this capability is cross-sectoral, industry wide and particularly urgent in the spaces of service design, strategic foresight, and enterprise management. This is where I am hoping Coda can help.
4. Considerations for Coda - Product & UX strategy
As Coda becomes more performant, more enterprise teams will try to build platform strategies around it. This will impact the involvement of client side strategic and product design teams, alongside management, who will need to think cross-functionally about Coda as an intelligent operations tool - integrating data to unblock people and process innovation at scale.
These users will benefit greatly from integrated visualization and visual deliberation capabilities within Coda - both in terms of the quality of systems they will create and in terms of their ability to advance the business case for broader integration of Coda enterprise wide. While there are many additional reasons to explore the opportunity around this product capability, I propose that modelling the business case for this point alone is likely to be worthwhile - especially as Coda seeks to scale up professional services (@John_Scrugham ), and potentially support more broad collaborations with industry service teams.
Conclusion
Those are all my thoughts for now. For those who read and comment - many thanks! Happy to clarify anything here and engage in discussion if I have time 
I fully recognize that all this might be better framed as a blog post - perhaps a coda doc in the gallery. Personally, I really want this kind of deliberation to be supported as an ongoing embedded and interactive community experience (eg: explorable explanations). In some sense - that is the future of Coda docs, we’re just not quite there yet. A basic comment stream on a silo’d blog wouldn’t quite cut it, nor would coda doc with an embedded form. I imagine we have to get to the next phase of the format wars before we realize our collective intelligence visions.
A brother can dream though right?
Cheers!
- as you mentioned, the core issues here are somewhat complex - and this is part of the challenge that users are trying to solve for.
)
