The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #191 Rhythm and Flow - A 2012 IA Summit Podcast with Peter Stahl

November 21, 2012  ·  42 minutes

Listen Now

Download the MP3

Most interactions have an underlying rhythm. For example, an application may ask you to scan a list of items, then click one, leading to another list to scan and click. Scan, click, scan, click. You can get into a groove. Systems increasingly have rhythm too: animated transitions, hover responses, and digital physics. Static is so last year.

Show Notes

(Originally posted at the IA Summit Library)

Most interactions have an underlying rhythm. For example, an application may ask you to scan a list of items, then click one, leading to another list to scan and click. Scan, click, scan, click. You can get into a groove. Systems increasingly have rhythm too: animated transitions, hover responses, and digital physics. Static is so last year.

But sometimes it’s wise to break rhythm. And besides, rhythm alone isn’t enough. The best experiences induce a state of “flow,” during which users get into such a groove that mechanics disappear, time falls away, and the experience itself becomes intrinsically rewarding. (Wouldn’t that be awesome?) Designers own rhythm. Yet our work practice lacks appropriate tools and vocabulary. How do you portray a groove in a wireframe or PowerPoint deck? Examples from other fields can help. We’ll see how it’s done in animation and movies, game systems, music and choreography.

Full Transcript

Peter Stahl: Good morning, everybody. How are you?
Audience: Good. How are you?
Peter: I'm doing great. My name is Peter Stahl, and I want to thank you all for coming to my talk on rhythm and flow. While we're waiting for people to filter in, I'll tell you a little bit about myself. This is my resume, on a slide.

I have worked in everything from eBay, e-commerce to Cisco doing specialized technical applications for Cisco Services. I started, actually, in local area networking at NetStar, and I've come full circle at Cisco.

If you want to know what I do when I'm not working, I'm into California ballot propositions. You can engage me in a lunchtime conversation about that. Also, I'm a musician, and I support a chorale academy, and I play in Redwood Symphony.

This is my second presentation at IA Summit. Four years ago, with Josh Damon Williams, I talked about checking the feel of your user interface with an interaction audit. It attempted to delve into the little-explored second component of look and feel, the feel part, which we think is neglected and deserves much more attention than it gets.

Here, we have the risky blank slide.

Here's where I talk about what we're up to today. I believe we're at a crossroads in our profession. Our disciplines have evolved tools and processes for static screens, information displays, forms and so on, all the things that made the worldwide web... I'm sorry? This is intended to be a blank slide.

The idea with this is that maybe you'll pay attention to the speaker instead of the visual.

We, as a profession, are really good at designing static screens, and that's understandable if you look at the evolution of our discipline. Many of them came out of print media and others out of architecture, and those, primarily, deal with static information displays or static experiences.

There are two problems. First of all, user experiences do not stand still anymore. Secondly, it's no longer good enough simply to provide functionality. We have got to engage and delight our users, and that's hard to do with user experiences that sit still.

Our profession has to adopt vocabulary, artifacts and methods that recognize experience over time and across screens, from end to end. If we don't, we risk obsolescence or worse, irrelevance, the same way that the designers of early mobile phones are now irrelevant in the face of Android and iPhone and the like.

Today, I hope to kick off a conversation about how to approach this issue that's so vital for our profession.

All right, now you've got a visual again. I'm going to be talking about interactive rhythm, flow, artifacts and deliverables, motivic rhythm, which is distinct from interactive rhythm, and finally, how to capture timing, in other words, ways for us actually to incorporate these into our work practice.

Interactive rhythm. You usually think of rhythm in terms of music. There is definitely an interactive component to playing the drums. You hit it. You get immediate feedback. You hit it rhythmically, you can get into a rhythm. But there are other experiences that have a rhythm to them, too.

Channel surfing. Lots of people go to their televisions, and they sit on the channel up button. They've got a period of maybe half a second to a full second after the new channel comes on to decide whether they like it, and then, they hit channel up if they don't. In the 500-channel universe, chances are that they don't. The rhythm is channel up, channel up, channel up, [laughs] channel up. It's a very simple rhythm but a very popular one.

Driving a car, particularly a manual transmission as you see here, has a very distinctive rhythm to it. Drive, push in the clutch, shift, let the out the clutch, over and over again, as you accelerate, as you decelerate. Even if you've got an automatic transmission, there's a great rhythm to driving. Speed up, slow down, that thing.

Video games have a great rhythm to them. That, in large part, has led to their popularity. You're able to learn the rhythm of each game and then sublimate it so that you can focus on the higher-scale things, like strategy and looking around for monsters.

Browsing the web has phenomenal rhythm. Read a page, find a link, and click it. Read the next page, find a link, click it, and so on.

I would argue that the worldwide popularity of the worldwide web back in the '90s, among not just geeks like the people in this room, not that everybody in this room qualifies as a geek, is, in large part, due to the simplicity of the web. It was so simple back then because all that you had were hyperlinks and maybe the occasional image map. Anybody could use it, so everybody did. Fabulous rhythm on the web.

Forms have a great rhythm. Fill in a field, go to the next field. Fill that in, go to the next one. Fill that in, go to the next one.

Desktop games have rhythm. I don't know how many of you have ever gotten lost in solitaire, but part of its appeal is that you get into a groove. You get into a rhythm, and you can't stop. There are lots of other games that have irresistible rhythms to them, as well.

Twitter, of course has great rhythm.

YouTube has a rhythm on a larger scale. When you get to the end of a video, it offers you a series of additional videos to watch next. You click on one of those, and, at the end of the next one, you get more. One of my kids is actually addicted to YouTube in this way, following a chain of recommendations, much like one would do when surfing the web.

This feature of Netflix is tremendously addictive, and part of its appeal is its fabulous rhythm. In this movie rating feature, you click a star, and, as soon as you've clicked a star, that movie goes away and another one pops up in its place. You can just keep clicking stars, in a steady rhythm, all day long, and I'm sure some of us have. I certainly have.

You might not think of a word processor or a desktop application as having rhythm, but Microsoft Word does. This user interface that you see, if you ignore that rhythm of complicated controls at the top, which are way too complicated for the people in this room, what you've got is something that was revolutionary when it first came out. It was the plain paper user interface, a direct metaphor for inserting a sheet of paper into a typewriter.

Now, typewriters have fabulous rhythm. My orchestra recently performed a pops piece by Leroy Anderson called "The Typewriter." Chika, chicka, chika, chika, chika, chika, chik. Chika, chicka, chika, chika, chika, ding, whoop, and so on and so forth. How many of you are not quite sure what the ding at the end of that was?

I'll explain it to you at lunch. It has to do with a warning bell telling you how many characters are left before you have to do a manual carriage return. Anyway, in that way, the typewriter has rhythm, and so, a word processor has rhythm. And, of course, PowerPoint has a powerful rhythm. Maybe that's why it's called PowerPoint.

When you're composing PowerPoint, new slide, title, bullet, bullet, bullet. New slide, title, bullet, bullet, bullet. New slide, title, bullet, bullet, bullet. Pretty soon you start to think like PowerPoint. By the way, we've just composed the PowerPoint song.

Given those examples, let's maybe draw a few generalizations. What makes rhythm? Well, it's got to be simple enough that you can repeat it, and it has to be repeatable, obviously. The tempo has to be relatively steady. Now, we saw, with YouTube, that it doesn't have to be exactly steady, but the sequence of action needs to be predictable, and you need to give people reason to continue, because if it only goes a couple of repetitions, that's not much of a rhythm.

Should we always try to strive to incorporate rhythm in our user experiences? I don't think so. It's only appropriate in certain circumstances. If you've got one overall job with repeatable interactions, you want to make sure that people don't get sidetracked or taken off track, so errors and exceptions should be rare and easy to recover from so you can get back into the rhythm.

Should rhythm ever be interrupted? I think it ought to, if you need the users to think, because once you get into a rhythm, it can be amazingly hard to get out of it.

Imagine an e-commerce site. You've got your users into this great rhythm. Browse, add to cart. Browse, maybe decide not to add to cart. Browse, add to cart. Now it comes time for the user to pay.

Should you set up your user experience, so that it's easy to pay and you just fall right into it? Well, you might get people making purchases that they didn't intend to. I know that some of you are thinking, "Great! I'll be a lot more successful. I'll make tons of money that people didn't intend to give me."

I have news for those of you who think that way. You're going to be really, really unsuccessful and probably only in business for a very short time. So, this is a great chance to interrupt the rhythm.

Finally, not all experiences got rhythm. Here's Photoshop. Photoshop is very complex. Now, Photoshop can have rhythm in certain, temporary circumstances when you've got 27 layers and you have to do the same two operations on all 27 of them. Then it's rhythmic, but the rest of the time, Photoshop is really on the outside of the rhythm.

A settings screen that only gets used once, occasionally. No rhythm there.

Here, we've got TurboTax. Now, TurboTax is a form, and I said earlier that forms have rhythm. But it takes me one second to recall my social security number. It might take me one hour to collect all the information I need for schedule D. The steadiness of the rhythm is missing there.

Finally, rhythm isn't enough. I said at the beginning that we need to engage and delight our users. Well, we've all been subject to rhythms that are boring, that are trivial, that are tedious, painful, unsatisfying, and pointless. Rhythm doesn't guarantee a satisfying user experience. Oh, and I forgot annoying and insulting. Let's never forget those.

What we need, instead of rhythm, is flow. Flow is a concept that was developed by this fellow, Mihaly Csikszentmihalyi, who is a psychologist at University of Chicago, was previously at Claremont Colleges, and I'm now going to teach you how to pronounce his name.

Ready? Repeat after me. Chick.
Audience: Chick.
Peter: Sent me.
Audience: Sent me.
Peter: High E.
Audience: High E.
Peter: Put them together. Chick sent me high E.
Audience: Chick sent me high E.
Peter: Very good. Now, the next time you drop his name in conversation, people are going to be very impressed.

His seminal work is "Flow," where he describes the phenomenon. It's available both in paperback and in Kindle version. I have a secret for you. Kindle edition is more expensive. I don't know why.

He describes this flow as "the state in which people are so involved in an activity that nothing else seems to matter. The experience itself is so enjoyable that people will do it, even at great cost, for the sheer sake of doing it. Flow is being completely involved in an activity for its own sake. The ego falls away. Time flies. Every action, movement and thought follows, inevitably from the previous one, like playing jazz." Let's see, like Diana Krall here. "Your whole being is involved, and you're using your skills to the utmost."

Now, wouldn't that be amazing, to have the user experiences that we create induce that kind of feeling in our users? When was the last time you truly felt as one with the user experience?

Ah, this is, perhaps, a little bit more modern version of that. When was the last time, time completely fell away? You looked up at the clock two hours later and were wondering what happened?

Or even here. The dimensions of flow that Csikszentmihalyi defines are clear goals and progress tracking. These are elements of the experience that need to be present in order for flow to exist. There needs to be a balance of challenge and skill. I'll get into these a little bit more in detail in a second. The user has to have a sense of control. There needs to be focused concentration. This will all lead to a loss of self-consciousness and time distortion.

We've all experienced time distortion. You have such a great time that you forget that you have something else to do. Ultimately, the experience itself becomes rewarding. You look forward to seeing the logo of your favorite social website, just because you love to see it, and you know what it leads to. You want to do it not because of some external outcome. You want the experience itself.

Now, Csikszentmihalyi has a critique of web design. He says that "Site designers assume that the visitor already knows what to choose," but that's not true. People enter a website hoping to be led somewhere, hoping for a payoff.

On feedback, most websites don't very much care what you do. It would be much better if they said, "You've made some interesting choices."

Challenge. A flow experience has got to be challenging. Anything that is not a part of it is going to be irritating or ignored.

Finally, progression. You need clear goals that are in a hierarchy that builds.

How can we induce flow in what we design? By the way, on that last slide, you notice the date, here? This critique of web design is from over 15 years ago. How many of you think it might still apply today? I thought so. Good. What this means is that there is an enormous opportunity for those of us in this room and at this conference to take the next leap ahead in user experience.

In order to induce flow, basically what we want to do is fill the gaps that Csikszentmihalyi points out, meaning, to create clear goals, achievable challenges, progress tracking and obvious next steps.

Here's one example of a way of doing it. LinkedIn tells you what percent your profile is complete, and it tells you what to do next.

Mint, which is now part of Intuit, does largely the same thing. It tells you your score and gives you ideas on how to bump it up.

Even more technical things, like wizards, can have stepped progress. If they're designed properly, they can even have hierarchically graded challenges.

Nevertheless, not all experiences get to have flow. Here's a registration page, and the registration page, even though it's a form and it has great rhythm, will never have flow because once you're done, you're done. It also has a sense of humor, by the way. It says down here, "Please prove that you're not a robot."

Tic-tac-toe. Sorry, no grading of challenges here. You can see, this person who tried to see if it's more challenging after the eight thousandth try, but... Sorry.

Some video games for some people don't have flow. When I play Mario Kart against my teenage son, he gets into flow, but I don't because he completely creams me every time we play. As far as I'm concerned, there's no flow here.

A dispatch page, such as the front page of a complex website, or maybe the Yahoo home page, no flow there because the idea is to get you off of this page as quickly as possible.

Let me shift gears here and talk about artifacts and deliverables, the kinds of things that we can do, starting soon, to induce flow and to create rhythm in our user experiences.

Here is a wireframe. How many of you have created a wireframe in the last six months? OK, lots and lots, so it's a popular artifact. It inherits a great deal of what it does from blueprints. It's an architectural diagram.

The architectural diagram tells you a lot about the structure, but it also hides a lot. It doesn't tell you about the materials. It doesn't tell you about the furniture. You have to be a specialist to be able to imagine, from this, what it's like to move through the space.

It's also got certain symbols that are very technical in nature. Things like where the electrical outlets or overhead light fixtures are. It's got some of the same problems associated with a wireframe. You really need to know the language of wireframes to understand what this represents.

Now, wireframes were great in the days of 1996, when this was taken, when the worldwide web consisted of only a few possible controls. Here, we've got hyperlinks. We've got an image map. We've got a form field. By today's standards, this is a wireframe.

There's a problem with wireframes. They are used to describe interaction, but they leave something out. Today's user interfaces don't stand still.

Here's the same Yahoo home page from about 12 months ago, and it's got all kinds of motion. Some of it is instantaneous, and some of it is in response to hovers. I'll do one or two clicks here, but it's got mouse-over responses. It's got tool tips. It's got these things. You click on them and completely redefine the page. How do you represent that in a wireframe? It's a web page.

There is, however, I think, a much deeper problem with wireframes and with their brethren, flow charts and mock-ups and even prototypes.

The field that I'm in is originally named computer-human interaction. Some of you might be aware of a conference that is largely the same as this one in terms of the subject matter that it covers. I think that's being held in a month. Where is that going to be held this year?
Audience: Austin.
Peter: Austin. Oh, excellent!

The artifacts that we've been looking at, wireframes, mock-ups, prototypes, what part of this do they show? They show the computer.

Now, we've just discussed flow. Flow is not a property of the computer. Flow happens in people. How are we going to induce flow in people if we leave them out of our designs? Our friends in the research community have a few ideas.

Look, here we have the mock-up or the actual computer in the main screen, and then, we've got the user down in the corner.

Here's another one that actually shows all three components. You've got computer, human and interaction. The computer is on the lower left. The human's on the upper right, and then, the actual interaction is here, on the lower right.

You might think to yourself, "Well, OK. How do I do this if I'm just designing and I don't have anything to test yet?" Well, you can go with this comic book approach.

As a matter of fact, our friend Kevin Chang, who is now at Twitter, has been advocating this for many years. You certainly don't have to be able to draw as well as he can. Any fans of Xkcd know that. You can get a lot across with just stick figures.

If you think that that kind of representation has to be dull, this is a counter example. This is a gesture system. You can see that this artifact is very compelling.

That leads us to motivic rhythm. We've already talked about interactive rhythm, things like remote controls. Motivic rhythm, rather than being a property of the user, is a property of the web page or the user experience. It happens on the computer.

Let me give you an example. This is the beginning of the Sony website. You can see that as mouse goes over each element, the response of the system is not instant. There is an animation that comes along with it.

Well, somebody had to decide whether that animation would take 250 milliseconds, 750 milliseconds, and a second and a half. And that is the motivic rhythm of this site. It's the responsiveness of the site to the mouse over.

I've got another example that I'll get to at the end if there's time. But that's what motivic rhythm is, and you're seeing it more and more in websites that give you more details on an object as you hover over it. Or some kind of new experience. You can see, in this case, the entire page changed.

Since the web experience no longer stands still, somebody has to design the timing. That person is probably someone in this room.

How are we going to do this? Well, let's see if we can take some cues from our colleagues in other industries. In motion pictures, there's a storyboard and you can see in the upper right there is some timing.

Actually, I don't know where the timing is indicated on these, but here's a storyboard for a television commercial from the '60s, for Hai Karate aftershave. Here's a storyboard adapted for web browsing.

The world of gaming is one where timing is critical. What they use is something called animatics. Animatics is, in essence, a rough cut or a sketch that has been animated. Here's an example from some game. You can see that it is just sketches and maybe two or three of them a second, maybe a few more. It's used to get the timing right for the interaction. It's also used to hand to the composer for the background score, if that's going to be coordinated with the action.

I believe the hero wins this one. Yeah, that's right. The spear grows back.

Another discipline that has motion and timing associated with it is dance. There are a couple of major notations that are used to establish timing in dance. One of them is Benesh Movement Notation. Each one of these lines in the staff corresponds to a part of the body, and each one of the squiggles represents a kind of movement. You can see, here, the positions that are associated with each of these notations.

A competing notation in dance is called Laban notation. You can see, this one actually has the music running up the side, and the notation doodads go in amongst the piano score, there.

Finally, music, of course, has a strong sense of timing and motivic rhythm. Maybe we can borrow something from that.

Let's imagine that this is the user experience that you want to engender, and actually, this is the real user experience. What I showed you before was the stimulus, but, of course, we want to induce flow. I don't know, would you say she's in a state of flow?

Here's the delivery method. It's a 45 rpm record that plays on this thing, which is called a hi-fi, or if you're my little sister, a lo-fi. I just noticed, in this photograph she's playing a 45 rpm single at 33 and one third, which might explain why she became a Pink Floyd fan later in life.

How do you specify something like that? Well, if you're a pianist, this is probably the right specification for that experience. If you're a guitar player, maybe this is the right tablature. If you are a musician who plays this bizarre meat grinder instrument that they invented at the MIT Media Lab, this is probably the correct specification. If you are the singer, you want the lyrics. Maybe this is your specification, although, that's hard to read. Perhaps you'd prefer your specification nicely typeset.

If you are an engineer, you might look at this and go, "Gosh, that's awfully repetitive. Can't we do something about that?"

As I mentioned before, you really want to present something that shows the experience over time, and so, a video is probably your best bet for demonstrating what the user experience will be like. In keeping with what I said earlier about including the users in your artifacts, we need to make sure we have that photo, down there. This might be the best picture.

Finally, let's talk a little bit about what tools we can use today to generate these artifacts to help us design rhythm into our user experiences and create flow in the users, the lucky users who will love us as much as we love them.

Adobe Director is the traditional tool for people who are doing movies. It's very old. I'm sorry. It's very mature and has a rich, rich history to it, which means that it's not necessarily simple for everybody to use, but it's great at what it does. Adobe Flash is somewhat easier to get started on, and Flash Catalyst is still easier.

Microsoft has its own tool, its Expression Blend, and I've heard good things about it. I've never used it myself. Has anybody here used Expression? OK, one or two.

Axure is a fine prototyping tool.

Let's not forget tools like Keynote and PowerPoint. Those have primitive animation capabilities, and I've seen them used to great effect, especially when you're using simple watt diagrams.

You can just take a wireframe, very similar to what is used in the animatics that we saw earlier that the gamers use, pop it in and adjust the timing using the PowerPoint or Keynote animation tools. You'll be surprised at how effective it is in conveying the experience over time and the responsiveness of the system.

Now, I think it's time for your ideas, so we'll pause here, and I think I've got five or ten minutes for questions.
Man 1: When you started talking about the tools that we would use, Expression Blend or the Expression Suite, Axure RP and stuff like that, you were talking about a video might be the best bet for us to get there and including the users. It seems like we would maybe even have that actor or that character in there to some extent.

I wanted to know whether you meant that a video, or approximating that in a deliverable, would actually include a character, and, if so, how you see that happening?
Peter: Thanks. That's a great question. Well, one of the things that you can do is include a stick figure down in the corner, very similar to what you see in usability tests.

Most of us have used the services of professional researchers, and what they deliver, very frequently, is something like what I showed earlier. The user experience is in the large part of the screen. Down in the corner is the user's response. Well, how do you interpret that unless you know what you want?

You can have the user's desired response down in the corner as a stick figure, or maybe you can take a photograph of yourself with various facial expressions. That's always a fun thing to do. That way, you can be overly dramatic and go, "Huh?" Or, "Wow!" Or something like that, and make that part of your prototype or your specification, say, "Here's where we really rope in the user." Or, "Here's where the user gets his question answered." Or, "Here's where the user runs into problems."
Man 1: I find this really useful. I'm wondering if I should do the evil, play devil's advocate thing. Isn't this all maybe just marking out the limitations of deliverables as a whole, and, really, what we're talking about is needing to go more towards prototypes. The deliverable is the prototype, and you develop the interaction by looking at it. The deliverable piece is actually, well, the user test that shows that's the user in it. Throwing that out as a...
Peter: Yeah. Well, one of my main points is that the deliverables that we are using today, in many cases, are the same deliverables that we used 15 years ago, and that's no longer appropriate. I don't know, exactly, what the correct deliverable is for us today.

If all interaction designers were to become animators, it would seriously affect the amount of time they have to put into their primary role. Maybe we need to start hiring animators, I don't know. It's an open question, but I think we need to move forward.
Man 3: I love your Beatles metaphor, especially since I'm a huge fan of the Beatles. Having said that, don't you think the metaphor is more like a jam session or an improvisational comedy show? There is not actually an audience that can take part. It's almost like a karaoke version of the Beatles. You can't interact. You can't change stuff on the presentation.
Peter: Well, you need to choose different artifacts for different parts of the design process. The Beatles thing, I think, is correct for an early stage where you're trying to design the overall experience, and it's important to describe, graphically if you can, what this is going to do for the users.

Later on, you need to be very, very detailed in specifications that you pass along to engineers, and so, that probably calls for a very different level of granularity in the artifact. Instead of delivering a prototype, you might deliver a table that has timings laid out in milliseconds. It's not a one-size-fits all kind of thing.
Man 4: This question's related to that one. You touched on duration. I'm wondering, to extend your metaphor, experience, should we be thinking about it as classically played or improvised in terms of how long somebody should be engaged, or how long to engage someone?
Peter: Nancy Dickinson, whom I worked for at eBay, liked to say, and I don't know if she made this up herself or if she's quoting someone else, she said that, "We don't design user experiences. Instead, we design the opportunities for those user experiences."

There are always going to be meticulously designed user experiences that are not on rails, and people will go down different paths. Sometimes usability testing will reveal this. Sometimes you'll create a rich system, and people will focus on some aspect that you didn't intend. And so, you didn't fully design it. Those are always surprises.

We've got to work with people, unfortunately or fortunately. I actually, tend towards the latter. And there are always surprises. I'm afraid I can't get any more specific than that.
Woman 3: We work with Kevin's approach of doing the user storyboards and making the comic strips. And we design wire frames for the screens that would help that story unfold.

We did this a couple years ago, and I forgot about it. It's called protocasting, where you take your design deliverables, even if they're not animated with Flash or with Axure, you take them and put them up on your screen and do a video and walk through the story. I would be narrating the wire frames or designs on my screen as I'm recording a video telling that story from the comic book.

I didn't come up with the term protocasting, but I can't remember the name of the guy who did. But then, that video is your deliverable to the developers. Even our offshore developers got it. They're like, "Oh, I see what we're doing now." But you could also send it to management, or your client or whoever.
Peter: That's great. What's it called? Protocasting?
Woman 1: Protocasting.
Peter: Good. If somebody wants to look up where that came from, we can do some instant research, here. That sounds like a terrific technique.

One more. This is all that's standing between you and lunch, so. I will try hard not to go over.
Man 5: Very quick. What do you recommend as a rhythm and flow for compiling databases? You talk very bad of the engineers and databases, all those things. But this is important activity, and many people need to do. Maybe you have some suggestions about that.
Peter: Well, I don't know if it relates to rhythm and flow, but in my experience, particularly with engineering driven product organizations, the design of database oriented programs seems to be completely oriented towards fulfilling the needs of the database, as opposed to fulfilling the needs of the users.

What I would do when designing a form to fulfill the needs of the database is insert the user. Show the user getting more and more frustrated with information, that they don't believe is important, but the database has to have. Use that as a lever to try and convince other parts of the product team to work on ways where the user isn't subjected to that kind of agony.

Even though it doesn't necessarily have to do with rhythm or flow, it is a way of making the user's needs paramount, where in so many cases, it's the needs of the system that are paramount, by default. That's where we can insert value.

Good. Well, I want to thank you all for attending. The summary is that interactions can have rhythm, and that flow is a great thing. Flow happens in people, not computers, remember that. Include people in your artifacts. Motivic rhythm is on the rise, and maybe we can use existing animation tools.

Here's my contact information. If you tweet, #RhythmAndFlow. Thank you very much.