Notes from Better by Design 2018


Notes from a design conference in Madison, WI

Things I encountered at this conference that challenged me to grow:

  • Celeste Headlee’s articulating the importance of conversations.
  • Jorel Dray’s reminder to provide the feedback that others need to grow.
  • Lou Downe’s call to enable scaling good design by extending more broadly the privilege of the opportunity to practice better service design.

Have (better) conversations

I found a lot to challenge me Celeste Headlee’s morning keynote (10 ways to have better conversations) and in the conversations practice workshop that immediately followed.

See also:

Our conversations are under-intentional, under-designed. There’s opportunities to have better conversations, by design.

Bad news: you cannot fix others’ conversational behavior. (In general, you can’t fix other people).

Good news: You can improve your own conversational skills.

Online and in email: you are the worst version of yourself.

To have better conversations:

  1. Single-task. Be present.
  2. Don’t lecture. Don’t try to change minds. Instead, go into conversation intending to learn from others.
  3. Ask open-ended questions. Who, what, when, where, why, how. Not yes-no questions.
  4. Go with the flow of the conversation. Don’t get caught up by some bit or by whatever your mind is teling you relates – let it go and keep up with the conversation as it flows past this.
  5. Say you don’t know when you don’t know.
  6. Never say “I know how you feel.” You don’t know how the other person feels. Even if you experienced something very similar, you still don’t know how even that experience felt, since with time and distance your mind has dulled that memory. Avoid conversational narcissism.
  7. Do not repeat yourself. Say it exactly once, and thereby become the kind of person who’s known to say things exactly once. If people have the impression you repeat yourself, they don’t listen, since their mind assumes they needn’t bother listening because the information will be available from the environment again in the future. If you’re known to say things only once, then people will listen to you the first and only time you say things.
  8. Stay out of the weeds. Most details don’t matter most of the time. Most people most of the time do not have the capacity to presently engage with those details. So just drop them.
  9. Listen. Really listen to people. Be interested in other people.
  10. Keep it brief. Online: you have 8 seconds. In face-to-face conversation, you have 30-60 seconds. It’s not a lot.

New research: the liking gap. We under-estimate how much other people like us and enjoy our company. Your inner critic is more critical than others are and hold you to higher standards. Others don’t notice or remember your conversational failures so much as you think.

Audience question: What about a culture of “healthy debate”? Answer: Rule for knowing when to engage in “debate”: Any time you want to accomplish anything, don’t “debate”.

Audience question: Conversations as ephemeral. What about written communication, email as a way to have a record of conversations? Answer: that record is worth a lot less than you think it is. There’s a huge gap between what the email author thinks the email said and what the email recipient thinks it said.

Email is good for:

  1. Lists, agendas, and summaries. Send an email listing or agendaing things that you need to have a conversation about. Have the conversation. Then send an email summarizing the conversation.
  2. Conveying attachments.
  3. Letters. The kind of thing that would have been a longhand real letter in a pre-email era.
  4. Praise. It turns out, straight up praise works as well over email as it does in conversation, maybe because looking at it afterward actually works for recipients of praise emails.

Remote work: modern teleconferencing tools work great. Phone almost as good as f2f, and solutions with cameras close this gap further.

How to get others to behave better in conversation: you can’t. The best you can do is model good behavior.

Think of conversation as a game of catch. Both the turn taking, and the setting the other person up for success (catch is only fun if they successfully catch the ball.)

Do not offer unsolicited advice.

Shift responses vs support responses. Some conversational responses attempt to shift focus to oneself, whereas other conversational responses support the other person.

Interesting to think about how this relates to the Async Manifesto and to more generally the advantages in making information available asynchronously, on demand, when people are ready to consume it rather than just when you’re ready to say it.

How to discover what your users really need

Paige Bennett’s talk How to discover what your users really need.

We won’t uncover user needs by looking at the data alone.

Ways to discover user needs

Do workshops with users.

Actively involve stakeholders – in working roles, photography, facilitation, greeters. Presence of stakeholders improves buy-in through their direct observation. This is more powerful than your reporting results.

Field visits

Observe users in their natural environment.

Metaphors

Helps people to be more expressive and more heard.

Reframing the question

We are not great at imagining what we may do.

“Would you use this” –> “Have you used something like this before?”

Flip a request for a promise (what would you do) to an observation of current action (what do you currently do).

“What would have gotten you to stay?” –> “What did you hope this product would have done for you?”

Sharing findings with stakeholders

Your findings must live on without you.

  • Workshops
  • Exhibit pop-ups. Mini museum.
  • Collateral
  • Brown bags

Audience question: what about remote users? Answer: consider a diary study.

Art of feedback

Jorel Dray’s The art of feedback.

Feedback is a process, not an event.

Getting feedback (in context of feedback about design work):

  • Seek out more feedback.
  • Set the tone.
  • Handling feedback you don’t agree with: try it before you discredit it. Do what’s right, and also do what was asked for. Show both.
  • Handling amorphous “I don’t like it” feedback. Gently remind that “it ain’t about you and what you like”, it’s about the design being effective for whatever its goal is. Circle back to the goal and try to get feedback on how the design fares against its goals.
  • Fight hard, but know when to let it go.

Giving feedback:

  • Respect before anything else. There’s no point in giving feedback to anyone or about anything you don’t respect.
  • Build a process. What’s working well? What needs to change to meet our objectives? (We do have identified objectives, right?) What would make the work more awesome? Recap. Take notes. Feedback becomes standard and routine, not a punishment.
  • What, how, when of feedback matters. “You made it too busy” –> “It’s too busy” –> “Try to simplify” –> “Try a version that’s simplified” –> “Try simplifying so that people can focus on that really cool thing you made.”
  • If time is tight, be specific.
  • Talk in person when possible. Email is always brutal.
  • Be timely.
  • Ask for feedback. If you’re the kind of person who asks for feedback it’s more natural for you to be giving feedback. Demonstrate a state of constant improvement. Demonstrate accepting feedback effectively.
  • Balance. Affirming and corrective. Standard 3 Mr Rogers to 1 Gorden Ramsay ratio, but sometimes much more Rogers.
  • It’s not about you. Be what they need you to be to grow.

In conclusion:

  • Work is never bad, it’s just not there yet.
  • Positive feedback keeps us going. Great feedback improves the world.
  • Try to find happiness and put energy into growth, not outcome.

Keynote: the future of (public) service design

Lou Downe ‘s The future of (public) service design.

Just hearing Lou Downe speak in person was inspirational in itself. They’re one of those leaders where you hear them speak and have that feeling of “Yes! Your heart is in the right place. You’re brave. You’re doing the right thing and doing the right things in the right ways. I’d follow you.”

The vision they laid out was also compelling. Cenrtalization brought a significant initial increment of experience improvement for people interacting with the UK government, but the UK will achieve the next increment of improvement through empowering decentralized attentions to user experience throughout the UK government.

Transformation is the ability of an organization to deliver and maintain a service over time.

delivery –> scale and sustainability

Successfully delivering services at all is good, better than not. But the long term wins will come from scaling and sustaining service delivery.

“Digital” is just a means to an end.

Most of government is service design most of the time.

Digital Service Standard –> Government Service Standards

Design your infrastructure, or your infrastructure will design you.

Corralary: designing and offering infrastructure is high leverage.

Don’t try to design the future. Design something the future can design.

Be strong. Be kind. Carry on.

Privilege and sharing privilege; privilege as lens for service design

Give people the skills and opportunities to help themselves.

Collaboration is a privilege. Barriers include money, time, and access to data.

Having the space, the slack, the empowerment to improve service design and delivery is a tremendous privilege. Public servants often want to do a better job, to do the right thing, to better serve the public. To deliver experiences that are reasonable, that are in the proudest traditions of thoughtfully and kindly treating others. And often public servants have very little room, empowerment, expertise, support for doing this. In extrema, sticking your neck out to criticize an existing experience, that’s a way to jeopardize a job you may not be able to afford to lose.

Making things better is a privilege.

The next increment of improvements will be achieved through sharing that privilege.

(Unpublished) ranty blog posts for the win

Anecdote that resonated: Lou’s proudest achievement so far has been spinning up the 5M Pound / year initiative around service delivery manual, style guidance, etc. This originated in a ranty blog post Lou had drafted and been asked not to actually publish, and instead to do something about the issues articulated.

There is power in writing. It clarifies thinking and it shares vision, persuades. There are also necessary steps that come after the ranty blog post to take strides forward. Not all ranty blog posts should actually be published (but perhaps really should nonetheless be written).

On how to approach accessibility and usability

Mobile-first, accessibility-first.

Extreme testing first. Testing with screen readers. User testing with users with physical and cognitive disabilities. If it works for some of the most difficult user contexts, then it’s more likely to work in other contexts too. This testing teaches you more sooner.

Making services accessible is like making a muffin be a blueberry muffin. It’s really hard to get the blueberries in later if you don’t bake them in from the beginning.

Extreme testing first is time and resource consuming and expensive and always needs justified.

It’s also the most effective way to design highly usable, accessible services. And when it comes right down to it, the law probably requires you to do this. So if you’re taking compliance with that law seriously, well, this is what it really takes to do it.

Conclusions

Be interested in humans.

  • Interested in learning from conversation with humans,
  • interested in discovering what humans really need,
  • interested in growing from feedback from humans, and in provding humans the feedback they need to grow,
  • interested in empowering humans to design and deliver better services at government scale

Andrew Petro

Related Posts

Apereo CAS is now on Develocity

An overview of how Apereo CAS is using Gradle and Develocity to improve its build and test execution cycle.

CAS OAuth/OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the Apereo CAS software acting as an OAuth/OpenID Connect provider.

CAS Groovy Vulnerability Disclosure

Disclosure of a security issue with the Apereo CAS software when using Groovy.

CAS OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the Apereo CAS software acting as an OpenID Connect Provider.

CAS X.509 Vulnerability Disclosure

Disclosure of a security issue with the CAS software and its X.509 features.

CAS OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the CAS software acting as an OpenID Connect Provider.

CAS OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the CAS software acting as an OpenID Connect Provider.

CAS OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the CAS software acting as an OpenID Connect Provider.

CAS Spring Framework RCE Vulnerability Disclosure

Disclosure of the Spring framework RCE security issue with the Apereo CAS software.

CAS OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the CAS software acting as an OpenID Connect Provider.