The Importance of feedback

How we’ve improved our design standards with better feedback loops

Sharing can be difficult

Whether it’s writing words on a page, applying colours to a design or choosing which piece of furniture will compliment your living room, there is always an element of anxiety or self-doubt to accompany the design process; one tends to wonder what someone else might think or say should the wrong direction be taken. The inner critique becomes emboldened and tries to stop you making any decisions whatever. There are hundreds of these moments in any given day, amplified of course if that person is paid to create for a living, which brings about its own unique pressures.

One of the creative’s daily hurdles is sharing. Sharing work early and often increases transparency and gives you an understanding of your work’s legitimacy. Is what I’ve created in the right ballpark? Am I going in the right direction? In this article I’ll be exploring how we’ve implemented a sharing culture at Student Beans, and why it’s important to have one.

Sharing what you have created is sometimes harder than getting started in the first place. You can to some extent battle your own inner voice with things like experience, self-actualisation, a bit of grit and willing and so on. You alone have made your thoughts real, in the sense that what you thought is now in front of you. This is where a creative’s insecurity, sensitivity and defences are tested. If your company doesn’t have a sharing culture or system, then sharing work can be difficult.

Rollo May is right when he says, ‘commitment is healthiest when it is not without doubt, but in spite of it’. In other words you can’t share without doubt or anxiety, but you must overcome it. You can make considered steps within a strong sharing culture to guide your decisions.

Before sharing anything, ask yourself these questions:

• What am I sharing and why?
• Who am I sharing it with?
• When should I share it?
• What feedback am I looking for?
• At what stage is this piece of work?
• What, out of what I’ve created, does a particular person need to see?

All of these questions carry their own importance for framing why you’ve spent time creating something and why it now happens to be in front of someone else, requesting their time, energy and focus.

I will now explore how we turn theory into practice at Student Beans, what it has meant for our overall Design culture over the last year and how you might be able to share your work more regularly with more confidence.

Building our sharing culture

We like to lean heavily on the principle of transparency and accountability. Sharing work early, often and in the right places means you can create a sense of autonomy with your work. You can be in control of your feedback loops, giving the right people the right view of your work at the right times.

The key here is to first understand when to share and what feedback to ask for. Within our design team, we structure our feedback timing on the 30/60/90 framework. This allows us to decide on our own terms the ‘stage’ of our work, and this in turn tells us what type of feedback we’ll be looking for. As a general summary 30% means directional and key structural changes are okay, 60% means you’re looking more for experiential feedback, 90% means you’re after copy changes and final user interface tweaks.

At Student Beans we work in different Tribes. We have seven designers and one researcher all working on very different but intrinsically linked products. To supplement the sharing that goes on within our Tribes we needed to find a way to remain transparent with each other but without taking up time with calls, to create a free-flowing way to highlight any clashes or catch any last-minute details before something goes to the developers, and much more. This is where we turn into co-pilots.

Co-piloting is our form of cross-functional Design QA whereby a designer posts on our Guild Slack channel a piece of work they want feedback on. The structure of a co-pilot usually goes something like:

🚨 Co-Pilot Request 🚨
What?: Write title of the piece of work

Status/stage: 30%, 60%, 90% or anything in between

Context: Provide some context on why you’re doing it, what metrics will it affect, what OKRs is it linked to etc

Feedback wanted: What feedback do you want?

Links: Attach link to Figma, Miro etc and add screenshots to the post if needed

Reviewers use 👀 to show they’re taking a look and ✅ to show they’ve closed their review. A healthy comment thread should then be present under most co-pilots as the commentary or feedback is what we’re after. Every individual has different skills to offer and so opening work up to the Design team in this way means you’ll receive varied feedback. Sometimes the work posted can be simple enough for a couple of comments, other times it sparks spicy debates which need more alignment, possibly a call set up off the back of it. Co-pilots keep alignment and spark interest.

Since starting co-piloting in February we have experienced less ‘woah’ moments — ie. work shown at a late stage which is way off course — and more ‘wow’ moments. There has been less rework and improved collaboration and transparency. We’re working on tracking the NPS and UX Scorecard metrics to see if our sharing has had an impact on our output quality. It has encouraged members of the team to share work when they’re not feeling completely comfortable to, thus overcoming doubt. It’s also a nice way for different Tribes to share work other members of the team aren’t close to. Sharing in this asynchronous way creates a live hub of activity around you; crucial when working remotely.

We have some house rules to maintain the consistency and quality of our output. Any two people can review any co-pilot, but at least one Senior or above has to review a 90% co-pilot before it goes out to developers. Our goal is to ‘close’ co-pilots by reviewing them within 2 hours, so we’re not slowing down a designer or researcher’s flow.

Over the course of the year co-piloting has been steadily adopted and we’re finding our rhythm with it. As the team grows, we expect the amount of co-pilots to increase as well as the amount of comments and reviewers. We’ll be moving this process into JIRA over the coming months to better integrate our practice into the various product squads.

References

When to ask for feedback and what feedback to ask for: 30/60/90 framework

The Courage to Create by Rollo May: https://www.goodreads.com/book/show/646141.The_Courage_to_Create