Owning It

In a perfect world, web-based projects are the making of a project is something like a Venn diagram of responsibilities and actions. Product 1)sometimes called Business, represented by the Product manager or Project Manager helps IT 2)represented by the  Tech Lead and UX 3)represented by the UX Lead understand the business goals of the project, UX helps Business and IT understand the best flows and uses of the product and how to reach the business goals and IT helps Business and UX understand the technical constraints and how best to build it.

A venn diagram showing the equal weighting of Product, User Experience, and Information Technology for completing a project. Summed up in the paragraph before it. And I take it so seriously I set it in my very best werewolf font.

In the real world, I’ve found, the circles of influence aren’t equally weighted. Product owns the purse strings, so generally they get what they need or the project is cancelled. If IT decides it’s not going to build what Product or UX request, well, nothing gets built4)or the wrong thing gets built, or in desperate cases the whole thing gets built in an Excel spreadsheet with a thousand macros by a Product person who could be doing something better with their time.

But if UX is the one out of alignment with the others, well, it doesn’t take much for Product and Business to build and ship without UX input—it happens all the time in our tiny corner of the universe.

We have to own and harness our ability to influence others. We have to show that while we may not necessarily have been granted the authority to make decisions, we are the authorities in making those decisions.

There are two ways to gain authority:

  1. Gain the trust of the other circles and build a positive reputation, so that people want your influence on the things you’re good at
  2. Get someone who already has authority over the other circles to grant you the authority to influence things.

In general, you can do them in either order but it helps to do both.

That’s where responsibility and ownership come in. For the purposes of this post we’re going to use “responsibility” and “ownership” interchangeably. Showing responsibility is a surprisingly powerful force when it comes to communication and getting things done. Responsibility means:

  • Owning your design skills. Consistently look for ways you can improve, through feedback from peers and co-workers, conferences, classes, articles, whatever sources you trust. Once you find ways to improve, implement them.
  • Owning your communication skills. If you’ve created the best design in the world but you can’t explain why it’s the best design, or positively respond to criticism, or work with others, you haven’t created the best design in the world. A design is only as good as its explanation.
  • Owning your mistakes. Whether it’s not keeping up with your calendar, overcommitting yourself, or dropping a ball, we all do it. Ownership is clearly saying “I make this mistake, I’m sorry, and here are the things I’m doing to make sure it doesn’t happen again”…. and then actually doing them.
  • Sharing your victories. Make it clear that the work you are credited for couldn’t have been done alone. Recognize the people who helped you (even if they didn’t want to or made it difficult).
  • Being compassionate toward the other members of your team5)This doesn’t mean being a doormat—you are not personally responsible for the actions of others. It does mean that unfortunate disasters and personal mistakes happen to everyone, and holding a grudge is rarely useful. Say “That sounds awful, how can I help?” more than you point fingers.
  • Being available for questions6)Be available within reason. If you have higher priorities, it’s best to communicate that. And remember that you don’t have to take on every project that someone else dreams up. even well after a project has launched. A five minute phone call to answer a question about something you worked on years ago may be enough to save someone else dozens of hours of time researching, even if you’re not delivering the news they want. They’ll remember that you helped them.
  • Documenting your work. Good documentation, in whatever form you choose, makes the difference between future-you or your future counterpart thinking you’re a genius and thinking you’re a slacker.

Not one of these skills is easy. But that’s what ownership is about: holding on to the hard things as tightly and reliably as holding on to the easy things.

And none of these skills are going to make us rockstar designers. There’s no guarantee that they’ll confer extra creativity, speed, or talent. They won’t make us famous and they probably won’t make us stinking rich. They will make us sturdy, reliable designers.

When we work on the skills above, we show that we’re consistently putting in the effort to make the team successful. We prove that we know what we’re talking about—and we prove that when we do make mistakes, we’re transparent about them. We gain trust from our teammates and our management team, and we gain authority through that trust. We clearly communicate our value and we lead others, not through coercion but through effort, to recognize that value.

While there are a few places where where Design is so baked into the culture that a UX Designer has the authority to stop a project in its tracks, they are still rare, and chances are most of us don’t work there.

For the rest of us, our authority and our influence grows when we increase our peers’ respect for us both as Designers and as people. That growth is driven directly from our own actions. We must transparently and consistently not only prove that we know what we’re talking about, but also that we are willing to do the hard work of clear communication, keeping our word, and making it easy for others to work with us.

When faced with a problem that can be solved by taking the easy route, or by owning our role, we should own it.


Also published on Medium.

Notes   [ + ]

1.sometimes called Business, represented by the Product manager or Project Manager
2.represented by the  Tech Lead
3.represented by the UX Lead
4.or the wrong thing gets built, or in desperate cases the whole thing gets built in an Excel spreadsheet with a thousand macros by a Product person who could be doing something better with their time
5.This doesn’t mean being a doormat—you are not personally responsible for the actions of others. It does mean that unfortunate disasters and personal mistakes happen to everyone, and holding a grudge is rarely useful
6.Be available within reason. If you have higher priorities, it’s best to communicate that. And remember that you don’t have to take on every project that someone else dreams up.

Author: Anne Gibson

Anne Gibson is Senior UX Designer and general troublemaker for a big/small technical company outside of Philadelphia, Pennsylvania. She's an editor and writer at The Interconnected. She is also published at A List Apart and The Pastry Box, and publishes short fiction when she's not persuading the terriers to stop wrecking things.