7 Guidelines for Constructive Design Feedback

If you’re a client working with a polyvalent team of makers at Atomic Object, one of the most valuable things you can do is to give feedback throughout the project. This may come as a shock to you. In the past, you might have been involved in a project where feedback wasn’t welcome—or even treated as downright hostile. If that’s the case, let me be the first (and hopefully not the last) to apologize on behalf of consultants everywhere.

The reality is that we are all on the same team. As a client, you have a project that requires custom software. You also have a budget allotted for completing that work. At Atomic, we have expertise in the project management, design, and software development you need. Together, we are in a great position to work toward our goal, and your constructive feedback will make it easier to reach that goal.

Your contributions are crucial!

As the client, the success of your project requires something that only you possess: expertise in your own domain. Without your knowledge of your vertical, we can make you an awesome, well-meaning software product… that will fail miserably. It could be elegantly designed with a tech stack that responds quickly and efficiently to a user’s actions, but if it doesn’t help users meet their goals and make life easier for them, it won’t make you money.

And you’re not hiring us just to spend money, right? You are investing a sum of money to make more money. Unless your product has a market fit as a product released into the wild, it will not make you money. And we depend on you to help us find that market fit.

The way that domain expertise makes its way into any project at Atomic is twofold.

Information Gathering during RDP

First, we seek to download as much of your domain knowledge into our brains as humanly possible through a research, design and planning phase (RDP). We take time to walk through a series of exercises designed to expose insights into your business model and the needs of your users. We then document these insights and give them back to you in visual, digital forms, eliciting your feedback to make sure we’ve correctly understood the output of the exercises.

In my experience, this type of knowledge transfer is enjoyable for everyone. As makers, we have a great time immersing ourselves in a new subject area, and our clients love sharing their interests and passions with us, too.

Feedback at Meetings

But we’d be kidding ourselves if we thought that this RDP phase could give us a complete understanding of your vertical. That’s where the second way we incorporate your domain expertise into any project comes into play. We purposefully schedule periodic meetings where you can view our progress and share your feedback.

It’s very rare for our clients to be able to comment on the quality of the code written by our development team, so a lot of the feedback focuses on design. And this is great! Most of the feedback we receive is positive. But good designers like to have their work challenged by clients. It’s an opportunity to explain the thinking behind the decisions we’ve made and to ensure that we stay on track with your business goals.

Giving Better Design Feedback

Unfortunately, design feedback can sometimes focus on areas that aren’t particularly helpful. To help you avoid these pitfalls, here are some pointers for giving more constructive feedback that will result in a better piece of software and, ultimately, more money in your pocket.

1. Keep feedback focused on business, not personal taste.

If there is something about the design that doesn’t sit right with you, ask yourself why. Be specific. Then, ask yourself if that is just your personal taste or if there is something legitimately wrong with the direction of the design.

If it is your personal taste, tread carefully. Seeing your personal taste implemented can be expensive and completely hamstring the success of your project. Why? Because you aren’t the user of the software we are designing. Your personal aesthetic satisfaction with the project won’t add a single cent to your bank account, and users won’t come back again and again to fill your bank account because of how pretty your software is. They will come back if that software fulfills a need they have. They are going to give you money because your product helps them achieve a goal while being as simple as possible.

A good designer will steer you away from statements about personal taste (both yours and their own) and help you focus on your core business model. Of course, if there is something that concerns you in a business sense, you should bring it up.

2. Tie your feedback into your own domain.

You have earned your business knowledge over years of battling in the trenches of your vertical, and we recognize that you are the expert when it comes to your business. This gives you a great basis for framing your feedback.

When we started the project, we went through that RDP phase that helped us define the project goals. As you evaluate a design, go back to those goals and ask yourself if the design is lining up to achieve success in your vertical. If you have any doubts, let your team know. It’s especially helpful if you can back up your feedback with specific data points or insights that the team you are working with might not have.

3. Give your designer room to explain his or her thinking.

Hopefully, you are working with a designer who has your best interests at heart. They should be submitting their work to a design process that’s been refined over time to produce successful results. Designers shouldn’t be interested in exercising their craft at their whim or at your expense for their own creative realization. That’s what artists do. Designers aren’t here to make art–we’re here to solve problems.

If you feel you are working with an artist, it’s probably a good time to evaluate your continued collaboration with that individual. They should be crafting thoughtful solutions to problems that presented themselves during the RDP or discovery phase of your project. If you see a problem, ask about it. Your designer should have put a lot of thought into what they are presenting and will probably be able to give you compelling reasons why they made the design decisions they made.

4. Remember, you aren’t the user.

During the RDP phase, we probably drew up a set of provisional personas. Those personas are archetype personalities (hopefully created as the result of user research) meant to represent the primary, secondary, and tertiary users of your software application. As designers, we want you to want to use the custom software we are designing. But as a stakeholder, it’s good to remember that you aren’t the primary user. Accordingly, when you share feedback, it can be helpful to couch your comments in terms of the personas we’ve created. Call those personas by name. Tell us why you are concerned that what we’ve created won’t help those personas meet their goals.

5. Let the people you hired solve the problem.

Design is an iterative process. We make something that isn’t perfect, and then we iterate on it until it is. You will almost certainly see business problems within the designs presented at each stage of any project. Feel free to point out those problems. Because you have a specific, unique view into the domain we are working in, you will see problems that we won’t. That’s a sign that everything is working the way it should!

However, it’s a good idea to restrain yourself from steering your team toward a specific solution. I know, it is a real temptation to solve the problems you see. Maybe you’ll send us a design comp you made in Powerpoint or Photoshop. Maybe you’ll send us a marked-up version of a design we gave you to review.

But remember, you’ve hired a team of smart professionals, and you can trust them to come up with unique and innovative solutions. If you push your team into a particular solution, you may end up settling for less than the best we can give you. So trust our expertise as we trust yours, and together, we will arrive at the most successful end possible.

6. Establish a shared ontology.

Language is fun! It can also be flexible to the point of losing meaning. The same word can mean a lot of different things to different people. Think about the usage of words like “love,” “like,” “cool,” “bad,” “fat” (or “phat”) in popular culture. Meaning has become so variable that the words don’t mean anything.

When it comes to a specific field like design, language includes a lot of idiosyncratic terminology that most stakeholders won’t understand. Some industry jargon uses words that mean something completely different from their regular use. Therefore, establishing a shared ontology (or set of defined terms) is incredibly important when teaming with people outside of your own industry.

As designers, creating and introducing this common vocabulary is up to us. We are, after all, communication professionals. The easiest and most cost-effective way is to ask for clarification when our clients say something we don’t fully understand. For example if you say, “I think a more edgy look would be more representative of the tone of our brand,” we are probably going to say, “What does edgy mean to you? Could you show us some things that you consider to be edgy?” Additionally, we try to eliminate jargon from our conversations with clients. If a designer ever uses vocabulary that’s unclear to you, I’d invite you to start compiling a shared ontology by asking what they mean.

7. Make feedback explicit and active.

No, I don’t think that feedback needs a parental warning! But as a client, you shouldn’t have to worry about hurting your designer’s feelings. Just make sure your comments reflect on the work, not the designer, and keep your comments clear and specific. Statements such as “I don’t like it” or “This is great” are too vague to be helpful. They don’t give your team any specific direction on how to improve the work. Instead, point out specific things that you think are working/not working to meet your business needs and the goals of the personas we’ve established.

Also, if you think something isn’t working, don’t wait. If you are concerned about an aspect of a design and you don’t bring it up now, you’ll regret it when the project fails to succeed months down the road. Now is not the time to sit back and see where things go. Be involved and active in your project. When you share constructive comments based in your areas of expertise, your input will ensure a greater degree of success for everyone.

For more than a decade, we’ve partnered with a wide range of clients in over 20 industries. We’ve created more than 200 software applications. If there is one thing we’ve learned, it’s that we need our clients’ expertise to navigate the waters of custom software development. So the next time you sit down with a designer or team of makers to review progress on your project, feel free to share your feedback, and make your comments count. The success of your project depends on it.