Home / Design  / How we foster a culture of vulnerability and openness in our design team

How we foster a culture of vulnerability and openness in our design team

Products with great user experience and high market impact are built on well-considered and well-executed decisions. This relies on members in your team having the right information at hand. On them thinking and deliberating, critically, to identify shortcomings and usability concerns even before testing. On them feeling empowered to challenge thoughts and ideas?—?even from those in positions of authority.

Everyone deserves feedback on their work. Ruinous empathy happens in teams who hold back on feedback for fear of being impolite, while teams who are harsh in their criticisms verge on obnoxious aggression.

As design leaders, we want to plough a middle ground where the seeds of radical candor can flourish?—?that’s being able to give honest and critical feedback, without leaving your humanity at home.

These are not individual actions any single designer is responsible for upholding; it relies on a continuous culture of vulnerability and openness.

The foundation for good work starts with designers being able to trust each other for an honest critique of their work, without having to worry about their place in the team. A kind space where everyone can be vulnerable without judgement. Over time, this builds psychological safety and a strong support network amongst the designers, and this develops into team resilience.

Here are three ways to build a culture of vulnerability and openness in your team:

1. Recognising good work, well.

As a manager or leader, the way you cultivate vulnerability starts not in difficult, challenging situations, but with the way you recognise and acknowledge good work.

i. Learn how to praise

Instead of applauding the genius of a person, encourage the action or effort taken, so it becomes a deliberate practice that can be cultivated to stretch their abilities.

Not helpful:
Jonti, you’re a superstar! What you did there was epic! Gosh you are so easy to work with, your work never fails to impress me.

Jonti, I really liked the way you guided the team to focus on goals instead of their opinions on the project. You whiteboarded the two main concerns there, which really helped align engineering and product on our priorities.

One promotes a fix mindset, another develops a growth mindset.

Also, when giving praise, refrain from using words like “superstar”, “hero”, or “prodigy”. They represent a culture of idolisation, and emphasise the glory of individual genius instead of team work and collaboration. Take time to recognise the specific skill demonstrated by the designer, so they know how to apply that again in the future.

ii. Separate the action from the person.

The outcome was a result of what they did, not who they are, especially when the outcome was negative.

Not helpful:
“Shalini, why didn’t you answer any of our questions just now? You just left it to the product manager to defend your work. That was really awkward, don’t do that.”

“Shalini, when you keep quiet on any questions about your project, it doesn’t help anyone in the meeting gain confidence about your progress. If you didn’t feel like you had the answers at hand, it’s okay to say: I haven’t thought about that, let me look into it and get back to you after.”

To give developmental feedback in a meaningful, actionable way, use the observation + impact + recommendation model: What was the situation or behaviour you observed, what happened as a result of that, and what is your suggestion for improving.

2. Normalise failure.

It’s okay to fail” is a terrible thing to say when something’s gone wrong. You may mean it as a form of consolation, but to your team member, you’ve just called out their failure and disappointment?—?and that can be demoralising, not encouraging.

To create an environment where failure is part of the job, that needs to be talked about before someone gets a chance to fail.

Make it a regular topic for the team.

Every Friday as part of our team’s end-of-week wind down, we put our tools down and turn to what we call Fail Diary.

The concept is simple. One by one, everyone reflects and talks about:
1. How they have failed over the week.
2. What was the silver lining
3. What is their learning outcome.

Fails tend to start small as people struggle with that concept. For example: “I forgot my notebook in Tuesday’s meeting and didn’t take notes. When I picked the work up this morning I had already forgotten what Manny said.”

Over time, they start revealing trends in behaviours or practices that can impact good work. “I had to rebuild my prototype ‘cause I forgot to write down the instructions Jerome gave. I was quite upset about that actually, it meant that I had to spend the last two days doing that instead of helping Yuki out with her interview scripts.”

Eventually, you may find some result in massive oversight on a project, or breakdown in communication, or delays on the team’s roadmap. “We spent three weeks rolling back this release, when it shouldn’t have even been a thing. Pete, Hyun-Ki and I decided against this interaction in that one meeting, but no one noted that decision down or shared it with the wider team. So the engineers went ahead and worked on the ticket, without knowing that it had been de-scoped.”

A fundamental behaviourial pattern we can call out here, is the habit of not taking notes or writing things down.

These habits may seem inconsequential in isolation, but without spotting and addressing them as they repeat, they can lead to damaging effects. For our team, Fail Diary has become a core part of our learning and growing, and a regular form of reflection therapy.

3. Learn how to critique the work.

Design is a highly personal vocation. Like in engineering, designers draw confidence and pride on their abilities based on their work, and have a natural tendency to get highly attached to their work. But unlike programming, where success means building something that works and failure means it didn’t work, success in UX design isn’t always binary.

Help your designers be objective about their work, by separating the uncertainty in the solutions they present from the rest of the work that’s already been validated.


Following the scientific method, start with a clear problem statement (what are your designs trying to solve?), and turn any hunches or assumptions into a hypothesis. A solution is an answer to the problem?—?it implies a fix, a sure remedy. On the other hand, a hypothesis has a 50–50 chance of failing or succeeding.

That does two things:
1. On a personal level, it liberates the designer from the pressure of “Abdul was wrong”, and work more objectively with “This hypothesis was wrong.”
2. On a technical level, it diagnoses areas that require more testing, from ones that already are resolved. That way, when one part fails, the validity of the rest of the solution don’t all fall apart like a tower of Jenga blocks.

A good hypothesis states:

“We think that by … [doing this]… users will be able to … [achieve that]…”

Notice it says “We think that”, not “We know that”.

Now that you’ve got a hypothesis, don’t stop at one. Challenge the designer to propose multiple so where one fails, another may succeed. Even better, several successful ones may then go on to form a multi-pronged strategy to address the problem.

An example of that in product design:

Problem statement: 
When rolling out new features, especially those that may be disruptive to our user’s existing workflows, many respond negatively to the feature because they are surprised by the change. How can we communicate high-impact releases to existing users, to help them understand and anticipate change?

Hypothesis 1: 
We think that by displaying an introduction of the new feature on the dashboard, and inviting them to opt-in at their own time, we’ll be able to increase voluntary adoption.

Hypothesis 2:
We think that by presenting a tutorial walkthrough demonstrating how users can complete their tasks faster with the new workflow, we’ll be able to prepare, equip, and motivate them to adopt and support the new feature.

Hypothesis 3:
We think that by sending an email promoting the new feature and its value, users who haven’t seen the feature will be able to learn more and can click through to interact with it in-app.

Technology starts and ends with people.

The beauty of having a diverse team is in the different perspectives everyone brings. However, without a safe and healthy environment to express opposing views and resolve differences in opinions, the loudest or most powerful voice always wins.

A culture of vulnerability and openness empowers everyone in the team with the authority to give constructive feedback, and the humility to receive criticism. It is the catalyst for robust discussions and healthy debates, and the opportunity to learn from each other’s successes and failures.

Recognise good work, well. 
Normalise failure. 
Learn how to critique the work.

Start laying the foundations of trust today, to allows positive actions and decisions to rise, and crystallise into the products and services we build.

  • This piece was originally published on Medium.
Review overview