Integrating user-centered design thinking into a team

Bringing user-centered thinking to a team with no prior design guidance

Caroline Keem
6 min readMay 28, 2020
Designer talking to team

I’ve been hired to join great teams of designers who collectively work within established company style practices but this has not been my typical job experience. Working on a design team is incredibly rewarding. However, for most of the jobs I’ve taken over the past 15 years, I’ve been the first designer of any kind hired into a development-lead team in order to mitigate the pain points of an already existing product.

This is a great opportunity to bring user-centered thinking to bear in a new way but must be handled diplomatically to work well for all parties involved. Many companies did not consider the user, as the first blush of genius spawned a new product into the world, and they must retrofit usability into their work. Usually, they have been cruising along for 2–5 years and, upon hearing a loudening chorus of “this product is great but is hard to use” from their customers, have decided to bring in a designer. There are specific things I do in order to make this process go well.

Set expectation from the beginning

The beginning of this job experience starts at the initial interview and in that platform, it is vitally important that I set the expectation of what I intend to bring to the team. I want to know what they already have. Do they have any sort of user data already? How has this been acquired? How have they been making design decisions up to this point?

When I have a clearer picture of their existing process I introduce my core design practices and paint the picture of what that development cycle will look like when I am a part of their team. I explain regular user testing, establishing style standards, and working directly with developers to achieve improvements. Then I listen carefully to their response. How would this work for them? Are they able to see this vision for themselves? I consider it vital to have real user data, gained either through surveys or interviews, in order to design solutions. If there is balking at the possibility of any kind of user testing — this is not a place I will be happy working.

Introduce UX to the team

In my most recent position, my new manager had a brilliant idea to hold a team summit that pulled together all lead developers, project managers, and business analysts to discuss how to integrate UX into their existing team methods. These two days were very helpful in clarifying what I as a UX designer have to offer and how to best integrate with their workflow. Upon joining teams that heretofore had no design involvement I most often get the attitude that I’m there to “fix everything and the customers will stop complaining”. This initial aura of celebrity wears off once they realize that while I have a lot of magic markers to wield, I possess no magic wand. Real improvement is a long process and it’s important to collectively clarify the vision of how that process will flow.

I work with the team to establish the “tent poles” of our new work world:

  • What do they think “User Experience” is?
  • What is usability going to mean to this team?
  • What is our team vision?
  • How will the assignment and tracking of design tasks be done? What existing practices have been working that we can grow on?
  • What do they need from me to be successful? How am I helping to solve our problems?
  • What do I personally intend to offer? How can usability help the company reach its goals?

It’s important to integrate early with the team. I like to say that were we making a cake together, UX is the eggs, not the frosting.

Explain the value of user testing in simple terms

Often the team has a catalog of users’ complaints which they want new designs to ameliorate and they see little value in pausing to user test at this early stage. A lengthy user wish list is a good place to begin probing for real issues but a bad starting point for undertaking new design solutions. As Steve Jobs said, “Users don’t know what they want until we show it to them.” User requests outline how they would like the experience to feel. The design solution is completely beyond their ability to predict.

Intimate knowledge of user complaints does not equal a full understanding of user problems. Until taking a full measure of the real problem doing design work is a futile exercise. We would very likely waste time creating a solution aimed in the wrong direction and which can harm, rather than help, our users’ productivity. There is great value pausing to conduct surveys or hold user tests (either remote with screen sharing or in-person) to further probe what lies underneath the stated user pain points.

Initial user testing is taking inventory of what works and what doesn’t. Any retailer who fails to take inventory at regular intervals to uncover and remove damaged or poorly selling goods would not survive in business long. This is what user testing gives us — a baseline inventory providing knowledge we will use to direct our efforts as we improve our offerings.

Know that someone’s ”cheese is getting moved” and this will cause friction

Chances are strong that someone on this team has a vested interest in things staying just as they are and will immediately resist adding a designer into the equation. Someone who has been handling the design work thus far may think they are doing just fine and is now feeling insulted or slighted. Another person may not like to see their responsibilities shifting or lessening. These concerns may be expressed with varying levels of aggression but really, it’s all just fear.

It’s never served me to meet aggressive behavior with more aggression but rather I seek to make this person my partner. This means no sniping back and no talking about said person to others. I listen carefully to hear what good they have to bring to the table and work to grow upon that. If kindness and listening don’t work the only person who would be reasonable to discuss the matter with is a manager.

“Well the last UX designer I worked with …”

This sort of thing is terribly unprofessional. But some well-intentioned soul will use these words when a design doesn’t match their worldview.

I am best served by assuming good intent and responding with better professionalism than I have just been shown. Here are the words that have worked for me in such situations:

  • “This field changes rapidly as new insights are uncovered. I would bet that those designers you worked with, if asked today, would do something different than what they suggested to you back then.”
  • “Thank you for sharing. Can you tell me more about the thinking around that?”
  • “That’s nice.” (Said nicely and only to be used in cases of persistent rudeness)
  • The 11th commandment in UX: “ Thou shalt react to negative stimuli only in a manner befitting of your intelligence and accomplishments.”

Breaking new ground is a pleasure

Integrating user-centered design thinking into a team has its surmountable challenges. It’s so exciting as well to see others learn to pause and consider the user first. Inevitably comes the day when someone else on the team does a better job of speaking up for the user than I might have at that moment. That is a job well done.

A note In Plain English

Did you know that we have four publications and a YouTube channel? You can find all of this from our homepage at plainenglish.io — show some love by giving our publications a follow and subscribing to our YouTube channel!

--

--