Understanding Norman’s Action Lifecycle
An excerpt from Design and Build Great Web APIs — by Mike Amundsen
In his 1988 book, The Design of Everyday Things, author Donald Norman lays out several principles of designing and building “things” (doorways, telephone, computers, and so on) for human interaction. A former Apple Fellow and co-founder of the human-computer interaction design firm Nielsen-Norman Group, Norman was the first to use the phrase “user experience” in a job title and is considered by many to be one of the founders of the field of human-computer interaction (HCI). He released an updated edition of his book in 2013, which continues to influence the field of computing.
One important concept in Norman’s work that can be directly applied to our work of modeling APIs is Norman’s Action Lifecycle (see the diagram). It’s a model for the way humans interact with any object, whether on a computer screen or in the real world.
Norman’s Action Lifecycle is composed of seven stages divided into two sections. Section 1 is the “Bridge of Execution.” This is where humans plan and then commit some action. The execution side of the model has three parts:
- Plan
- Specify
- Perform
For example, I might decide I need to turn the light on in my room in order to continue reading a book as the sun sets — that’s my plan. I then need to figure out where the light switch is (I specify exactly what to do). Finally, I need to actually go over to the wall and flip on the light switch — I perform the task. In that last step (perform), I affect the world around me — I change something.
The next set of steps, the ones Norman calls the “Bridge of Evaluation,” are what I use to determine what happened in my world and decide whether or not I actually accomplished my intended goal:
- Perceive
- Interpret
- Compare
I perceive whether the light actually turned on. I interpret the results of my actions — meaning I associate my change of the light switch to the light that is now on in the room. And I compare my expectations (I wanted the room to be brighter) with the actual real world results (in this case the light is on and the room is bright enough for me to read).
That last step (compare) leads me to decide whether I’ve accomplished my goal. The goal, by the way, is Norman’s seventh step. If I’ve met my goal, I’m all done and can sit down and get back to reading my book. However, if the switch I used actually controls the overhead fan and not the light, I did not accomplish my goal yet. That means I need to go back and start the cycle again (plan, specify, perform, perceive, interpret, and compare) and continue until I find the proper switch and make the room bright enough to continue reading.
Everyday Things
While this model sounds rather tedious, it’s really quite handy. You can apply it to all sorts of things in your everyday life. The light switch example is rather simple, but this action lifecycle is present in many activities. Consider, for example, the task of searching for this book on the web. You need a plan, you need to determine some specific search criteria, and you need to type that criteria into an Internet search engine. Depending on what you typed as your criteria, you might not get the answer you expect when you perceive, interpret, and compare the search results on the computer to the response you’re thinking of in your head. That means you need to start the loop again, and so on, until you get your expected results (or just give up and go outside for a walk).
All sorts of things you do every day use this action lifecycle, such as more complex activities like driving to the store to buy groceries or meeting friends for dinner. In everyday life you often need to interact with several things in order to accomplish an important task. Commuting to work in the morning is one example: You need to first get out of the house (that’s one lifecycle), then you need to drive to the commuter parking lot (that’s another lifecycle), and then you need to catch the next train into the city (another lifecycle), and then you need to make your way from the downtown train stop to your office (one more lifecycle). Each of these cycles has its own challenges; you may need to stop for gas on the way to the parking lot, you may need to take a detour along the way, you may need to catch a different train into the city, and so forth. We often use this loop quite subconsciously, but we do use it.
We can use the same process as a model for our API — and as a model for the act of creating it too.
API Action Lifecycle: The RPW Loop
Norman’s Action Lifecycle is a good approach for us when we model our own APIs. But, as already mentioned, it can be a bit tedious to work with. Knowing exactly what happens in the perceive step or the interpret step might not be very helpful when all we’re trying to do is model an API to solve someone’s problem. For this reason, we can simplify Norman’s seven-step model into three general actions that work for all the types of APIs you need to model: (1) request, (2) parse, and (3) wait, as illustrated in the figure shown.
This request–parse–wait (RPW) loop makes lots of sense if you think about how the web works — especially how a web browser works. Users type something into the browser to start a request (for example, I type https://training.amundsen.com into the address bar and press Enter). Next, some server somewhere sends a response that the browser needs to parse (for example, the HTML message returned by a server gets parsed and displayed as a web page with graphics, tables, CSS, and so forth). Finally, after the browser displays the parsed response, it waits for me to click something, fill in a form, or just type something else in the address bar; and when I do that, the loop starts again. If you think of your potential API client applications as a kind of web browser, using the RPW loop as a design pattern can be very helpful.
The RPW loop is a good way to think about your API server too. Web servers behave very much like web clients in that they spend most of their time waiting for a request to come in. And when it does, a server needs to parse the incoming request (What URL was requested? Is there a body of data to process? What kind of response format is requested? and so forth). After processing that request, the server needs to create a response to send to the client. Once that’s done, the server just waits until another request appears.
What About Real-Time APIs?
INFORMATION
Even if your server and your client are not using typical request/response HTTP messages and are, instead, using something like reactive services, WebSockets, or some other real-time interface, the same RPW loop exists. It just has very small wait times and even smaller response and request messages.
So, modeling your API with the RPW loop in mind is a good idea. That means taking all you know about what your users are trying to accomplish (the goal), all the tasks they need to complete along the way (each of those is its own cycle), and how your users determine whether they’re making progress (comparing) and what it is that lets them know they’ve actually completed their work (met their goal).
This can be a bit tricky since people don’t always think in the way Norman does or even the way most developers think. Your users will often just tell you how they do their daily work, what forms they fill out, and where they send the forms when they’re done. And they may tell you only part of the story. To use our fictional company as an example, some people at BigCo just work on handling company records and don’t know anything about account records (that’s another department). But when you’re working to model an API that combines the work of both the company team and the account team, you’ll need to come up with your own set of action lifecycles to accomplish a goal that no one else yet knows about.
That’s what we’ll be doing here when we model our own Onboarding API lifecycle.
We hope you enjoyed this excerpt. You can continue reading Design and Build Great Web APIs directly on Medium.
Or purchase the ebook directly from The Pragmatic Bookshelf. As part of our 2023 Spring sale, you can save 50 percent on this book by using code DATAFLOW2023 through midnight ET on April 25th, 2023.
For a print copy, visit bookshop.org.
