While reading the book Changing Minds by Andrea diSessa (2000), I came across a very insightful way of categorizing different understandings one can have of a thing: functional models and structural models. I realized that some of my biggest learning epiphanies have come from discovering a structural model for understanding a thing.

First I'll provide several examples of functional and structural models. After that concrete context is in place, I'll describe the models in general and how we can use them to improve our learning, teaching, and designs:

• Examples
  • Microwave
  • Multi-speed bicycle
  • Linked list
  • Git
  • Notion & Coda
• Characteristics of functional & structural models
• Implications

Microwave

One way to understand and use a microwave is in terms of the specific items it knows how to heat. My microwave includes buttons for heating popcorn, a potato, and pizza. A strength of this design is that if I want to heat one of these specific items, I know exactly what to do. If I want to heat popcorn, I hit the popcorn button. A weakness of this design is that if I want to heat something for which there is no button, I have no idea what to do. Which button do I use to heat a brownie? Should I use the popcorn button since they're both desserts? Or the potato button since they have somewhat similar shapes? I really have no idea.

This design can be considered to be a functional model. The button labels are written in terms of the task I'm trying to accomplish. It's trivial to accomplish tasks that the design accounts for but it's completely non-obvious how to accomplish other tasks.

Another way to understand and use a microwave is by controlling its time and power. A key concept is that the longer some food is in the microwave, the hotter it gets. I can use this understanding to heat any kind of food. If I want to heat a brownie, I put it in the microwave for one minute and then I inspect its temperature. If it's too cold, I put it in for another minute and then inspect it again. I repeat this heat and inspect cycle until the brownie is as hot as I'd like it to be.

This design can be considered to be a structural model. The design is more focused on the mechanism of how the microwave works than on the specific task I'm trying to accomplish. Consequently, it takes more thought and more experimentation to heat food by controlling time than to heat food by pressing a food-specific button like popcorn. However, unlike with the food-specific buttons, I can use the time control and a little trial and error to heat any kind of food.

When I learn a structural model, I feel like I obtain a much deeper understanding of the device and gain a much better intuition of what it's capable of. From the microwave's structural model, I understand that operating it involves controlling its time and power. That's all there is to it! With the functional model, I don't gain any insight deeper than pressing this button heats this kind of food.

The structural model gives me a deeper understanding of the functional model. If I can find out how each food-specific button sets the microwave's time and power, then I can understand how heating popcorn compares to heating a potato.

Now that I'm aware of this distinction between functional and structural models, when learning something new I'm often on the lookout for a structural model. The structural model gives me better intuition for the device's capabilities and increased confidence in using the device. It gives me clues of what to do for handling uncommon situations and recovering when something goes wrong.

Multi-speed bicycle

This example of the design of a fictional bicycle is taken from Changing Minds by Andrea diSessa (2000).

Functional model. Suppose the designer of a multi-speed bicycle heavily focused on function and labeled the gear settings in terms of the terrain they envisioned the rider encountering such as smooth pavement uphill, smooth pavement downhill, gravel, and crossing railroad tracks. This poses a problem in certain scenarios. What gear should the rider use if they're riding on gravel and the gravel gear doesn't feel right? What gear should the rider use if they encounter terrain that doesn't match the label of any of the gears? The functional model doesn't provide good answers to these questions because they lie outside the set of scenarios envisioned by the designer.

Structural model. An alternative interface for controlling the bicycle's gears would be to label each gear setting with a number. The mental model would be that the higher the gear setting, the greater the wheels turn for a given rotation of the pedals. With this model, the rider can find the right gear setting for any terrain through a little trial and error. If pedaling is too hard on the current terrain, they should decrease the gear setting. If pedaling is too easy on the current terrain, they should increase the gear setting. In this way, the rider can continually adjust the gear setting until they feel pedaling is the right difficulty.

Linked list

A functional model would be understanding a linked list in terms of its API. Whenever I want to do something new with the linked list, I need to check the documentation to see if I can find a relevant API. If I can't find one, then I'll conclude that the linked list cannot perform the task.

A structural model would be understanding a linked list in terms of how it stores its data: understanding that a linked list node just stores its value and a pointer to the next node. This knowledge and some thought provide good intuition for the linked list's capabilities. If I want to do something new with the linked list, I can think about how the linked list's data could be used to achieve it. Based on whether or not I can see a way, I can make a good guess about whether the linked list can accomplish this task without having to refer to the documentation.

Git

My first several years of using git were based on a functional model. I understood git primarily in terms of its commands. Git was intimidating. It was a massive tool with tons of commands and tons of options. I'd never have a good intuition of git's capabilities. Whenever I wanted to do something new with git, I searched the internet to find out how to do it. If I couldn't find a solution, I'd conclude that this wasn't something git could do.

After years of using git this way, I read about git's internals to satisfy my curiosity. I didn't realize it at the time but learning about git's internals provided me with a structural model for understanding git. I learned that git had just a few core data types (blobs, trees, commits) and that all of git's capabilities could be understood in terms of operations on those data types. This gave me a great intuition for git's capabilities. If I wanted to do something new with git, I could think about what operations would need to be done on git's core data types. Based on this, I could conclude whether or not git seemed like a good fit for the task and predict whether or not git would have a command for the task.

To my surprise, learning about git's internals helped me to become a much more capable user of git. I now realize that's because git's internals have provided me with a good structural model for git. When using git and running into non-routine situations or error scenarios, I now feel confident that I can figure out what to do by thinking in terms of the structural model.

When thinking in terms of the functional model, git felt like a massive and intimidating set of somewhat disconnected commands. When thinking in terms of the structural model, git feels like an elegant set of just a few simple ideas.

Notion & Coda

I first explored Notion out of curiosity. My initial reaction was confusion about what it was. It seemed like some combination of a wiki, a collaborative note taking system (like Microsoft OneNote), and a task management system. If it's just like these existing tools, what advantages does it have?

I looked at its templates and was overwhelmed by the number of things it could do. This made me even more confused about what exactly Notion was. Here's a sampling of things I see when looking at its list of templates today:

• To-do list
• Projects & tasks
• Meetings
• Docs
• Wiki
• Product Spec
• Design Portfolio
• Pitch deck
• CRM Tracker
• Job board
• People Directory
• Org Chart
• 1:1 Notes
• Journal

I watched Notion's video, What is Notion?, which showed that Notion has capabilities including to do lists, kanban boards, calendars, and word processing.

All this gave me the impression that Notion can do everything which doesn't give me a clear idea of its strengths and weaknesses.

I started experimenting with Notion. When making a new page in Notion, I observed that I could pick from several different types:

• Page
• Table
• Board
• List
• Timeline
• Calendar
• Gallery

This small list was more digestible than the big list of templates but I still felt confused about Notion's purpose. I played with Notion more, made no further progress in understanding its purpose, and moved on to other things.

Months later, I was talking with a few people and one of them mentioned how much he liked Notion. Another person said they struggled to understand how to use Notion and asked if he could give a tutorial. The first person replied that Notion makes a lot more sense when you realize that everything is a database.

After some discussion, I felt I finally understood what Notion was. The core primitives in Notion are databases, pages, and views. Everything else in Notion is built on top of these primitives. Suppose I create a database to keep track of video games that interest me. I might make database fields for the game's title, its release date, and my current status with the game (e.g. want to play it, playing it, finished it). Each database record in Notion also has a page associated with it where you can put as much rich text as you want: prose mixed with images, videos, etc. I might use this capability to store my notes about each game.

Earlier, we saw some of the views that Notion supports (e.g. Table, Board, Calendar). Views enable you to see different representations of your database. I might create a Board view of my database so that I can see the video games divided into columns based on my current status with them: want to play, playing, finished. When I finish a game, I can drag it from the "playing" column to the "finished" column. I might also create a Calendar view so that I can see the games that are coming out soon displayed in a calendar format.

The core primitives of databases, pages, and views represent a structural model for Notion. Everything else about Notion can be understood in terms of these.

Looking back at my initial encounters with Notion, I had been trying to understand it in terms of functional models. Notion's templates focus intensely on function. Each is focused on one of the many scenarios that a user might want to accomplish. This is very helpful if I'm trying to accomplish a specific task and there's a template for it. It's not so helpful for understanding the essence of Notion — for building intuition of what it's capable of.

The views are also not a good starting point for understanding the essence of Notion. Views such as the Board, Timeline, and Calendar seem like disconnected pieces of functionality.

The database is the foundation that ties everything together. The views are just different ways of looking at your database. Each template is just a collection of databases, pages, and views that are preconfigured for a particular purpose like organizing a todo list or a directory of people.

Coda is one of Notion's competitors. I have limited experience with it but I overheard somebody sharing similar advice: Coda makes a lot more sense when you realize that everything is a database.

Characteristics of functional & structural models

A functional model is focused on a task that a person might want to accomplish which means it takes minimal effort for a person to see how to accomplish their task using a functional model. This works great in routine situations — situations where the task is covered by a functional model. Whereas it's not at all obvious what to do when encountering a non-routine situation. Using a device requires a whole repertoire of functional models. They may feel like a bunch of somewhat disconnected ideas. This facilitates incremental learning in that a person can learn one functional model at a time.

A structural model is a compact set of tightly interconnected ideas. It is comprehensive in that you can use it to figure out how to do anything you want with the device. This means that even when you encounter a non-routine situation, you have a starting point for figuring out how to accomplish it.

Instead of focusing on a user's task, a structural model is more likely to be a description of a mechanism. Consequently, it takes some thinking to figure out how to use it to accomplish any task. The mechanism description doesn't necessarily represent how the device actually works — it just needs to be useful.

In my experience, a structural model can feel like an elegant set of just a few simple ideas. It brings a lens that unifies the many functional models that previously felt somewhat disconnected. It gives a better intuition of the device's essence and what it's capable of.

In summary, functional models make accomplishing routine tasks fast whereas structural models make accomplishing novel tasks possible.

Here's a table summarizing some of the trade-offs between functional and structural models:

Table: Time to figure out how to accomplish a task

Task Type	Functional Model	Structural Model
Routine	Short/quick	Long
Non-routine	Potentially not possible	Long

(the green cells represent an advantage compared to the other model)

Here's a visualization showing some of the properties of functional and structural models:

Here are the functional and structural models from the microwave example presented using the same kind of visualization:

Implications

How can we use this awareness of functional and structural models to improve our designs, learning, and teaching?

Designers can try to come up with simple structural models for their devices and build functional models on top of them. Perhaps the designer will be lucky enough to find a design where the structural and functional models are equivalent or only have a small gap between them. That way, not only can the user leverage the structural model to accomplish any task but it's also quick to figure out how to accomplish the tasks using this model.

Learners and teachers should probably begin with functional models. They can be learned incrementally — one at a time — and enable the learner to directly accomplish the tasks they care about. Later, the learner can work on acquiring a structural model which will bring them to a new level of competence. It'll enable them to handle non-routine situations that aren't covered by the functional models.

Functional and structural models apply not just to devices but to knowledge in general. Here's an observation about learning physics:

In the beginning it always seems as if I had to memorize thousands of new facts, concepts and ideas. But this is an illusion. There are always just a few core principle that govern the field and thus my first job is to identify them.

From Teach Yourself Physics by Jakob Schwichtenberg (2020), p. 196

External links

• 📕 Changing Minds by Andrea diSessa (2000). I initially learned of structural and functional models from this book.
• 📄 Models of Computation by Andrea diSessa. Chapter 10 of User Centered System Design (1986). Provides additional details about structural and functional models.
• 📄 Mental Models and Problem Solving in Using a Calculator by Halasz & Moran (1983). Compares the performance of calculator users who were given a structural model with those who were not. The users who were taught a structural model spent more time on each calculator operation they entered but completed non-routine calculator problems more quickly. In other words, the users who didn't have a structural model required more calculator operations to complete the non-routine problems.

Reach out

Do you have any examples of structural models that you've found to be helpful? Do you know of ideas that seem similar to the concepts of functional and structural models? I'd be interested to hear about these.

If you have any questions or are interested in anything you read here, feel free to leave a comment or reach out to me directly!

View Comments