8 principles for sharing work better
How collaboration by design unlocks stronger iterations
Maybe it’s the slight wobble in your hand as you press ‘send’. Maybe it’s the ominous tone that the Google Meet bell takes on as you join an important meeting. We’ve all felt it. Whether you’re working in a tiny agency or a gigantic tech company, the fear is real.
UX gets a tough break in that way. We’re the ones that have to take what’s often a pretty abstract idea and try to convert it into something tangible. Something usable. That means we’re often on the business end of explaining the reality of the thing, and all of its constraints. I often find myself in the position of ‘owning’ all the drawbacks of an approach simply because I’ve been the one that’s discovered they exist. But we can mitigate this and make things little easier on ourselves if we think about the sharing of work as a craft all to itself. Something we should all work to get better at.
We can make things little easier on ourselves if we think about the sharing of work as a craft all to itself.
My UX team works on the part of Shopify that helps merchants run their back-office operations. We build the tools that help merchants manage their inventory and fulfill their orders — things that can make or break a successful business. The changes we make can have huge consequences for merchants, so sharing our work with the right people at the right time is hugely important to how we operate.
To get things done, we have to be constantly circulating work, with other designers, with engineers and PMs on our teams and with partners on other teams. We need to use a bunch of formats, styles and levels of formality depending on our audience, but whatever the medium or the audience the fundamentals of the practice are the same. For us sharing is never an afterthought. It’s not something we do after all the work is done, it’s a huge part of the work itself.
In my role as a Senior Staff Designer at Shopify, I’m constantly thinking of ways we can move faster and smarter, trying to push us all to be just a little bit better everyday. A huge part of craft leadership here is to try and create new and better practices that can become a part of the way the team operates, even when you’re not directly there to guide them.
Last year, our team worked our way through a bunch of huge, mission-critical releases, all while the size and complexity of Shopify just kept on scaling up around us. Sitting across a few of these projects in a Staff role, I could see how much friction was generated by inconsistent collaboration. Looking at teams that did this well and teams that struggled with it, the correlation between how good they were at sharing the work and how good the subsequent iterations were was so strong. I began to realize it might be causal, rather than correlative, so I decided to lean into it more.
In that spirit, I helped the team create 8 principles as a baseline for us to check ourselves against whenever we need to share work. At times, these principles intentionally contradict each other, but that’s by design. Navigating the tension between them and indexing on the most important aspects for a given situation is how we keep these principles alive and stop them from just being boxes to check.
#1 Sharing makes work better
As straightforward as this one might seem, I think we often lose sight of it. As a craft, UX never works in isolation. Despite that, I often observe folks spending a lot of energy trying to avoid sharing something for as long as possible because it’s ‘not ready’. It’s easy to fear unwanted influence on work we’ve nurtured so closely and get the idea in our heads that sharing work is a test we need to pass. We forget sometimes that the reason we do it is so it gets better.
We’re intentionally keeping the definition of ‘sharing’ loose here. Sharing can be the thing you do in a formal exec review, but it can also be an async video walkthrough, or even just be grabbing a couple of minutes to get a gut reaction from someone. I struggle to think of a scenario where something I’m working on hasn’t benefited from another perspective. More often than not I feel embarrassed to have missed something that a fresh pair of eyes spotted in seconds. The amount of feedback you need is not an assessment of skill, or something that you grow out of as you get more senior in your career. Instant reactions, hot takes and measured responses are all just inputs we can take to refine and improve what we’re working on.
The amount of feedback you need is not an assessment of skill, or something that you grow out of as you get more senior in your career.
#2 Have an opinion
If you’ve gone through the process of understanding the problem and the user needs, you should be able to come up with a recommendation of what you think is the right way forward. When you’re at the point of sharing, don’t make the mistake of going deep on explaining the problem but then hedging on what you want to do to fix it. If you’re not clear on what you think is the best option, everyone’s going to try and find a solution for you, and then you’re designing by committee. None of this means you have to be ‘right’ in some kind of objective sense — opinions can exist without certainty.
If you’re not clear on what you think is the best option, everyone’s going to try and find a solution for you, and then you’re designing by committee.
At Shopify we talk about ‘strong opinions, loosely held’, which is a way of reminding ourselves that we haven’t failed if people disagree. Part of our job as designers is to give other disciplines something tangible to react to because that’s what moves the work forward. I can think of multiple times where I’ve intentionally projected far more confidence than I’ve actually had in my own opinions, not because I’m desperate to get my way, but because sometimes unpopular opinions are the best way to get a strong reaction. I just have to remind myself that it’s okay if people get fiesty and tell me all the places where I’m wrong.
#3 Match the fidelity of your work to the fidelity of your thinking
Subconsciously or not, people tend to assume that buttoned-up, hi-fidelity designs represent ‘finished’ work. When a prototype looks like it could be shipped tomorrow, that suggests that the thinking behind the work is all locked up. While this is helpful in avoiding distractions when you’re polishing the final details, going up to that level of fidelity too early in a project can change the conversation in unhelpful ways. Some partners might get defensive, mistakenly thinking they weren’t bought in early enough to meaningfully contribute. Others may simply hold back from offering any feedback under the misperception that it’s too late to change anything.
A simple trick is to sync up your level of certainty to the level of detail in your work.
A simple trick is to sync up your level of certainty to the level of detail in your work. A hand-drawn sketch can sit somewhere around the ‘just throwing stuff out there’ range. At Shopify, every UXer is equipped with an iPad and an Apple pencil to help make this easy, but this is nothing that can’t be achieved with paper and a pen. Once we’re past this phase, then simplified, blocky UI can represent something more like an ‘educated guess’. Finally, a polished, fully-interactive prototype becomes shorthand for ‘this is the thing we have the most confidence will work, and we’re ready to move it forward’.
With the proliferation of prototyping tools out there now, we try to be as agnostic as we can about the specifics of how you build the thing, but in general we try to live by the maxim that the best prototyping tool is always the one you have right in front of you. If it’s fast and it makes your work ‘feel like the thing’, then it’s the right tool. For us that tends to be Figma, but we try not to be too prescriptive about it.
#4 Just show the thing
Users don’t experience products like we lay them out in our Figma files. They don’t get the benefit of arrows, highlights and other pieces of marginalia as they’re trying to make sense of it, so try to avoid those crutches as you try to make your argument. Let the work do that. Demo it as if the people you’re showing it to are real users. You can avoid the temptation by defaulting to prototypes rather than scrolling through artboards when you’re presenting. There are so many cases where the flow between screens is just as important as the screens themselves, and it’s harder to get a read on those interactions when you’re looking at things diagrammatically.
#5 Don’t look back
At the risk of being reductive, there’s really only two ways of talking about UX: why something works, or why something else doesn’t work. I’d rather spend whatever time I have on the former.
It’s natural to want to tell the story of all the work, to talk about all that you explored and how you got to where we did. That’s a very common habit. But all of that should be reflected in where you ended up. Laboring too much over the details of how you got there risks overselling it.
When you share something, it’s better to use whatever time and attention you have to strengthen your argument than it is to spend time explaining all the things that didn’t work, or walking back through the design explorations that got you there. It’s handy to have those previous explorations ready in your back pocket if something comes up in the subsequent discussion, but those references shouldn’t just be there just for the sake of proving that you did a lot of work to get to where you got. That should be obvious.
#6 Scrappy, not crappy
Moving fast is great, but when you’re too loose and things get thrown together too quickly, you’ll either get something back that’s just as loose, or your time-constrained crappiness will actually undermine what you’re trying to say. In that case the person you’re sharing with might start to wonder — if the details here are so patchy, then what else you aren’t thinking about if?
We can save everyone a lot of time by spending a little more of our own time knowing ahead of time exactly what we want to say and being crisp in the way we deliver it. If you’re working async, always take the time to craft a written description that sets up the work and cuts the need for long preambles. If a video recording is bogged down with long explanations of ancillary information, delete ruthlessly. If you’re sharing in real time, do what you have to do ahead of time to prep and make sure you’re being as efficient as you can be in what you’re trying to say. None of that means you have to resort to cold corporatese; if your style is informal then lean into it. Just try to apply the same principles of clarity and simplicity to the way you talk about the work as you do the work itself.
#7 It’s not a committee
There’s a famous adage that describes camels as horses designed by a committee. I think that’s a little unkind to the unique qualities of a camel, but the point is well made. A perfectly rational committee might come to the conclusion that a camel has far better features than a horse, but it will struggle to see that all those features don’t always add up.
Within a project team, try to avoid situations where everyone on the team has to say ‘yes’ to move forward, but only one person has to say ‘no’ to not move forward. Some people really do have veto power and that’s fine, but if they don’t have that power and they’re still dissenting, you need to assess the scope of the problem that they’re pointing out relative to everything else. It’s just so easy for these discussions to blow up issues so quickly that we forget to ask ourselves simple questions like ‘how many people will this actually affect?’
You don’t have to dismiss the opinion outright, but once you’ve established it’s not something you need to worry about at the moment, you should find the right parking lot for it so the team can keep moving. When we’re in committee mode we tend to burn up time figuring out problems in the abstract, when really the best way to prove if you’re right or not is to run with an idea and see if it bends or breaks under the pressure of trying to make it real.
#8 There are no boss battles.
Reviewing work with senior folks is not the final boss battle at the end of the design process. It should never be the goal in itself, but it also shouldn’t be a thing you have to get past to get on to the next thing. That mentality stops us from using senior leaders to solve problems with us, not against us. When they’re at their best, these are people who can provide broad context and insight. Their job is to make the work better, same as ours. They shouldn’t be there to offer up binary yes/no rulings. That’s the standard you should hold them to.
If you do need them to make a hard call on something, don’t try to preempt what you think the response will be by diluting your work with a compromised version ahead of time. Show them the best UX, and frame the difference between the ‘great’ version and a ‘good’ trade off as a resource question. For example, ‘we think this experience is 70% right and here’s what a 100% looks like and here’s what it will take to get there’.
Talking through and trying to define these principles has been a huge lift for us. Like everyone else, we’ve had to think about entirely new ways to work and communicate over the last few years, and that job is far from finished. We’ve found that by being rigorous about the ‘work that surrounds the work’, the work itself has got better, which is the best confirmation of Principle #1 (sharing makes the work better) we could ever hope for.
