How to stop defending and start presenting your design work

A major differentiator between being just a designer and being your team’s MVP is being able to articulate your process and how you arrived at your solution.

Before knowing how to do this, I always found myself having to defend my work to my team. My team would look at my solution and start asking loads of questions about all the decisions I made that lead to the solution I created. Being in this situation left me nervous. I would get defensive and stumble on my words trying to come up with answers.

And that can really kill your confidence and your team’s confidence in you.

When you aren’t able to easily explain the why behind your work, you inevitably end up misaligned with stakeholders’ expectations on how you’ll arrive at your goal. This can then lead to not only redoing your work but potentially losing stakeholders’ trust.

So how do you prepare to present your reasoning clearly and confidently so that stakeholders easily understand the thought behind your work, provide specific feedback, and get behind your solutions?

Simple: Come prepared with a shortlist of design principles.

These principles are 2 to 5 clear and concise sentences that explain the WHY and HOW behind your work so that people won’t shred apart your design because they didn’t understand the approach behind it.

So, trust me when I say they are invaluable to a designer (and your ego!) when written effectively.

Here’s a deeper dive into what design principles are and how to go about creating them:

What are design principles?

Imagine, you’re going on a road trip. You have a destination in mind and a list of things you’d like to see along the way. However, you’re also travelling with 3 other people, all eager to get to the same destination but have their own set of requirements in order to get there. Someone requests that you stop every 3 hours to eat, while others are eager to see certain monuments or cities.

In order to meet everyone’s needs and avoid questions about why you’re going a different way, you write out an itinerary that outlines your route, where you’ll be on each day and how long you’ll stop in each place.

Your design principles are your itinerary that shows why your route makes sense. They are a list of must-haves that explain why and how you worked within certain restraints. They are statements that help people understand why you considered putting the button in the top left, but ended up putting it in the top right.

Note: While the company may have its own set of overarching fundamentals that guide the work they do, these design principles should be criteria specific to the design project you are working on.

Minimize questions and maximize buy-in

During almost any project, there will be a time when you need to show your work to stakeholders who have less understanding of the context in the initial concepting. Having design principles prepared puts you in presentation mode.

You give yourself control over the conversation by showing everyone the much-needed context around the hundreds of small decisions you made to get to a certain point. By being prepared with the WHY and HOW behind your work, you will minimize confusion and maximize alignment with what you’ve created. You may still get things wrong, and the principle might actually be incorrect, but it allows everyone to have a much more informed discussion using a shared language.

Presenting your design principles will not only remove subjectivity from feedback and help stakeholders focus their critique, but the extra time that gets put into thinking clearly about the how and why makes it so much easier to talk about if it gets questioned. It will save you from having someone refuse to go along on your road trip before they know what route you’re planning to take and why it’s best.

How to write top-notch principles

My process starts with exploring the initial problem statement which helps me take a deeper look into the specific problems my design aims to solve. Remember: if the approach is too narrow, you’re prescribing a solution, if it is too broad you won’t be able to identify what needs to be done.

Take a look at these:

• “Make it easier to checkout”
• “Move the upgrade button up on the screen”
• “Make the checkout button easy to see”

The first is too broad, leaving too many solutions possible throughout the design. The second is too specific and doesn’t leave the option for any other possible solutions with the button. The third is specific to one function while leaving it open enough to allow you to explore multiple solutions.

Let’s take a closer look.

Recently, we re-designed a checkout page for a well-known SaaS company. From our research, we learned that the page was not performing well because of the way the information was structured. Users needed to piece together numbers from 3 different areas of the page to their plans and then how it all rolled up into the amount ‘due today’. We also knew that the plan editing button, which is critical to helping people customize their plan to meet their needs, was small and hard to see.

After I created a first draft solution, I wrote these simple principles:

Add clarity: We want users to scan and quickly understand their plan, the price and their amount due today.

Reduce friction: We want users to quickly hit the upgrade button and effortlessly enter their card details.

Make it easy to find the customization controls: Those that do need to customize should be able to find the inputs easily.

Consider what users aren’t seeing on the pricing page: This may be their first time encountering the structure of their plan since those things are not obvious on the pricing page.

Notice that the solution is not written here. What is outlined are the goals or guidelines around what my design is meant to achieve.

Explore first, write later

While design principles are the guide to why you created what you did, I don’t suggest writing them before you design.

Just like you would never create your road trip’s itinerary before doing a little research on all the things you want to do along the way, I only write my principles after I’ve completed exploring what to create for wireframes and sketches. Then I work backwards and evaluate my plan, thinking critically about WHY my chosen solution is valuable and HOW it solves the original problems that were laid out. Basically, I perform a one-person design critique.

Going back to our example SaaS company, I identified that I moved a button to where I think it will be more obvious for the user, or that I re-organized the pricing information to be all in one place because users need clarity around how much their plan costs.

Then I write my principles as:

• “Make editing more obvious”
• “Add clarity to pricing”

The Takeaway

Writing design principles keeps the important goals of your work front and center. When successfully outlined, you’ll be ready to confidently present and you’ll be less likely to get caught off guard when questioned. In my experience, this preparation has led to better outcomes because the principles remove the need to debate and defend your solutions.

In sum, it’s like being back in high school math class. If your teacher can “see the work” it’s easier to figure out why the answer was right or wrong. The conversation then shifts from being about the answer (correct or incorrect) to being about the formula that led to the answer. You’ll hold confidence among the stakeholders you’re presenting to because they see you’ve thought deeply about every decision you made. And, let’s be honest, who doesn’t want a little more of that?

Nick Foster is the founder of Sixzero, an agency that helps companies design apps and software with impact.

Illustration by: Muti, Folio Art