Attended the Observe, Collect, Draw Workshop

Posted on by Rob Stenzinger

After being a student in the Observe, Collect, Draw Workshop I have a new appreciation for analog data. Two instructors ran the workshop: Giorgia Lupi and Stefani Posavec, both are experts in working with data, visualizing, and finding deeper insights through the process of gathering and visualizing data. They also created the fascinating Dear Data project where they would capture personal observations, process the data, and visualize it on a postcard for one another every week for a year.

My doodle notes overview, captured throughout the workshop day

My doodle notes overview, captured throughout the workshop day

The workshop had sections of lecture, covering inspiration, theory, and process for gathering and visualizing data mixed with sections of hands-on exercises to experience the data gathering and visualizing first-hand.

Choosing some personally relevant data was the first challenge. The instructors suggested using your text/sms history with someone, your music listening habits, or photo taking habits as options to consider digging into. I chose to learn from my 50 overdue tasks in Omnifocus.

observe collect draw - data and visualization progression 6:26:2018.jpeg

From there, we all gathered data and observations about the data. This analog approach is different than how I've worked with data in the past. For example a while back I did an experience inventory project where I gathered 240 experiences from the year past and gave them about 20 attributes of rating and categorizing. It was a digital process of data, scripts, and reports. This new project was all pen and paper which felt different in a more focused on the topic sort of way.

Once I had all the data, the key insights I started to notice were I had a potential cluster of tasks based how overdue and based on how much or little I wish to do that given task.

Then we moved into the data visualization part. How to convey the insights and possibly discover more about the data and insights while exporing ways to visulize it all.

After a process of refining, here's the direction I landed on. Two axis of the drawing, one had the amount of days delayed 1, 7, 14, or 28... the other is the rating of how much or little I wanted to engage with the task. Layered on top of this is the nuance of clarifying why I didn't engage or what might be blocking me from engaging with the task.

I thoroughly enjoyed this workshop and I'm glad to hear the instructors have a book coming out this September.

Discussion off

EYEO 2018 Sketches and Doodle Notes

Posted on by Rob Stenzinger

Once again I've had the privelage of attending a super awesome event called EYEO. It's a conference that explores great work in the areas of design, technology, data visualization, and putting it all in a human and historical context without any sense of hype or baloney. I've shared many notes and thoughts on multiple podcasts in the past about Eyeo.

I plan on sharing more thoughts on this coming Thursday's Lean Into Art podcast. We broadcast via Youtube live on Thursdays at 9PM Central time.

Discussion off

EYEO 2017 Sketches and Doodle Style Notes

Posted on by Rob Stenzinger

EYEO is a conference style gathering where artists, engineers, scientists, professors, enthusiasts of all types of backgrounds gather to learn from one another via talks, social events, and hanging out in the hallways of The Walker Art Center in Minnepolis, MN. Some common topics you'll encounter: making cool installations, coming upon interesting insights while making things, building things to serve and awareness of challenges of given communities. Lots of design, art, data, but not limited to those concerns exclusively.

Something I posted on Instagram along the way this year sums up a lot: "Still sketching away at #eyeo, an event that continues to teach me things that I didn't know I needed to learn and then wonder how I could have lived without learning."

For a few years now, it's been my habit to draw during talks with the intent to connect further with what is being said, shown, via words and doodles. Also, to discover connections between those things I'm capturing: noticing what I'm noticing.

Here are sketches I captured at EYEO 2017. Likely they're most useful to my memory. Maybe next most useful to those who might have been there to recall stuff based on these notes. Then in a random way maybe useful to those who are curious to check out these great speakers present but haven't yet had the chance.

Discussion off

Animating SVG Paths of a Sketch via CSS

Posted on by Rob Stenzinger

Recently I've been exploring CodePen as a way to quickly experiment with HTML, CSS, and Javascript in a way that's fun and convenient.

My latest experiment was to learn more about animating SVG paths. The details of what I learned are in the code comments of this Codepen.

Here's the original sketch I converted to SVG using Cocopotrace and Adobe Illustrator:


And the Codepen experiment:

See the Pen SVG Sketch CSS Animation by Rob Stenzinger (@RobStenzinger) on CodePen.

Discussion off

Making an Experience Inventory to Reflect on the Year Past

Posted on by Rob Stenzinger

TL;DR: I developed an Experience Inventory to help me pull data out of my journal, calendar, and various notes for the past year. Once I had this data I was able to explore it and compare what the data said to how I feel about different times and topics throughout the year.

Data nerds know that’s awesome. Data what-evs know they’ve clicked the wrong link.

Spreadsheet Fish - Looking for Data

Spreadsheet Fish - Looking for Data

How the Experience Inventory Came About

Every December I take a look back at the year. Each year the look I take is a little different then the other years. Last two years I used the self interview guide that Susannah Conway publishes. I like that approach yet I also wanted to get more data out of the process.

I do UX research at my day job and a technique I’ve found useful is adding quantitative observations to qualitative sessions. The observation notes are helpful in a qualitative way to convey the narrative of the experience. Then adding quantitative data like “how successful did they complete the task” and “pick or add a label to describe the participant’s reaction” helps with summary observations across the experiences of all the participants.

It was a natural hey-what-if thing for me to go from self interviewing to then add some quantitative questions to the mix - to help me summarize and group my experiences of the past year.

Either that or I while reflecting on the year past - I slipped and fell and made a spreadsheet.

What Did I Want to Learn

To craft helpful goals for this year, I wanted to feel better informed by what happened in the prior 12 months. Who did I connect with? What kinds of connections were they? What was particularly challenging or particularly easy?

To answer those questions, I considered what data I’d need to gather, what questions to ask to gather it. Three categories of questions emerged:

  • Questions to gather basic data about the experience (when, where, what topic)
  • Questions to explore about how I relate to the experience (feeling, effort, difficulty)
  • Questions about how others seem to relate to the experience (did it connect with others, who as a group, who specific, what reaction, how much reaction)

Steps to Capture the Experiences

Where do I have information about what happened in my life during this last year? In a bunch of places. Evernote, nvAlt notes, OmniFocus, and especially my DayOne journal are all private places I capture data. Then there’s Twitter, Instagram, blogs, and podcasts for things I share publicly. Finally, I have the day to day administrative sources of data such as my calendar of appointments, emails, and files on my computer sorted by date.

To capture experiences:

  • Open one of the data sources and browse through it, while keeping my Experience Inventory spreadsheet ready to enter the data.
  • Take note of an experience
  • Add data about that experience
  • Review progress
  • Fill in gaps
  • Repeat

It took about 1 and a half calendar weeks of this capture work for ~20min-1hour a day to get the amount of data that felt like enough. I gathered 240 experiences and captured 19 answers/observations about each experience. A total of ~4,560 points of data.

Experience Inventory Questions

For each line in the spreadsheet, the following questions are columns. The first column is the experience, the other 19 are questions to gather insight on that experience. Each row following captures data about the experience.

Info About the Experience
1. What did you do or experience? an event you experienced, could be any time frame from moment to a month… keeping to roughly a day or week is most useful
2. What month? date or when phrase
3. Where did it take place? online, offline local, offline travel destination
4. Additional notes or details optional
5. Life role/purpose? What big aspect of your life best categorizes this experience? For example: personal, professional, main gig, side gig, friends, family, finance, learning, fitness, etc.
6. Project? Was this part of an organized set of tasks, goal, or overall project-like commitment?
7. Topic? If you gave this experience a recurring theming hashtag, what would it be?

Affect on Me
8. How do you feel about the EXPERIENCE overall? rate 1-5 1= very negative 5 = very positive
9. How easy or difficult was it to produce? (Easy: you didn’t have to learn new things to produce it - Difficult: you had to learn a lot and invest a lot in learning to produce it) skill… rate 1-5, 1 = very difficult, 5 = very easy
10. How much EFFORT did it take to produce or participate in this experience? rough numeric estimate in hours of effort…
11. How do you feel about the EFFORT? rate 1-5 1= very negative 5 = very positive
12. How much did it cost you monetarily? numeric
13. How much did you earn? numeric

Affect on Others
14. Did it help you connect with other people? y/n
15. What was others reaction to it? for example: conversation, celebration, purchase
16. How much reaction was there overall? rate 1-5: 1 is no reaction, 2 is little reaction, 3 is some reaction, 4 is a good amount of reaction, 5 is incredible amount of reaction
17. What was the result of the reaction? for example: learned something, networked, earned pocket change, earned a living, etc.
18. Why did you take part or make this experience happen? for example: a long established goal, a new goal/revision, belief in it, improvising, fun
19. Who as a group did you connect with? A group name or list of groups of people or communities, separated by comma.
20. Who individually did you connect with? A person’s name or list of individual people, separated by comma.

What I learned From the Data

The data I gathered felt like a great reminder of who I connected with throughout the year and what kinds of things I made for what purposes. Exploring the data, I found some insightful queries to make these reports:

The Best Stuff Report: Taking a slice of what experiences related to projects I felt best about that others responded well to, then sort them by how much effort they took.

The Worst Stuff Report: The crap list. Things that didn’t go well that I either want to do better in the future or avoid entirely.

The Meh Stuff Report: Things that had to be done, not the worst, not the best.

The ready-for-my-day-job-review report: Many of the experiences I captured related to my day job/main professional commitment. Now I have a list of accomplishments and events throughout the year for my self evaluation/performance review.

What I learned from the Process

App-making distraction: I got excited about this process and how it felt gaining insights along the way. Pretty soon I found myself designing an app to build based on this process, daydreaming ways to visualize the data, and sketching. To set that aside for now, I stopped summarizing my data in Python, sketching UI, and switched to using Base and Excel. That kept me focused on exploring the data, not building an app.

Solid start to the process: Doing an experience inventory is definitely a flexible process. It was no problem gathering data from a variety of sources into one big spreadsheet, then learning from the reports on the data.

Getting spent diving through the data: To do this in one effort over a few weeks to dig through a year of data both fun and overwhelming. It was a bit much to reflect on such a big-time and sifting through so much data.

Do this more often: I need to repeat this process, tweak, improve upon it, and benefit from the insights more often than once a year.

Keep an eye on enough-but-not-too-many observations: In a given session of data gathering, it’s easy to get fatigued making observations on so many records.

Unclear if 240 experiences is too few or too many: I captured about 240 experiences, which feels like a lot yet is clearly not exhaustive.

Would I do this again?

It felt like a useful exercise, yet a bit overwhelming to do a whole year at once. To really know the answer to “should I keep doing this”, I need to do this again applying what I’ve learned this time.

My plan: I’ll be giving this a try at the end of March. Will I still find it useful? Will it feel less intense since I’ll be taking a much smaller slice of the year into account? I’ll be sure to share an update, we’ll see how it goes.

What I do know: I’ve found it possible to sift through piles of stuff I’ve captured throughout the year, capture some structured data, and learn more about what I experienced. This feels super helpful for planning the year ahead. —
Experience Inventory Spreadsheet - Download/Clone from Google Drive

Discussion off

Journaling About My Phone

Posted on by Rob Stenzinger

What follows is a journal entry I thought worth sharing in my blog. If you're a listenter of the Extra Lean podcast, this is the post I was debating about sharing in "Extra Lean 68 - Why Bother Holding Back at This Point?". Also, this post has swears. In my journal, I curse like a sailor wanting to do standup.


Being a parent is amazing on many levels. One level that’s teaching me something elusive, more than I’m able to grasp at the moment, is the experience of teaching my eldest daughter to wipe her butt well when she poops.

It’s about patience and practice. Also, it’s something I leave to my wife when I have the chance.

Tonight, Kate’s in bed fighting a cold. I am downstairs facilitating bed time.

Tonight clearly number 2 nature called and my daughter called me in to the bathroom to help with wiping. I mention that we’re going to have her practice a couple wipes. If she still wants help after that, no problem.

She did and she did.

Feeling a bit tired, I walk up as she shows me her butt, it all is what it is. A parental job to be done. I grab some TP from the roll and that’s when my phone slips out of my shirt pocket.

Bounces off my daughter’s ass and into the toilet.

Un. Fucking. Believable.

Phone in the toilet. It did not rest within clean waters.

That’s when time slowed down. I debated with myself if I should just flush to and say good bye or rescue the phone. I rescued the phone.

Then wiped my daughter’s ass.

She asked if I was mad - I said nope. She apologized and I said - totally not your fault sweetie. She seemed relieved.

Suddenly she needed to share the event with her mom.

I said go ahead as I needed a minute to dry and disinfect my phone.

When I got upstairs they were both laughing so hard they were in tears. I had a chuckle too. Quickly both said they felt bad and that they totally understand if I need to get a new phone.

Very sweet of them. We’ll see what happens. So far, my disinfected phone is working fine.

The journal entry is from the 10th of August, the phone that went for the unfortunate swim was an iPhone. A temporary Android Phone was involved in the aftermath. That's where I'll leave the tale for now.

Discussion off

Collaborating More Like Columbo

Posted on by Rob Stenzinger

For Better Handoffs and Team Cohesion

Better Handoffs, Science, and a Detective Show

Let’s explore common pain points in team collaboration and how we can improve our own habits through empathy and scientific method.

I propose: empathy and scientific method are not just useful, they are the right thing to do to help us be more intentional and more accountable in our shared creative works.

Also: taking cues from Columbo. Yes, the 1970s TV show. More on that later.

Let’s begin our exploration with a question: what happens when we handoff something in a creative process?

Collaborative Handoffs


Relay races, factories, and business teams have something in common. Work is assumed to be progressing if we observe something moved from one stage to the next - that movement is often a Handoff.

Where do handoffs happen?

  • Role/skill specialties lead to handoffs.

  • Accountability-shifting decisions lead to handoffs.

What do I mean by handoffs?

Universally: a handoff is a commitment to share something that is being expected by someone else. As individuals we may have an affinity or interest in some steps or parts of a problem and not others.

Some of us are more inclined to planning vs. making or troubleshooting vs. strategizing. That’s helpful for forming groups of people with the collective skills to take-on a shared mission. Teams allows us to solve more complex problems.

Rapidly incoming handoff

Handoffs happen at stages of creative progression.

Handoffs are where one discipline connects with another to collaboratively work in serial or parallel. Handoffs are possible at stages of creative progression and at discipline boundaries. Handoffs are decisive moments.

Project Progression

Name an industry and you’ll likely see some amount of role specialization and some need for different specialties to work together on products and services.

Regardless of the specialty or industry, roles and handoffs are everywhere.

Same words, separate ideas

In creative media industries such as in comics we can see specialized roles:

  • Writer

  • Penciler

  • Inker

  • Colorist

  • Letterer

  • Editor

In making digital products we have a variety of specialized roles:

  • Sponsor

  • Product Manager

  • Backend Development Roles

  • Frontend Development Roles

  • Visual Design

  • Experience Design

  • Devops

  • And many others - digital products is a space of many spaces within with different ways of interpreting the idea of making digital products.

I like to frame handoffs as decisive moments. Decisive moments happen as choosing paths among options both during handoffs and even before work needs to be handed from one role to the next. Decisive moments are a great place to be informed by one another’s roles.


Decisions via Compromises and Constraints

You’ve likely encountered and needed to use compromises in projects where constraints would have been more beneficial.

Constraints help guide the key choices that make a product or system into something that people find useful, useable, and maybe even delightful to use.

Compromise frequents projects where you find either a lack of empathy among collaborators or when the collaboration is being driven as a negotiation instead of a shared purpose.

A constraint is a useful creative limitation or reality. When you discover, understand, and embrace a constraint, it helps focus your creative problem solving and helps the team produce better designed solutions.

Whereas compromise also grows from misunderstandings and miscommunication, such as not understanding one another’s roles.

How do we relate better to one another’s roles? Framing intent is a good place to start. Ask: What’s driving you in your role? What are goals and principles informing what you’re offering?

Framing Intent

Why are we doing what are we doing? These questions are a good place to begin to understand why others are doing what they do in their roles.

Coming From Different Perspectives

It’s easy to rationalize why a project isn’t going well.

It’s also easy to see things differently and disagree as a result.

Different roles value different things: their specialized methods, tools, and language can define, help, and distinguish their role.

Producing collaboratively with all these differences in roles is a sort of model UN exercise. Each of us promoting our values and attempting to share artifacts across our role cultures.

The risk of this much role-centric effort: it leads to an isolated definition of success instead of holistic which leads to compromises instead of constraints.

Collaboration across roles helps us identify constraints.

Applied Discipline

pure discipline vs. applied discipline

Being role centric means to advance knowledge within a given domain of study VS emphasizing a shared intentional outcome or goal. Much like the contrast between pure research and applied research.

PURE RESEARCH - expanding knowledge within a specific domain and therein lies the definition of success.

APPLIED RESEARCH - which may use the same knowledge but mash it up with a goal or need which dictates success through external measures such as audience size, profit, or learning in order to achieve those external measures.

In the APPLIED discipline realm, we’re shipping things and learning from what we ship.

To do this across and with our various roles and disciplines it takes curiosity, empathy, and investigative habits.

Enter Columbo

Which one is Columbo?

Which one of these doodles represents Columbo? Do you recall some of the things Columbo does? He’s a detective character, played by Peter Faulk in a long running murder mystery television series in the 1970’s - 2000’s.

There's Columbo!

As a detective he often showed his investigative habits and immense skill for interviewing. He pursues his goal to solve the crime with relentless dedication. He is not a Terminator character with a goal, Columbo doesn’t pursue a mission unquestioningly. Nor is he a Dirty Harry character with a goal, he doesn’t perform his role with extreme aggressive judgment.

Progression of Columbo

Columbo started the "howcatchem" twist on the whodunit formula.

If you’ve not had the pleasure and a quick review for those who have, here’s a synopsis of the Columbo plot structure:

First the Crime

We don’t see Columbo in the first act. We see the perpetrator and their normal life until they choose to commit the crime.

Enter Columbo

Then we see detective Columbo, often having a seemingly absent-minded professor moment as he begins the investigation.

The stakes get higher

The stakes get higher and higher as Columbo explores the situation and the perpetrator feels they’re doing a good job fooling the annoying inspector.

Just one more thing...

Until finally we get our "one more thing" moment, where Columbo looks like he’s about to “not” capture the suspect in a net of logic and evidence. But he does! And once again Columbo prevails and we get to learn the howcatchem result.

The Columbo Combo

Two significant factors in his success: his approachable demeanor as he’s interviewing suspects and he’s incredibly observant.

Relating to Columbo

What does that have to with collaborative creative projects? Traits that define the character of Columbo also outline good collaborative habits:

  • ask questions, test ideas

  • be very curious about the people and world around you

  • be observant and find evidence

  • have an approachable manner, show empathy

  • gathering evidence is a good way to build confidence in a direction

Project Progression Revisited

How would Columbo examine a handoff? I think he’d ask if this going well, then explore why. Also, if the effort is going poorly he’d ask why, gather observations, then explore them to see what holds up.

Project Progression, now with more Columbo

Listen, ask questions, and listen some more.

Columbo keeps at it

Don’t stop talking with people across all the roles.

Columbo keeps at it still

Let me state that again. Don’t stop talking with people across all the roles.

Integrate what you’re gathering. Share it and see if others relate to what you’re investigating and how they relate to your findings.

Columbo keeps at it even still

Just like Columbo you’ll be gathering, testing, and combining evidence of what’s working and what’s not working. It’s a sort of superpower to work across any role.

Columbo investigates across all the roles

Watch Columbo work. He’s so collaborative-compatible as he interviews he’s so approachable, everyone answers in one way or another. He’s right there listening and observing.

Key traits

Whether you are a troubleshooter, investigator, designer, analyst, or software engineer, researcher, in any collaborative effort role:


Result of the key traits


However… Being human is a complicated business.

Gathering evidence is hard. Withholding judgment is hard. Why do they remain difficult even after we know they’re useful and are ready to try?


Even though we all perform some discipline or use processes we’ve studied and practiced: no methods or logical thought can stop our emotional side from influencing us.


Because: we all have biases and commit logical fallacies.

Cognitive Biases and Logical Fallacies

And logical fallacies...

Cognitive biases can lead to perceptual distortion, inaccurate judgment, or illogical interpretation and logical fallacies result as an error in terms of reasoning.

We aren’t only filtering with biases and committing logical fallacies as we go about our day to day. These mistaken beliefs can mix with our habits and disciplines. Some examples follow.


The Dunning–Kruger effect is a cognitive bias - that puts us in the situation of: how do you know the extent of your skill when you don’t yet have enough skill to accurately understand your skill.

When the Dunning-Kruger research was being performed, it was also nick-named "American Idol Syndrome" where someone doesn’t have an accurate understanding of their own skill because they don’t have the skill to understand AND likely don’t have critical feedback.

That’s illusory superiority.

The opposite is also true. Another Dunning-Kruger effect is when someone who is highly skilled rates their ability as far lower than they should.

Sunk Cost

Sunk cost fallacy is also known as loss aversion. A classic example: if someone buys a non-refundable ticket to an event, many would use it even if something better comes along that they’d prefer attend.

On projects I consider the Sunk Cost Fallacy when I hear the argument: "but we made it this far… or spent this much of the budget already" as the main reason for continuing. That’s when I like to explore with the team to find more evidence and discuss what we discover to hopefully break out of the fallacy.

Empathy and Role Biases

Assumptions about roles

Through experience and some self awareness I know I can be biased for and against other roles in making projects.

Do you look suspiciously at any role or work products from any role in particular?

For myself: I look askance at planning-focused roles vs. make-focused roles.

I’d love to be perfectly objective - at least that sounds like it’d be a useful superpower. What I try to live up to and advocate for is to discover our biases to be able to better manage them.

Empathy helps.

Lack of empathy

How can we improve our empathy?

Empathy Map

We can borrow useful tools from the User Experience discipline to amplify our empathy for a given role or collaborator.

One tool in particular I find of use is the empathy map diagram. It’s a mental exercise that may not give you all the answers about someone’s perspective but it does give you a bunch of ideas to help move the conversation forward.

How do you make an empathy map? You need to make four lists. I like to start with the two lists that are observable as an outsider: what is the person you’re observing saying and what are they doing. From there, I can attempt informed guesses as to what they may be thinking and feeling.

Through this, you can capture questions that attempt to relate and understand their particular role.

For example, if conversing with someone in a visual design role with empathy is discussing a recommended change with someone in an engineer role with empathy:

Engineer Collaborator: *"I saw your feedback on the latest release - how strong of a concern are you expressing and are you recommending we delay this release?" *

Visual Design Collaborator: "I just learned we’re getting complaints and usage stats that show the call to action page is getting too many abandons. We need to redesign and implement a fix as soon as possible."

Engineer Collaborator: "I’m open to that - though I do want to understand the trade-offs and risks in how that may delay us vs. we ship on time and get it next iteration".

User centric applies everywhere

If you’re a fan of usability, pleasing design, and utility in the things we make, you’re already a fan of having empathy for one another.

We’re all end users for one another’s skills as we’re building stuff together.

Be Informed by More Than Biases

Improving on your own biases...

Seeking to improve upon your biases is a good place to start. It’s no easy task, but it can be fairly straight forward.

It’s a habit we’ve seen in both scientific method and art.


Critique is how we can acquire some of Columbo’s super skills.

By critiquing our own arguments we can explore biases and fallacies Through that… YOU WILL PROVIDE AND HELP OTHERS PROVIDE BETTER AND MORE INCLUSIVE RATIONALE. This unlocks something even better than being an individual Columbo… your group will be FUNCTIONING AS A TEAM vs a COLLECTION of DISCIPLINES.

It’s true we all need practice with critique and to get used to providing feedback within your team. Do it often, until it feels comfortable. Critique is a critical skill we all need to learn how to give and receive. I will provide more specifics on good critique soon. Before that, let’s consider how teams help our collaborative habits.

Teams Help with Critique

Teams! Huzzah!

Teams are critical to forming and supporting these habits. We are social creatures. Our roles don’t stand alone. Even Columbo doesn’t work alone.

Teams help with practicing.

Skills, cultures, tools

You and your team practice and share skills, cultures, and tools.

Skills combined with tools and culture lead to advocacy across roles: code advocacy, design advocacy, business knowledge sharing, all kinds of advocacy.

Teams also provide a culture - what do you celebrate and how? Do you celebrate the reason you’re working together?

Shared purpose

As a team, you share purpose.

Shared purpose can be a wide boundary. It begins with you and your team but it extends to everyone contributing to the final result.

The more clear and widely understood the shared purpose, the easier it becomes for the team to discuss tradeoffs and critique work in progress.

Giving and Receiving Critique


Feedback is how you know you are progressing or if you have arrived at a stage of completion or commitment.

Whether it’s expert opinion or other evidence from audience reaction and at any given stage, feedback is useful.

Feedback is observable evidence. And making space for feedback creates a place to practice good critique habits.

Good critique is a useful exchange of ideas

Critique can be an emotionally charged word. It doesn’t have to be. Good critique is a useful exchange of ideas.

What does good critique look like? It looks like a conversation.

What does good critique feel like? It feels like an interesting conversation.

Questioning and exploring a collaborator’s rationale builds context for critique.

Within that context it can make it easier to have potentially hard conversation because you create a safe place, allow for vulnerability, and can share ideas openly.

The observations (or critique) shared maybe not be new "answers", sometimes they are questions, new questions can be even more valuable for someone looking to make something better.

Context for Critique: What - Why - How

So how do you create a safe environment for critique? Start with these three parts of asking for critique or giving critique: explain what you made, why you made it for a given audience, and how you made it with given constraints.

Likely choices, tradeoffs, and resulting work will have many layers to it.

Good critique will be navigated by both the person asking for it and the person providing it.

Bad critique... RAHR!

Why makes bad critique bad? Delivery. It could be delivered in a very emotional wrapper. Or stuffed in an envelope of indifference. It could also be inconsiderate of the foundational constraints and tradeoffs necessary in the project.

Our motivation for requesting and for providing the critique is a major influence on the quality of the critique.

Bad critique, I can't deny

I’ve given bad critique. It wasn’t due to shouting, paper-chucking, or indifference. It was due to …. Once upon a time I was a tech and design lead for a content management system platform and fortunate enough where the platform became a defacto standard for the company where I was working at the time.

A project came to me for feedback and at the time I lacked the empathy to really understand their rationale, needs, and constraints. Instead I kept to the safety of my role as a multi-hat-wearing-lead and as a result, we didn’t have a the kind of conversation we needed. What’s worse for me looking back on it, I know that I also missed out on an opportunity to receive their critique in a meaningful way.

Not very Columbo of me. Just as good critique is a conversation, bad critique is an announcement.

Look out below.

The worst kind of announcement style critique: swoop and poop.

Swoop and poop is dropping off a package of reaction and assumption. Even if it is insightful, it’s tough to receive without the context of a trusting conversation.

To avoid or reframe a swoop and poop: remember you have options to renegotiate the situation you’re in to gather feedback. For example, you can offer to dedicate a separate time, place, and structure to explore the feedback.

Teams reflect, perspective, retrospective

Sometimes it’s awkward or intimidating to get the critique habit. Retrospectives are a great place to introduce critiquing habits to the team.

Critique of work in progress is useful as is critique in the form of reflection. A supportive team can learn from one another both via current perspective and by listening to be retrospective.

Retrospectives, are a time to gather the team and look back at the recent effort, activities, and results. Through that exploration, your team can list ways to improve what you do next and celebrate both what went well and one another’s effort.

Make Share Collaborate

Make Share Collaborate Manifesto

The Make Share Collaborate Manifesto is a useful set of principles that serve to better team collaboration.

One day I got inspired to interview teams I work with about what they feel should be part of a healthy system, why, and how that ideally flows, looks, and feels.

Those raw interviews grew into the Make Share Collaborate Manifesto.

Read it, sign it, critique it.

I hope you do. Between now and then I offer a key principle from the document: let’s work WITH one another instead of working FOR one another.

WITH changes the dynamic and makes critique and collaboration possible for everyone present.

Dig Deeper Into Rationale with "Why"

Makes for the door, like Columbo

If I were Columbo… at this point I’d be heading for the door. I’d also do a quick do-I-have-my-keys pocket patting check. Then after thanking you for your time, sure that you have a busy schedule, I’d pause.

Just one more question

I have just one more question to wrap this session.



Columbo asks why.

Why is like a magnet that sticks to how people see problems and solutions. It makes it easier to frame project decisions. You have a chance to see how your clients or collaborators see the situation.

Why is that?

Because why keeps us accountable the reasons that what we create.

The things we express are no longer implicit. Assumptions become explicit and out in the open to be observed and understood.

Why lets us open up our intent and see how that relates to our methods.

Why helps us connect more with our methodology, a technique, a given service, tools. It helps us accurately convey the benefit or value of those things.

As a habit, expect others to not just follow what you assume. Share both the narrative behind and the evidence behind what you’re proposing.

You’ll be demonstrating a huge step toward trust and accountability.

What are you intending and why?

Here is an example: a designer asks the engineer…

Designer: Why must the API take so long to return a result? We’re losing conversions in our checkout process. We discussed making the busy animation more compelling - can't we do something more?

Engineer: It’s a tough problem. We have old system integration performance, we also purposely slow some things down so attackers have a high cost for them computationally. Also, it’s just a lot of data behind that page.

What if they share constraints and design a solution together?

Both Together: Perhaps we could stream data or get it in small parts, start showing the user something useful sooner - not just as a distraction.

UNDERSTANDING - one another’s trade offs, constraints, is how to build holistic solutions via constraints, goals of business, human factors, and wider system issues taken together in shared context.

Why am I doing this? AND is there evidence to support my rationale?

Don’t forget to ask yourself why. It’s a healthy check in with yourself. It also helps practice for the time when someone else is asking you why.

Make informed handoffs and tradeoffs with any project role.

If you build and practice evidence-based habits you’ll be able to avoid blind spots in your reasoning. You’ll make better informed trade-offs and handoffs with any project role.

You know you're on the right track when the project decisions are based on shared purpose instead of negotiation across roles. When the team is more informed by constraints instead of personality and bias compromises.

Collaboration Resources


Great books and resources related to this topic:

Time to Be Columbos

Be Columbos

Collaborating more like Columbo is a combination of practices. Share and seek critique, explore your biases, and do so with empathy for yourself and others. Ask "why" and find the constraints of everyone that serves your creative project.

If we choose to be Columbos as we make things together…


… collectively we’ll be FLOCKS of COLUMBOS making better creative products with better handoffs.

Afterward and Thanks

After performing this as a talk both at Agile Day Twin Cities 2014 and on the Lean Into Art podcast, each occasion has led to questions from the audience.

One question in particular that has me pondering: two people from an agency’s UX group, both consulting on a client site presented a challenging situation to asking why:

"I can probably ask why once, then it’ll cause a lot of defensiveness in my stakeholders. What should do I do to help them be open to being asked why?"

Sometimes it’s not safe to ask why.

Trust in all directions is important but not always a guarantee. When there’s less than enough trust for any of us to respectfully ask one another "why?" I propose we still have options:

  • Consider switching from "why" to one of the other classic investigative questions: how, when, where, who, and what.

  • Consider requesting feedback on your observations based on what is positioning the team well or poorly to accomplishing the shared purpose in question.

Finding a way to build trust is critical. There’s a good chance that you’ll be able to build some trust through some conversation other than the "why" conversation. Once you’ve built trust, you might have helped your collaborator with lowering their defenses enough to safely explore “why”.

Keep the conversation open and safe, keep their trust, and be your own Columbo.

Thank you

Thank you reader! Also, thank you to DevJam and Agile Day Twin Cities where I initially shared this as a talk. Thank you to Jerzy Drozd for performing a version of this with me on our podcast. And extra special thank you to an incredible collaborator, editor, and inspiration who also happens to be my wife: Kate Shields Stenzinger.

Discussion off

The Make - Share - Collaborate Manifesto and its Initial Feedback

Posted on by Rob Stenzinger


With inspiration and assistance from some special people I work with now and have worked with in the past, I drafted a manifesto about collaboratively making stuff. It's been well received among a small group of people. So now I'm ready to share it with a wider group and looking to learn more about how it can be of use to you and how it can be improved.

An open space

Recently I took part in an event called Open Space hosted by DevJam. Open Space has an un-conference style format (talks and workshops not planned in advance, just show up with something to say) so I signed up to give a talk. The topic I chose: "What Should Be Next For the Make Share Collaborate Manifesto?".

During the session, I shared the basic story behind how this manifesto (MSC) came about, an overview of what it is, and questions I have about ways to improve it.

The group had a lot of good conversation, thoughts, and feedback...

Themes from the Open Space session feedback:

  • MSC covers more than software development concerns
    • It mentions roles, sustainability, creative stages, critique, and a variety of concerns such as empathy not traditionally voiced along side software development.
  • MSC needs examples and demonstration
    • Project stories and scenarios. Somehow provide them while not being overly prescriptive.
  • MSC should refer to supporting materials
    • Books such as Creative Confidence, creative process roles and modalities such as those mentioned in A Whack on the Side of the Head.
  • MSC needs to call out inspirations
    • The Agile Manifesto, etc.
  • Among those inspirations, in particular: how is MSC different than the agile manifesto?
    • It seems more about creative collaboration in general, pertains to software development, yet also more.

Additional thoughts

  • I intend to reflect and share more about MSC and how it came about and ideas of what to tackle next. That'll either be here or on the Polytechnicast soon.
  • DevJam's Open Space was an awesome event. If you're in the Twin Cities Metro area and into making software I highly recommend checking out their events.
  • If you're into the Make Share Collaborate Manifesto - sign it and share it. Either way - please offer your reactions and feedback.

Discussion off

A set of creative web experiments

Posted on by Rob Stenzinger

I started a project on GitHub yesterday, inspired by the 180 Websites in 180 Days project. Seriously if you have yet to check out Jennifer Dewalt's project, you should. It's pretty great on its own, yet what makes it extra amazing: she taught herself to code via that project.

So as I said - her project inspired me. Plus I have a thing for creative challenges.

After considering what I'd do with such a project, I took a few days to consider if I had enough ideas for a bunch of web experiments/challenges. I drafted enough of a list (at least 50 ideas) where I think it's worth a go.

My initial two experiments are live. First I made a color animation toy that tweens colors via the jquery.animate-colors.js plugin.

Preview of the animation - thought the colors randomize each time you visit and when you click the page.

Preview of the animation - thought the colors randomize each time you visit and when you click the page.

Today I built a page that uses a relatively new modern web browser feature: built-in speech synthesis. This experiment is most exciting when viewed in Safari as it chooses a random voice. In Google Chrome there's only one voice, it sounds good yet there's no surprise.

Discussion off