We can’t control systems or figure them out. But we can dance with them!
- Get the beat.
- Listen to the wisdom of the system.
- Expose your mental models to the open air.
- Stay humble. Stay a learner.
- Honor and protect information.
- Locate responsibility in the system.
- Make feedback policies for feedback systems.
- Pay attention to what is important, not just what is quantifiable.
- Go for the good of the whole.
- Expand time horizons.
- Expand thought horizons.
- Expand the boundary of caring.
- Celebrate complexity.
- Hold fast to the goal of goodness.
Tuesday, July 20th, 2021
Thursday, October 15th, 2020
Ambient reassurance is the experience of small, unplanned moments of interaction with colleagues that provide reassurance that you’re on the right track. They provide encouragement and they help us to maintain self belief in those moments where we are liable to lapse into unproductive self doubt or imposter syndrome.
In hindsight I realise, these moments flowed naturally in an office environment.
Tuesday, September 29th, 2020
I think it holds up pretty well. There’s one interaction pattern in particular that I think has stood the test of time. In the talk, I introduce this pattern as something you can see in action on Huffduffer:
I was thinking about how to tell the user that something’s happened without distracting them from their task, and I thought beyond the web. I thought about places that provide feedback mechanisms on screens, and I thought of video games.
So we all know Super Mario, right? And if you think about when you’re collecting coins in Super Mario, it doesn’t stop the game and pop up an alert dialogue and say, “You have just collected ten points, OK, Cancel”, right? It just does it. It does it in the background, but it does provide you with a feedback mechanism.
The feedback you get in Super Mario is about the number of points you’ve just gained. When you collect an item that gives you more points, the number of points you’ve gained appears where the item was …and then drifts upwards as it disappears. It’s unobtrusive enough that it won’t distract you from the gameplay you’re concentrating on but it gives you the reassurance that, yes, you have just gained points.
I think this a neat little feedback mechanism that we can borrow for subtle Ajax interactions on the web. These are actions that don’t change much of the content. The user needs to be able to potentially do lots of these actions on a single page without waiting for feedback every time.
On Huffduffer, for example, you might be looking at a listing of people that you can choose to follow or unfollow. The mechanism for doing that is a button per person. You might potentially be clicking lots of those buttons in quick succession. You want to know that each action has taken effect but you don’t want to be interrupted from your following/unfollowing spree.
You get some feedback in any case: the button changes. Maybe the text updates from “follow” to “unfollow” accompanied by a change in colour (this is what you’ll see on Twitter). The Super Mario style feedback is in addition to that, rather than instead of.
I’ve made a Codepen so you can see a reduced test case of the Super Mario feedback in action.
Here’s the code available as a gist.
It’s a function that takes two arguments: the element that the feedback originates from (pass in a DOM node reference for this), and the contents of the feedback (this can be a string of text or it can be HTML …or SVG). When you call the function with those two arguments, this is what happens:
spanelement and puts the feedback contents inside it.
- Then it positions that element right over the element that the feedback originates from.
- Then there’s a CSS transform. The feedback gets a
translateYapplied so it drifts upward. At the same time it gets its opacity reduced from 1 to 0 so it’s fading away.
- Finally there’s a
transitionendevent that fires when the animation is over. Once that event fires, the generated
Still, even if the code could benefit from an update, I’m pleased that the underlying pattern still holds true. I used it recently on The Session and it’s working a treat for a new Ajax interaction there (bookmarking or unbookbarking an item).
If you end up using this unobtrusive feedback pattern anyway, please let me know—I’d love to see more examples of it in the wild.
Sunday, April 28th, 2019
What would Wiener think of the current human use of human beings? He would be amazed by the power of computers and the internet. He would be happy that the early neural nets in which he played a role have spawned powerful deep-learning systems that exhibit the perceptual ability he demanded of them—although he might not be impressed that one of the most prominent examples of such computerized Gestalt is the ability to recognize photos of kittens on the World Wide Web.
Tuesday, February 26th, 2019
Some useful lessons here for strengthening a culture of sustained work on a design system.
Creating and maintaining a design system is like planting a tree—it has to be nurtured and cared for to reap the benefits. The seed of our design system has been planted, and now our teams are working together to maintain and grow it. Our new way of working supports gives people recognition, facilitates trust, and creates strong partnerships.
Tuesday, January 22nd, 2019
A history of buttons …and the moral panic and outrage that accompanies them.
By looking at the subtexts behind complaints about buttons, whether historically or in the present moment, it becomes clear that manufacturers, designers and users alike must pay attention to why buttons persistently engender critiques. Such negativity tends to involve one of three primary themes: fears over deskilling; frustration about lack of user agency/control; or anger due to perceptions of unequal power relations.
Sunday, June 17th, 2018
Dave is liking the word “telepresence”:
On social media we broadcast our presence and thoughts over radio and wire and I likewise consume your projections as they echo back to me. We commune over TCP/IP.
Just wait until he discovers the related neologism coined by Ted Nelson.
Tuesday, April 3rd, 2018
Navigating Team Friction by Lara Hogan
Lara started as a developer, and then moved into management. Now she consults with other organisations. So she’s worked with teams of all sizes, and her conclusion is that humans are amazing. She has seen teams bring a site down; she has seen teams ship amazing features; she has seen teams fall apart because they had to move desks. But it’s magical that people can come together and build something.
Bruce Tuckman carried out research into the theory of group dynamics. He published stages of group development. The four common stages are:
- Forming. The group is coming together. There is excitement.
- Storming. This is when we start to see some friction. This is necessary.
- Norming. Things start to iron themselves out.
- Performing. Now you’re in the flow state and you’re shipping.
So if your team is storming (experiencing friction), that’s absolutely normal. It might be because of disagreement about processes. But you need to move past the friction. Team friction impacts your co-workers, company, and users.
An example. Two engineers passively-aggressively commenting each other’s code reviews; they feign surprise at the other’s technology choices; one rewrites the others code; one ships to production with code review; a senior team member or manager has to step in. But it costs a surprising amount of time and energy before a manager even notices to step in.
The Hulk gets angry. This is human. We transform into different versions of ourselves when we are overcome by our emotions.
Lara has learned a lot about management by reading about how our brains work. We have a rational part of our brain, the pre-frontal cortex. It’s very different to our amygdala, a much more primal part of our brain. It categorises input into either threat or reward. If a threat is dangerous enough, the amygdala takes over. The pre-frontal cortex is too slow to handle dangerous situations. So when you have a Hulk moment, that was probably an amygdala hijack.
We have six core needs that are open to being threatened (leading to an amygdala hijacking):
- Belonging. Community, connection; the need to belong to a tribe. From an evolutionary perspective, this makes sense—we are social animals.
- Improvement/Progress. Progress towards purpose, improving the lives of others. We need to feel that we do matters, and that we are learning.
- Choice. Flexibility, autonomy, decision-making. The power to make decisions over your own work.
- Equality/Fairness. Access to resources and information; equal reciprocity. We have an inherent desire for fairness.
- Predictability. Resources, time, direction future challenges. We don’t like too many surprises …but we don’t like too much routine either. We want a balance.
- Significance. Status, visibility, recognition. We want to feel important. Being assigned to a project you think is useless feels awful.
Those core needs are B.I.C.E.P.S. Thinking back to your own Hulk moment, which of those needs was threatened?
We value those needs differently. Knowing your core needs is valuable.
Lara has seen the largest displays of human emotion during something as small as moving desks. When you’re asked to move your desk, your core need of “Belonging” may be threatened. Or it may be a surprise that disrupts the core need of “Improvement/Progress.” If a desk move is dictated to you, it feels like “Choice” is threatened. The move may feel like it favours some people over others, threatening “Equality/Fairness.” The “Predictability” core need may be threatened by an unexpected desk move. If the desk move feels like a demotion, your core need of “Significance” will be threatened.
We are not mind readers, so we can’t see when someone’s amygdala takes over. But we can look out for the signs. Forms of resistance can be interpreted as data. The most common responses when a threat is detected are:
- Doubt. People double-down on the status quo; they question the decision.
- Avoidance. Avoiding the problem; too busy to help with the situation.
- Fighting. People create arguments against the decision. They’ll use any logic they can. Or they simply refuse.
- Bonding. Finding someone else who is also threatened and grouping together.
- Escape-route. Avoiding the threat by leaving the company.
All of these signals are data. Rather than getting frustrated with these behaviours, use them as valuable data. Try not to feel threatened yourself by any of these behaviours.
Open questions are powerful tool in your toolbox. Asked from a place of genuine honesty and curiosity, open questions help people feel less threatened. Closed questions are questions that can be answered with “yes” or “no”. When you spot resistance, get some one-on-one time and try to ask open questions:
- What do you think folks are liking or disliking about this so far?
- I wanted to get your take on X. What might go wrong? What do you think might be good about it?
- What feels most upsetting about this?
You can use open questions like these to map resistance to threatened core needs. Then you can address those core needs.
This is a good time to loop in your manager. It can be very helpful to bounce your data off someone else and get their help. De-escalating resistance is a team effort.
Listen with compassion, kindness, and awareness.
- Reflect on the dynamics in the room. Maybe somebody thinks a topic is very important to them. Be aware of your medium. Your body language; your tone of voice; being efficient with words could be interpreted as a threat. Consider the room’s power dynamics. Be aware of how influential your words could be. Is this person in a position to take the action I’m suggesting?
- Elevate the conversation. Meet transparency with responsibility.
- Assume best intentions. Remember the prime directive. Practice empathy. Ask yourself what else is going on for this person in their life.
- Listen to learn. Stay genuinely curious. This is really hard. Remember your goal is to understand, not make judgement. Prepare to be surprised when you walk into a room. Operate under the assumption that you don’t have the whole story. Be willing to have your mind changed …no, be excited to have your mind changed!
This tips are part of mindful communication. amy.tech has some great advice for mindful communication in code reviews.
Mindful communication won’t solve all your problems. There are times when you’ll have to give actionable feedback. The problem is that humans are bad at giving feedback, and we’re really bad at receiving feedback. We actively avoid feedback. Sometimes we try to give constructive feedback in a compliment sandwich—don’t do that.
We can get better at giving and receiving feedback.
Ever had someone say, “Hey, you’re doing a great job!” It feels good for a few minutes, but what we crave is feedback that addresses our core needs.
|General||Specific and Actionable|
The feedback equation starts with an observation (“You’re emails are often short”)—it’s not how you feel about the behaviour. Next, describe the impact of the behaviour (“The terseness of your emails makes me confused”). Then pose a question or request (“Can you explain why you write your emails that way?”).
observation + impact + question/request
Ask people about their preferred feedback medium. Some people prefer to receive feedback right away. Others prefer to digest it. Ask people if it’s a good time to give them feedback. Pro tip: when you give feedback, ask people how they’d like to receive feedback in the future.
Prepare your brain to receive feedback. It takes six seconds for your amygdala to chill out. Take six seconds before responding. If you can’t de-escalate your amygdala, ask the person giving feedback to come back later.
Think about one piece of feedback you’ll ask for back at work. Write it down. When your back at work, ask about it.
You’ll start to notice when your amygdala or pre-frontal cortex is taking over.
Talking one-on-one is the best way to avoid team friction.
Retrospectives are a great way of normalising of talking about Hard Things and team friction.
It can be helpful to have a living document that states team processes and expectations (how code reviews are done; how much time is expected for mentoring). Having it written down makes it a North star you can reference.
Mapping out roles and responsibilities is helpful. There will be overlaps in that Venn diagram. The edges will be fuzzy.
What if you disagree with what management says? The absence of trust is at the centre of most friction.
|Commit||Mature and Transparent||Easiest|
|Don’t Commit||Acceptable but Tough||Bad Things|
Practice finding other ways to address B.I.C.E.P.S. You might not to be able to fix the problem directly—the desk move still has to happen.
But no matter how empathic or mindful you are, sometimes it will be necessary to bring in leadership or HR. Loop them in. Restate the observation + impact. State what’s been tried, and what you think could help now. Throughout this process, take care of yourself.
Remember, storming is natural. You are now well-equipped to weather that storm.
Wednesday, September 6th, 2017
An interesting idea from Ruth—using subtle sounds to augment inline form validation.
There aren’t any extremely established best practices for this stuff. The best we can do is make tasteful choices and do user research. Which is to say, the examples in this post are ideas, not gospel.
Sunday, June 25th, 2017
A look at the feedback needed for a slider control that feels “right”.
You can get most of the behavioural (though not styling) suggestions in HTML by doing this:
<form> <input type="range" min="0" max="100" value="50" onchange="amount.value=this.value" onmousemove="amount.value=this.value"> <output name="amount">50</output> </form>
Saturday, August 6th, 2016
Jake has written up the notes from the most recent gathering to discuss service workers. If you have any feedback on any of the proposed changes or additions to the spec, please add them. This proposal is the biggie:
We’re considering allowing the browser to run multiple concurrent instances of a service worker.
Wednesday, July 27th, 2016
I love this back and forth between Brad and Jonathon. I think they’ve both got some good ideas:
- I agree with Brad that you can start marking up these kind of patterns before you’ve got visual designs.
- I agree with Jonathon that it’s often better to have a generic wrapper element to avoid making assumptions about which elements will be used.
Tuesday, July 26th, 2016
Wednesday, July 20th, 2016
Shamefully, I haven’t been doing one-to-ones with my front-end dev colleagues at Clearleft, but I’m planning to change that. This short list of starter questions from Lara will prove very useful indeed.
Sunday, June 5th, 2016
Wouldn’t it be nice if we had an x-ray that could peer into the true intention behind words on a screen? Sadly we don’t have that x-ray yet (for most of humanity’s existence, we had body language to enrich our words and enhance understanding, but we live in interesting times where so much, perhaps even the majority, of our communication lacks body language) and so we have to be mindful of how our words might be perceived, and what the ramifications of publishing them might be. That’s not to say we should hold off completely, but it does mean we should be mindful if we’re to be most effective.
Wednesday, December 16th, 2015
‘Sfunny, I was just discussing this with Clare and Charlotte at work: how our office space (and culture) lends itself well to spontaneous exchanges of feedback and opinions.
Friday, March 7th, 2014
When I was talking about Async, Ajax, and animation, I mentioned the little trick I’ve used of generating a
progress element to indicate to the user that an Ajax request is underway.
I sometimes use the same technique even if Ajax isn’t involved. When a form is being submitted, I find it’s often good to provide explicit, immediate feedback that the submission is underway. Sure, the browser will do its own thing but a browser doesn’t differentiate between showing that a regular link has been clicked, and showing that all those important details you just entered into a form are on their way.
progress element is inserted at the end of the form …which is usually right by the submit button that the user will have just pressed.
While I’m at it, I also set a variable to indicate that a POST submission is underway. So even if the user clicks on that submit button multiple times, only one request is set.
You’ll notice that I’m attaching an event to each
form element, rather than using event delegation to listen for a
click event on the parent document and then figuring out whether that
click event was triggered by a submit button. Usually I’m a big fan of event delegation but in this case, it’s important that the event I’m listening to is the
submit event. A form won’t fire that event unless the data is truly winging its way to the server. That means you can do all the client-side validation you want—making good use of the
required attribute where appropriate—safe in the knowledge that the
progess element won’t be generated until the form has passed its validation checks.
If you like this particular pattern, feel free to use the code. Better yet, improve upon it.
Friday, May 31st, 2013
The existential angst of unfeeling feedback.
Friday, September 28th, 2012
Andy’s talk from the Smashing Conference in Freiburg.
Monday, November 23rd, 2009
A jQuery plug-in inspired by the interaction feedback on Huffduffer, which was in turn inspired by retro games.