Lessons from the 2023 Animation Workshop

The Animation & Rigging module had a design workshop a few weeks ago, with participants both remote and in person. We accomplished a lot of important design work, and generally had a good time together. But there are also things we think we can do better next time.

This post is about those takeaways and some accompanying ideas we plan to try next time. We hope this will be useful not only to the animation module, but also to other modules and projects.

Listen to Each Other

“Listen to each other” sounds obvious. And indeed for some people this comes naturally, and I believe most of our participants fall under that category. But for the more vocally inclined (such as yours truly), this needs to be more intentional.

Here are some of the ways we failed to listen to each other at the workshop:

• Interrupting each other.
• Talking over each other.
• Not making sure we understood what was said before responding.

These behaviors aren’t coming from a bad place. They can simply be due to excitement and passion. For example, if someone says something that sparks an idea, you can feel very eager to share that idea. And it often feels like it’s part of the flow of the discussion: after all, it’s something someone else said that sparked the idea.

But in reality, this leads to interrupting, talking over each other, and just generally not listening well. And in addition to simply being frustrating to be on the receiving end of this, it’s also counter productive because it significantly increases the chances of misunderstandings (a.k.a. talking past each other). It also tends to silence the quietest voices, which means we’re missing out on valuable ideas and insights from those people. And all-in-all it just makes the workshop less effective.

So for the more vocally inclined among us, we want to be a lot more intentional in the future about practicing good listening skills. Including but not limited to:

• Making sure we let people finish what they’re saying, and listen while they do so. Even if we have a Super Cool Idea™ we want to share.
• Making sure we understand what was said before responding, especially when the response is critical. For example, by asking clarifying questions, repeating back what we think they meant, etc.
• Leaving space for the less vocally inclined to speak.

Pay Attention to Gut Feelings

Something that happened several times during the workshop is that someone would have a gut feeling (either positive or negative) about a proposed design direction, and the others in the group would immediately ask for their reasoning. The person with the gut feeling would then get flustered and scramble to put together some chain of reasoning to explain their gut feeling.

In retrospect, we don’t think this is helpful.

For one thing, even though this isn’t the intention, being put on the spot like that can be unpleasant and make the process feel adversarial. Particularly if no one shares your gut feeling. And all other things being equal, we want our workshops to be a positive experience.

But just as important is that people in this flustered state are much less likely to figure out the real reasons behind their gut feelings, because being flustered and forced to think quickly interferes with thinking clearly.

This doesn’t mean that wanting solid reasoning is bad. Quite the opposite! Rather, this means we want to approach things in a way that maximizes rather than minimizes the chances of discovering the real reasons behind those gut feelings.

So we think a far more useful approach is to treat people’s gut feelings as a useful signal that we may be overlooking something. And rather than demanding that they produce their reasoning alone and on the spot, we instead cooperatively work to figure out what we might be overlooking.

The worst-case outcome of this approach is that we waste some time if it turns out the gut feeling is entirely devoid of merit. But we think more often than that, this approach will help us discover additional relevant considerations and trade-offs in the design, even when the gut feeling isn’t completely right. And that’s useful regardless.

Try to “Break” Your Own Designs

It’s easy to get excited about your ideas and designs. And that includes collectively as a team. There’s nothing wrong with this: it’s good to be excited!

But with that excitement comes the danger of being overly optimistic, and being blind to drawbacks and problems with the design. Some of that is addressed by designing in a team: one person’s blind spots can be caught by other people. But it’s naive to think that you won’t have blind spots as a group as well. Especially when you collectively start to feel really good about a design.

So something we want to make a part of our process (and this extends beyond workshops) is intentionally trying to break our designs once we feel good about them. To be a little more concrete, that means trying to find as many drawbacks and failure cases of the design as we can:

• Situations where it’s awkward.
• Situations where it outright fails.
• Situations where an alternative design works better.
• Corner cases we didn’t account for.
• Points of fragility.
• Bugs in the design, where it doesn’t even work the way we thought.
• Etc.

In short, trying to take as pessimistic a view of the design as we can, and seriously examine and investigate it from that perspective. Or as Sybren put it, approach it like a software tester would.

The purpose of this is to ensure that we have both eyes open. All designs have trade-offs and weaknesses, and we want to make sure we are aware of those and that they’re appropriate for our goals.

Of course, there are limits to what you can discover at the design stage. At some point you just have to build the thing and try it out. So prototyping is also critical for discovery and ensuring good design. But we nevertheless want to do what we reasonably can during design. And we think trying to break our designs is an important part of that.

Document the “Why” of Design Decisions

At the workshop we sometimes revisited earlier design decisions. This isn’t necessarily a bad thing. New ideas and insights can often impact earlier decisions.

What’s not good is revisiting previous decisions only to waste time rehashing and rediscovering all the reasoning that was already considered. Unfortunately, this happened quite a few times at the workshop.

This seems to happen for two reasons:

1. You have new people in the discussion who weren’t present for the initial reasoning. They see the end result, but don’t see the rationale and (understandably) may have concerns or just want to know the rationale.
2. You have people that were present for the initial reasoning, but all of whom have forgotten relevant specifics, and are therefore requestioning that decision.

In both cases, having documentation of not only what was decided but also why would be extremely useful. This doesn’t mean that prior reasoning can’t be questioned. It just means that it doesn’t have to be rediscovered, which wastes time. Especially when the reasoning is subtle or related to non-obvious corner cases.

Notably, this extends to decisions made outside of the workshop as well. In fact, the decisions we wasted the most time rehashing were made in the weeks and months before the workshop, because their rationale wasn’t fresh in our minds.

So we think both in and out of the workshop it’s good to make a reasonable effort to document the following things along with decisions:

• A concise description of why the decision was made.
• The alternative solutions/designs that were considered.
• The pros/cons that were considered for each alternative (including the chosen one).

Then when revisiting that decision later it’s quickly clear whether we’re bringing any new alternatives or insights to the discussion that weren’t already considered.

Importantly, this isn’t meant to limit revisiting previous decisions. It’s just to make it more efficient when we do.

Have a Designated Note Taker, and Pause for Note Taking

Having a designated note taker is just generally a good idea for meetings. But it’s even more so when trying to document the “why” of decisions as described in the previous section. So we want to do this at our next workshop.

Additionally, the note taker should have the power to pause the discussion to ensure good note taking. This might sound annoying, but we think the pauses will actually be helpful to everyone by providing room to breath, slow down, and think.

Finally, the notes should be taken online where everyone can see them (for example, on HackMD, Google Docs, or similar). This is helpful especially for remote participants who may be popping in and out of the workshop, giving them a way to get caught up at any time.

Have a Designated Meeting Wrangler

Along with a designated note taker, we think having a designated “meeting wrangler” would be useful. This would be someone that tries to ensure that we:

• Stay on topic.
• Use our time well.
• Listen to each other.
• Etc.

Basically, someone who does their best to ensure that things run smoothly and are productive.

Of course, we want everyone to take responsibility for this. But giving this task to a specific person can help avoid issues with diffusion of responsibility. Particularly when people get excited or things get intense.

Use a Stack of Discussion Topics

At our first workshop back in October 2022 we came up with a “safe word” to use when things veered off topic: durian. It meant “that’s important but not directly relevant to the current topic, so let’s discuss it later”. People would even self-durian when they realized they were going off topic. This was extremely useful at both the 2022 workshop and the 2023 workshop a few weeks ago.

However, we didn’t have a way to keep track of these durian topics or really any deferred-to-the-future topics. And this almost certainly led to things getting forgotten.

At our next workshop we want to experiment with a “topic stack”. The idea is that any time we want to defer a discussion topic, we write it down and put it on the stack. Then when we’re finished with the current thread, we can take the top item off the stack and continue from there.

This shouldn’t be strict, of course. We can always discuss something lower in the stack (or even not in the stack at all!) if it feels more important or like a more natural progression. But this gives us a way to track topics and ensure that nothing gets lost.

A topic stack also has some other benefits:

1. We can prepopulate it before the workshop, with the highest-priority topics on top. This could be a useful way to set the agenda.
2. After the workshop we’ll have a list of all the things we didn’t get to. This can turn into a list of remaining design tasks/questions, or be the basis for a “future work” section in the workshop report, etc.
3. It could combine well with the earlier-described approach to gut feelings. If someone has a gut-level concern without clear reasoning, we can acknowledge it as an important signal and put it on the topic stack to come back to later. That person can then more easily give their full attention to the current thread, confident that their gut-level concern won’t be ignored.

Use Break-out Sessions

At the earlier October 2022 workshop we made a point of sometimes breaking out into multiple groups, each tasked with exploring something different. However, we were a lot less intentional about this at the workshop a few weeks ago. As a result, we only did it twice.

In retrospect, we think the workshop would have benefited from doing this a little more often. It gives people a chance to work through and think about things in smaller groups in a less intense environment, and it can foster better communication. It can also parallelize work to some extent, although that has limits (for example, because sharing and additional discussion may still be needed after reconvening the group).

We don’t yet have clear guidelines on when break-out sessions are most useful. For example, if there are two competing topics of discussion, when should you do break-out sessions vs when should you put one of the topics on the topic stack? We don’t really know yet.

But we want to keep break-out sessions in mind as one of the tools in our toolbox.

Do Practical Set Up Ahead of Time

In advance of the workshop we made a list of things we wanted to discuss, prioritized them, and created an agenda from that prioritized list. This was super helpful in letting us hit the ground running and ensuring that the workshop was focused and productive.

However, we didn’t do the same kind of preparation for the practical side of things. For example, ensuring that there was a whiteboard in the meeting room we were using. Or ensuring that the meeting room’s computer was working properly for people joining remotely. Or setting up a camera for remote participants to see the whiteboard clearly. And so on.

This hindered the workshop somewhat because we had to spend time getting these things together and troubleshooting technology. In fact, for some things, such as a camera for the whiteboard, we never really had a good solution and just ended up winging it with people’s phones.

For future workshops we want to move all of these tasks to the days before the workshop, so they’re all taken care of ahead of time. This is pretty obvious, but nevertheless something we can do better in the future.

Conclusion

Over all, our 2023 workshop was a success. Even in the areas we can improve, everyone was always coming from a good place of enthusiasm and passion for the project. Nevertheless, we hope the ideas in this post can help our future workshops be even more effective.

Importantly, none of the above ideas are meant to be prescriptive. They are very much in the spirit of “tools not rules”. And that’s how we’ll be treating them. Additionally, some of the ideas are still untested, so it’s possible they won’t work the way we hope, in which case we may need to try something different.

But we’re excited to give these ideas a try at our next workshop.