Jasmine Christensen

When someone says, “I want to be more autonomous,” what does that mean? Autonomy is independence, freedom, self-government. In the context of design, autonomy can be perceived to mean: “I want to do this on my own, I can do this by myself.”

I’ve often heard young designers ask for autonomy as if it’s a role to be had or a skill to be developed. What autonomy-seeking designers really want is to be empowered to make their own decisions; they falsely equate solo decision-making with seniority.

The best design work is never done by any one person alone, but instead is built from collaborative processes. Partnering with others in order to learn, evaluate, and make informed choices drives more impactful, effective solutions.

When you suggest autonomy is valuable or necessary in your process or as a skill, you’re saying that you don’t want to take on the beneficial task of working with others.

You might not necessarily see collaboration as a bad thing; you might simply prefer working in isolation because collaboration can be hard and time consuming. There are a few key assumptions that serve as arguments for autonomy.

Assumption 1: You already know what people are going to say

You already have the right solution. You might believe that you already thoroughly understand the problem or have the right solution, but pulling in collaborative partners could uncover context or value that you hadn’t heard previously. Or alternately, your expectation of what they were going to say might be flat out wrong.

You know you’re not there yet. Exposing work you know is incomplete might put you in a situation where your solution is off track, or your lack of progress is exposed. Collaborating and getting feedback frankly risks us being wrong. And that’s okay! Great design is often influenced by our mistakes and our missteps. It’s better to be guided into a well-shaped approach than design based on our intuition alone.

You’ve heard it before. If you already know what people are going to say—and they actually keep saying it—and your design hasn’t addressed those things, you may need to step back and consider a few things. Either you’re ignoring their feedback because you don’t believe it’s important (and possibly missing out on a better solution) or you’re missing an opportunity to clarify context and constraints.

The solution to assuming you already know what people are going to say is to seek out feedback anyway and listen to it. Specifically: listen to the nuances of the feedback. Repeat back to them what you’ve heard to make sure you catch the details of their perspective.

When you bring solutions repeatedly to the table, ask if you’ve addressed prior concerns. Ask what concerns are outstanding, and what could be made more clear.

Assumption 2: You don’t have enough time to bring people in

There’s not enough time in your project plan. You might not think you have enough time to conduct stakeholder interviews, test initial concepts, or get feedback on early directions because you’re bound to a hard deadline. However, early understanding and the internalization of what you discover will save you extra time getting to a well-evaluated solution. There’s nothing worse than getting to the finish line and realizing you missed a crucial learning moment; the best way to get those learnings is by exposing your plan early on.

Peers, reviewers, teammates, or managers might cause you to backtrack. Sharing context is an investment, particularly with stakeholders and close teammates. The more you get into habits of sharing and soliciting feedback, the more time you’ll save explaining the details of your projects. Collaboration with key people prevents backtracking to find new solutions or pivoting when a direction is taken that wasn’t widely shared, evaluated, or agreed upon. All of these things are significant time wasters.

To save time in the long run, when you kick off projects, schedule immediate time to gather information and constraints from stakeholders, subject matter experts, and peers. Schedule time to interview users—or partner with a researcher—to further understand the problem being solved. Try scheduling a repeated block on your calendar to to get feedback from cross-functional folks. Share regularly in design critiques.

All of this lends to a collaborative process and ensures a well-canvased approach; time well spent will save you time. Get into good habits of collaboration and feedback early.

Assumption 3: You’re ready to go it alone

You already have the right solution. Even if you’re positive you’re on the right track, check your understanding and knowledge against what others might be able to provide. Likely you will be working from limited anecdotal evidence and won’t have the power of multiple sources and appropriate synthesis. Foundations are always stronger with various contributors and perspectives.

You work better alone. Maybe you really do work better alone to some extent; many designers do need time to process and focus. But designing end to end without feedback or collaboration is faulty. Even if you have no direct design partners, there are always partners to work with. Your job is to ask the right questions.

You need to prove yourself as autonomous to get to the next level. If you truly believe independent work is what propels careers, you’re probably not ready for that next level. The more experience you have, the more you will become deeply acquainted with the nuances and depths of your unique skillsets as well as the distinctive aspects of the industry and the product you’re building. With this knowledge, you’ll also be able to better evaluate where you can improve. As a designer, you may be a user, but you are not every user. You may be a developer, or you may not be. You may have insight into the stakeholder vision, but you might not be privy to how that changes over time. Your awareness of the need for collaboration and the skills to facilitate it indicates your probability towards leadership.

To solve the assumption of going at it alone: don’t be afraid to ask what you don’t know, what you’re missing. Ask who you should talk to next. Ask what would be a success, and what would be a failure. If you have a collective vision of what the problem looks like when it’s solved—and what it looks like if it’s not—you have not only a picture of success, but also a body of partners to evaluate it against.

A collaborative designer will always seek out people who complement their skills and who flesh out their understanding. The proactivity it takes to gather information from others is the demonstration of a leader. And, as you develop further in your career, you’ll find that leaders are never going it alone.

Collaboration keeps us accountable to designing something for others instead of for ourselves and raises the quality of our output. It ultimately helps us in our pursuit of empathy.

Collaborative designers…

• Are practiced in understanding problems and synthesizing themes; they don’t run on anecdotes
• Work through edge cases quickly and are often taking design directions that seem less appealing because of pertinent context
• Ask for very specific things when they’re soliciting feedback because they understand complex dependencies and sequencing
• Thoroughly internalize research, feedback, and constraints and deliver synthesized and distilled design directions with informed intentionality

Autonomy in itself isn’t something that helps you grow. Having space to practice skills of collaboration and application is important, but that’s not autonomy. People get perceived autonomy—leadership—once they’ve demonstrated the ability to deliver thoughtful, usable, high quality, collaborative solutions. The more you demonstrate, the more you are able to lead, collaboratively.

‍