The quest for workplace clarity.
The author finds his daughter drawing on the wall. He’s both appalled and interested. Consequences and conversations will follow. Credit: Me.
My wife and I have three kids. And being a parent has taught me a lot about life: they really do grow up fast, you can never pack enough goldfish, and dear God in heaven, please do not wake a sleeping baby.
Ever.
One of our primary functions as a parent is to create boundaries for our kids. We create rules and structure to keep our children from hurting themselves, hurting others, and to prevent my wife and I from going completely insane (partial insanity is just going to happen).
A few years ago, I realized something. All the rules and structure that my parents gave me; 1hr of daily screen time, 8pm bedtimes, getting to ride in the front Monday / Wednesday / Friday (because I had to share it with my little sister), etc. It’s all arbitrary.
They aren’t real rules. There is no universal, scientific law of front seat privileges. My mom made that rule up on a Tuesday morning to keep me and my sister from screaming at each other when we needed to go to the grocery store.
But, just because the rules aren’t real, it doesn’t mean they aren’t good.
My parents created those rules to help me. They created structure to give me an understanding of how to operate in the world. They were trying to build a framework I could use to understand what success looks like.
Well… Hopefully, that’s what they were trying to do. Maybe they just wanted a little more sleep?
Success doesn’t have a clear path
The problem that I experienced (and maybe I’m not alone here), is that when I graduated college and went out into the real world, I had an expectation that it operated on a framework. All I needed to do was figure out what a company’s rules were. If I could abide by them, I could be successful.
That was a huge mistake.
I’m about 15 years into my career. Here’s the thing that I’ve learned: clarity is a luxury. More often than not, I have entered into a work situation where there is no structure, there are no rules, or key performance indicators. No one I was working with understood how to define success. All I had was a job with an unclear description, and a mandate to do it so that my family didn’t live under the nearest bridge.
This was incredibly frustrating. How was I supposed to get an “A+”? What did I need to do to get more responsibility, a raise, or even a promotion?
Unless I had an excellent manager with a ton of time on her hands, I had very little to draw on. And while I could blame my boss, the company culture, or executive leadership for not creating rules that teach it’s people how to be successful, that’s a terribly unproductive use of time.
Complaining never gets anyone very far.
Create the clarity
I’m a design manager who has been leading teams for the last 6 years. Do you want to know what the main difference is between a Product Designer and Senior Product Designer? While a little different everywhere you go, there’s a single common trait that becomes more and more pronounced as a designer advances in her career: solving problems independently.
As a designer, learning to be competent at your work is the goal. You want to learn the necessary skills to execute all the tasks that are delegated to you. But once you’ve achieved mastery, and you understand your company’s process, if you want to grow in your career you must identify new problems and solve them without being asked. That may mean that you redesign an inefficient process used on your team, repair a library that you’re using in your designs, or meet with your project stakeholders to align on the basics goals of the project you’re collaborating on.
You need to be the one to create clarity and cast vision for yourself, your work, and potentially your team.
If your work environment doesn’t have structure, make it. Don’t leave it up to your coworkers or your manager to define what success looks like. Use the company’s framework (if they have one), so that you’re speaking the same language as your coworkers. But make sure that you are not waiting on someone else to cast vision and translating that vision into tactics.
What are we really trying to solve?
Several years ago, I worked at Blackboard (now Anthology) designing educational software. At the time, I was working on improvements to the WYSIWYG editor in our content creator. The product manager I worked with explained that customers were asking Blackboard to add “custom HTML/CSS” to our editor.
That was my goal; design the custom HTML/CSS button in our editor and how it would function. But as I drafted my design brief, I realized that we didn’t truly understand the pain points that we were solving for our users.
No one asked “why”.
Instead of jumping right in, I asked if we had time to perform user research. We did, and had several instructional designers who would be very excited to speak with us. I asked them a series of research questions as they walked through how they create lessons in Blackboard. What our research showed us, was that our users actually needed more custom options for building their lesson content. But they assumed the only way they could do that was by inserting custom HTML/CSS. So, that’s what they asked for.
In the end, we design more features for the WYSIWYG editor than just HTML/CSS. We added more option for typography, color, and content.
I created clarity on that project and in the end, we were able to solve our user’s real problem. That’s what you need to be doing as a designer.
Three tools for creating clarity and casting vision
I have three tools for you to help you create more clarity and structure in your work, particularly when things feel a little opaque.
Tool #1: Ask dumb questions If you’re new to the company, or new in your career as a designer, this is your power move. Always be asking questions (Forbes has a good list). You don’t know anything, and people expect you not to know anything. So, you can ask whatever you want.
Are people throwing acronyms around like they own the place? Bang! Question. Does everyone assume we all know what the project’s goal is? Bang! Question. Does a project stakeholder have unrealistic expectations for design’s role in a project? Bang! Question.
It’s always been startling to me how many assumptions that we all make when creating software. This is especially true when you’re working with people who possess different specialties. We assume that the things we know well, other people also know well and that creates an entire world of confusion.
Questions, even seemingly dumb questions, cut through that confusion.
Here are some of my favorite questions:
What problem are we solving?What do you mean by [bizarre code name or weird acronym]?Who are our users?Why is this [thing/feature/product] important?What does success look like?Are there any constraints we need to consider?Can you explain that in simpler terms?What are the potential risks?What’s the timeline for this project?What are the key assumptions we’re making?Who will maintain this after launch?
Tool #2: Design Briefs
If you’ve had any formal design training, you’ve learned about design briefs. We’ve been using them in architecture, design, and agency work for decades. They’re a tool for translating business needs into creative work.
Too often I have seen designers working on a feature without any kind of brief that brings together the details of their project. There’s no single document that provides context, illustrates the pain they’re trying to solve, and defines what success looks like for their work. This is a big mistake.
Whenever you start a new project, create a brief. There are some really great resources to help you make this happen.
This document can be used for a lot of things. But it is especially great at aligning stakeholders on the goal of a project. Too often, everyone working together on a project makes assumptions. Leverage your design brief to strike those assumptions down, dead in their tracks.
Here’s how I typically organize my briefs:
Design Brief
Project Overview
Begin with the title of the project, followed by a brief description outlining the project’s primary goals and objectives.
Background
Provide context and history leading up to the project, as well as relevant market analysis highlighting current trends and industry information.
Objectives
Clearly state the primary goal of the project. Additionally, list any secondary goals and the expected benefits of achieving these objectives.
Target Audience
Describe the target user in detail, covering demographics such as age, gender, and location. Include psychographics like interests, behaviors, and lifestyle. Identify the user needs and pain points the product aims to address.
Scope and Deliverables
Define the project scope by outlining what is included and excluded. Specify the key deliverables, detailing the specific outcomes and products to be provided upon completion. Potentially break deliverables into phases.
Technical Requirements
List the functional requirements, detailing the features and functionalities needed. Include non-functional requirements such as performance, usability, and security considerations. Address technical requirements, specifying the necessary platforms, technologies, and integrations.
Timeline
Provide a timeline with key milestones and deadlines to keep the project on track.
Stakeholders
Identify the project team, detailing roles and responsibilities for each member. List key stakeholders, including both internal and external parties involved in the project.
Research and References
Include links to any previous research performed. Summarize insights from user research and feedback. Include examples of similar projects or designs that can serve as inspiration or reference points.
Success Metrics
Define key performance indicators (KPIs) to measure the project’s success. Describe the evaluation methods that will be used to assess whether the project meets its goals.
Risks and Assumptions
Identify potential risks and challenges that could impact the project. List any assumptions that the project is based on, ensuring they are clearly stated and understood.
Tool #3: Workshop Facilitation
This is a skill every designer should learn. It’s an incredibly useful tool for aligning large groups of people towards a common goal. There are some amazing resources you can take advantage of to start learning. AJ & Smart, a design agency in Berlin that works exclusively in workshop facilitation for its clients, has put together a really useful guide to workshopping.
What makes this skill so valuable is that it creates structured, productive conversations in a very efficient way. Instead of just having a discussion, you create a series of exercises that outline problems, identify success metrics, and assigns ownership to each person involved. I’ve also written a lot about workshop facilitation in a previous post.
Here’s a Project Kick-off Workshop that I would run if I were starting a new project with a group of stakeholders. If you want detailed descriptions and FigJam layouts of some of my favorite design thinking exercises (including these), check out this link here.
Project Kick-off Workshop
Hopes and Fears
The “Hopes and Fears” exercise aims to surface participants’ aspirations and concerns regarding a project or initiative. The goal is to address potential obstacles and align expectations early in the process.
Stakeholder Map
A Stakeholder Map identifies all individuals and groups involved in a project, highlighting their interests, influence, and relationships. The goal is to understand stakeholders’ roles and how they affect the project.
Problem Statement
The Problem Statement exercise helps articulate a clear and concise definition of the problem to be addressed. The goal is to ensure a shared understanding of the problem, guiding the team towards focused and effective solutions.
Assumption Collecting and Mapping
Collect assumptions from your project stakeholders regarding what you think might be true about the project. This exercise gets everything out in the open. You’re going to realize how misaligned everyone is and have several conversations to work through it.
Hypothesis Statement
The Hypothesis Statement exercise is aimed at formulating clear, testable statements that articulate assumptions about the project, its users, or the problem being addressed. These statements guide the design and development process by providing a foundation for experimentation and validation.
Conclusion
I hope you find these tools helpful and empowering. You don’t need to wait around for someone else to provide structure. Bring clarity to your work. Invite others into it. Make things that start conversations. Other people aren’t going to do it. You need to.
Resources
Understanding design levels: Junior vs Mid-level vs Senior UX Designer — UX Careeers
Ten Questions to Ask Your Manager When Starting a New Job — Forbes
How to run your first workshop — AJ & Smart Youtube Channel
Game Storming by Dave Gray, Sunni Brown, and James Macanufo
Hey y’all! I’m Trip Carroll, a design leader at Cisco and aspiring cartoonist.
I write and publish a new articles on design, leadership, and software development every other Monday. You can see more of my work on my website, check out my drawings on Instagram, or subscribe to my newsletter on Substack.
Let’s make work great!
Draw your own maps was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
