Can (and should) visual thinking be supported in Coda to facilitate use cases for strategic intelligence in system and application design?

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:

  1. 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.

  2. 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.

  3. There are some implications from the thoughts above on the field of strategic design. I outline them below.

  4. 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 system is just as likely to break in the process of trying to improve it, and 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 for seminal discourse 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 :slight_smile:

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!

Amazing digest and ideas; a delight to read.

I think it’s safe to say that if you have adopted Coda in a way that relates to system and application design or even simple software development projects, pretty much everything about your work intersects in some way in Coda. But as it pertains to the design and development of Coda apps and solutions themselves, there’s an undeniable need to address many of the ideas you presented.

Coda apps will only grow in complexity and the pressure to embrace areas well beyond system and application design in areas like location and data science, will only increase. Coda wants to be at the center of the quest for higher intellectual workflow and it may achieve that. But when it does, it will be awash in integration challenges that at times will make it seem like we’re still using VisiCalc.

Circling back to your general point, we can see no-code modeling disfunction in many products; Airtable comes to mind and it’s not unusual to see business domain experts struggle in the face of data modeling challenges despite the availability of a scheme app. Of course, schemas and entity relationships after the fact are not very helpful if you’re an expert at buffalo herd management.

While I love the idea of visual thinking capabilities in Coda, I’m probably not skilled enough to know what to cheer for, but I do know as the power of Coda rises, the easier deep complexities will seep into solutions and the more difficult it will be to guide users to make good design choices.

2 Likes

Thank you @Bill_French! I fully agree with every point you just made. In reading your response, I realized that I probably could have more accurately titled my post, “Can (and should) data and interaction driven visualization for conceptual system deliberation be supported in Coda [etc…] ?”… Long, unwieldy, paradoxically more accurate yet more vague and likely inaccessible… but perhaps herein lies the point :man_shrugging:t4: - as you mentioned, the core issues here are somewhat complex - and this is part of the challenge that users are trying to solve for.

I think there is a natural tendency to take the easy route and pretend that system design is easy, and that user friendliness won’t require a UX deep dive into the underlying issues behind why and how humans wrestle with the intersections of their psychology and the effectiveness requirements of the systems they build. Doing so only punts the problem to the next generation of innovators (many of whom may be in Coda’s maker community) at the cost of technical debt and user attrition in the short to mid term.

Thankfully, these challenges are far from intractable - and we may be the best generation poised to tackle them. From a strategy perspective, there is a lot of value in mapping existing data on the interaction requirements of systems that various user types in the Coda community have been building or attempting to build, and pairing this with some use case oriented qualitative research on the usability affordances and feature utility of Coda within those user’s development process. Run the subsequent insights through a Wardley Map and Kano analysis and a picture would likely emerge on how to tackle the space.

Scanning the community forums I can infer some patterns (might be worth a write up in future), curious if the Coda team is building any integrated intelligence and evidence around this? (Happy to help :raising_hand_man:t4: )

1 Like

You had me at “Can (and should) visual thinking be supported in Coda.” I need no further predicates [for me] to understand exactly where you were going,

This is akin to the question - Should Codans build every manner of data visualization feature? I don’t believe they should as evidenced by some posts in the past; far too many variants it becomes a big distraction. But even though this is akin - make the features or or integrate other products - this specific one is different. You at least intimate that Coda cannot easily integrate its way out of this challenge.

2 Likes

We seem to be tiptoeing around the dynamic systems modeling discussion. I actually have some business requirements to use Coda as the framework for a dynamic modeling project but not entirely sure I can tackle that one with any degree of anticipated success.

1 Like

Slippery slope indeed - Maybe just radar charts, improved labeling for bar graphs and some overlays for bubble and line charts (eg: candlesticks and trend lines etc…). Dying for some multidimensionality here :tipping_hand_man:t4:

No need to tip toe! If we’re not looking at how to use our data and systems capability in a future facing way, what are we doing?

Your project sounds like a fun challenge to chat about offline. Curious to learn more about its breadth of scope, how much domain translation is needed to support the various stock and flow types, and if you have to integrate the model with ongoing user input. Feel free to send a message!

2 Likes

Thanks for making my point. :wink:

If they add anything or incrementally attempt to enhance any aspect of their current charting stack, the slope becomes steeper and more slippery. Eventually, they will be faced with harmonizing a UI to support every conceivable visualization need which has already been identified in Vega and D3. One must ask - where does it end? And the answer is - it never ends - data visualization is an unbounded science with deep evidence of road kill across thousands of companies who thought they could do it internally and better.

The only companies that have exceeded in data visualization are the companies who chose this area of science to be the core of their business. Just sayin …

I completely understand the need for simple, basic, immediate charting gratification, but good luck drawing the line at simple, basic data visualization.

1 Like

I’m with you :slight_smile:

The challenge is that there’s a general visualization aspect - but when it comes to general collaborative intelligence work (ie: all of design), it’s actually about visualization as interface for interaction and further data creation. Synthesis of data as insight is itself further data that needs realtime visualization. The two way loop is essential, as is the collaborative aspect of this exercise. While Vega, D3, various graph viz are absolutely part of the way forward, this kind of charting isn’t quite the core story on what users need.

1 Like

Yes - agreed - this is a very subtle but impactful distinction.