Is it Bad Behavior or a Problem to Solve?
What Children can teach us about working in Cross-functional product teams
I’m a Product Designer and Researcher. My role on any project team is to care deeply about the motivations, goals, and experiences of our users and design delightful product experiences. But that’s only half of the equation. The other half of my job is sitting down with my team and stakeholders to work through the tough decisions of what we should design and build.
Effective communication and collaboration are critical skills toward design projects. If you would have told me in Design School that most of my job as a designer would be talking to people — I wouldn’t have believed you and probably would have switched majors. But the ability I’ve learned in my design practice to be a good listener and synthesize lots of information actually benefits all parts of my life. Specifically, in my role as a mother.
Much like design project goals, most parents have some sort of goals for their children. If I were to chart the goals I have for my daughter on a typical week day it would look something like this. We would:
- Wake up in the morning on time
- Eat a well-rounded breakfast
- Get to school on time
- Have perfect behavior reports at school
- Go to bed on time
However, we rarely get everything done perfectly because kids generally have their own set of goals:
- Have fun
- Play outside
- Eat food that tastes good
Now I can still convince my daughter to complete some quality tasks on any given day. But the success I have in doing so greatly relies on her participation and willingness to go along with my idea of success. And she is stubborn!
Like children, people can be unpredictable and hard to work with.
If you don’t have stubborn kids, I’m guessing you might have stubborn co-workers. What was it like when you had to design something with them?
In the book Articulating Design Decisions, Tom Greever mentions that there are three ingredients to a successful design:
- It solves a problem
- It’s easy for users
- It’s supported by everyone
In teams, we as designers are brought together with other people because of the different skills we bring to the table. To be most successful, we have to learn to see eye-to-eye with this group of people to achieve our common goal of project success. This group of people we must spend time with is our project family.
For a web design project, your project family might look like this:
A Designer’s goal is to make the pages beautiful and easy to navigate.
A Developer’s goal is to write the most efficient code in a short amount of time.
A Project Manager’s goal is to have key milestones completed in the project duration.
A Subject Matter Expert’s goal is to make sure all the content is accurately represented.
Real families tend to pose nicely for family portraits, attend events together, and only share the best moments on Facebook. But behind the scenes, they’re likely butting heads and reaching disagreements along the way. After all, we are a mixed bag of personalities expected to spend a lot of time together.
Trying to sound smarter than the rest of your team doesn’t work.
Once I was working with a team on our company’s corporate website and I didn’t agree with the team’s decision to move on to another project. I felt like the changes we made to the site were minimal and it didn’t seem like the team valued giving the project their full time and effort. As a product designer, it really irked me because I saw the project from our users’ point of view, not my team’s.
In an effort to really convince this team to help me execute a redesign, I decided to plan my own usability test which would provide us all with customer feedback and clear design recommendations. Nobody on the project team at this company was involved in the usability sessions. I thought it best to go at it alone because I knew I would find the problems and it would be clear we need to get to work!
When I was done with the sessions, I wrote a report of my super smart usability findings and design recommendations before sharing them with a select few people on the project team via email. In the best case scenario, members of my project team would:
- Thoroughly read through the report as soon as I sent it
- Take my design recommendations and turn them into action items
- Promote me for taking such amazing initiative
As great as all of that sounds it didn’t happen that way. The moment I went off on my solo mission without considering the goals, agenda, or mindset of my team was the moment I condemned myself to being the only one to care about the project. I didn’t know it then, but asking this group of people to care about usability in the midst of their own projects and goals is like expecting my daughter to make breakfast — it’s just not going to happen.
I learned from this experience to not embark on design exploration, research studies or design decisions alone anymore. At least if my goal was to actually move the project forward.
Today, I find much more success sitting down as a team early in the project to discover:
What makes the project successful from my team’s point-of-view?
What do we know today about the project requirements?
What assumptions do we have about the people using it?
It is only after we reach this shared understanding of the problem space and questions we need to ask in research that we can move forward in a project together.
Embracing the connections, experiences and contrasting opinions about these things with each team member is what ultimately makes a project team a project family. It’s embracing that together we are smarter than we would be had we worked alone.
Resist the urge to design solutions or conduct research in a silo so you don’t blind yourself to critical pieces of information and valuable feedback. You can learn to embrace challenging opinions from a project team if you learn to see all pieces of feedback as opportunities for growth.
Motherhood has taught me a great deal about working with people.
I personally attribute my ability to embrace feedback and conflict to my experiences with my daughter. She’s stubborn and still practicing her communication skills, which inadvertently creates some conflict at home.
For example, once she was laying in her bed, fighting sleep and kept yelling: “Mom! I’m hungry!” She had already eaten dinner and it seemed like she just didn’t want to sleep.
In this situation, some parents would shake their finger at their kids and tell them to be quiet. They might be angry at the child for challenging them and their authority. I’m not here to say what’s right or wrong, but I can say that every time we reach conflict I always get to the root of the problem by listening and tackling the problem together.
Evelyn’s complaining that night eventually turned into tears about her friend at school leaving her out of a game that day. The behavior was just a symptom of something deeper that was bothering her. It took me asking the right questions and leaning into the behaviors to get to the root of the problem. (Parenting = User Research!)
Working in teams is hard. Here is how you can make it easier.
Like children, adults typically exhibit annoying behaviors if something is bothering them and they can’t effectively communicate it. Here’s a few annoying behaviors you might have encountered with your team in a design review:
Team Challenge: Maintaining a Shared Vision
“I know I said I wanted this, but our direction has changed.”
Maybe you were off designing a project only to come back and have to pivot entirely. The truth is a lot of people say they want thing when they need another — and what a stakeholder says they need at the beginning of a design project can vary greatly by the time you show them your design. It’s also likely that success can look very different from person to person. The best way we can combat this behavior is checking in early and often to share works in progress and get necessary feedback before we spend too much time on the work.
Team Challenge: Understanding each other’s vocabularies
“I don’t like your design choices. We should design this instead!”
Some stakeholders really like to have a say in the final design of projects. They might show you competitors, solicit feedback to your work on their own or even design something themselves. This can be really frustrating when it’s our area of expertise! The reality of it is, we can see this as an opportunity to appreciate that they care enough about the project to voice their opinion. The best thing we can do in this situation is kindly redirect the conversation away from design patterns, and toward the problem at hand.
Team Challenge: Project Transparency
“Did I forget to tell you about the new research? Use that in the project. Thanks!”
Stakeholders aren’t great at providing context to the projects we’re tasked with, and sometimes we get so far along in our work realizing we missed a critical piece of information. Our service as designers is to provide a tangible design, and others don’t assume we need background information regarding their motivations and goals for the project. Some people have never worked with designers before at all, so it’s up to us to tell them specifically what we need.
It can be really difficult to face these struggles in the middle of a project. What we can do is try to mitigate these risks by consciously making an effort to get shared understanding from all members of the project family at the beginning.
In the book Gamestorming, this exciting beginning of a project is called the challenge space, or the space between initial conditions and a target state. By embracing open-endedness at this point in the project and inviting our team along, we can gain that much needed shared understanding of the problem to be solved before designing a solution.
Doesn’t collaboration sound better than just being pulled into execute someone else’s idea? For me, it does!
