This post is part of an ongoing Good Client Guide series, which serves to demystify the web development process and empower consumers of web design (known to many in the industry as The Client™) to be an informed and effective partner in the process. Missed a step? Check out Step 4: Your Guide to Bids & Budgets.

Good feedback is about good questions

Throughout a web design and development project, you will be asked to provide feedback on various stages of its progress. Although your contractor or team does want to know your opinion, what’s more important is whether the project is appearing and functioning as expected, and whether it will meet the goals you discussed during the early stages. So, different types of feedback are more productive than others.

Being able to give good feedback is about asking yourself and your contractor or team the right questions when doing evaluations. The most important question that you and your web professional should be able to answer is “Why?” All decisions should make sense and match up with a design or development goal, so if you don’t understand, ask! I’m sure your designer or developer has asked you similar questions about your goals as well.

In addition to knowing the reason behind things, questions are usually best when they are as specific as possible. I’ve provided some guidance on how to ask the right questions when evaluating web designs or web development below.

Good design feedback

Design feedback is not just about critiquing the look and feel of a website (although that is also a big part of it). The primary purpose of design is communication, and it’s your job to evaluate the effectiveness of that communication. The primary questions to ask yourself are: Does this make sense? and Does this fit with my brand?

Some things to keep in mind:

• Design for the web is a little different than print. With a static layout like a poster  or magazine, we are looking at specific layouts (like “the contents page” or “the main feature”) and evaluating exactly what is there. In a content management system like WordPress, the content may change in the future, so a savvy designer is creating your site as a series of modules and systems based on the type of content you will be sharing (like articles, videos, products, or testimonials, for example).
  Questions: Do the systems we are creating match with the content you expect to share? Are the rules consistent, do you understand them? Do they allow you to be flexible while still staying on brand? 
• Though a designer wants you to be happy with your designs, remember that your designer is designing for your audience, not for you. Rather than just focusing on whether aesthetic or communication choices are personally appealing to you, look back to the research you completed early on in the project to identify who you are targeting, and evaluate based on their perspective.
  Questions: Are these visual elements on brand? Does it make sense to my audience?

Good development feedback

Development is executing on designs and building the functionality for your WordPress website, so development feedback is focused on how the website is working. The primary question to ask yourself is: Does this do what I expect it to do?

Some things to keep in mind:

• Trying to troubleshoot development problems requires a lot of data, so it’s important to give more feedback than just “it’s broken” when evaluating a piece of functionality that isn’t working as expected. I recommend providing feedback in the following way:
  • Try to provide details about the environment you were using to view the website (“I was looking at the website on Safari on my Macbook Pro Retina via Wifi” or “I was looking at the website on Chrome on my Samsung Galaxy S5 via my mobile network”) which can help eliminate variables in browser, internet connectivity, or hardware differences
  • Explain exactly what you did, and in what order (“I opened the site while I was logged in, scrolled down, and clicked on the “contact us” button) which will help developers re-enact the steps you went through.
  • Explain not only what happened, but what you expected to happen (“I got taken to the About Us page, but I thought it was supposed to take me to the Contact Us page” or “An alert box popped up like it was supposed to, but there was no form inside, it was just blank” or “I went to the contact form, but all the labels were red instead of blue like they should be”). This is the most important step, because it gives developers a few pieces of information: is this an actual bug (something broken or not working as built) or is this just a bad user experience (it’s working as it was built, but the action is counter-intuitive), or is it a visual/display problem (all the functionality is there, but it doesn’t look right).
• Even though modern web browsers have gotten a lot closer to universally supporting everything, all browsers (including mobile browsers) have different rules for supporting different technologies. This can affect small details, like how text looks, or large details, like layout or functionality.Many exciting interactive technologies we take for granted on new browsers are difficult to achieve on older versions, and require extra work.  As a general rule, the more browsers that need to be supported (including older versions of browsers), the more time and cost there will be in development, especially if you want the experience to be an exact (“pixel-perfect”) match. Based on the research you completed early in the project, you or your developer should have a good idea of which browser support makes the most sense for your audience. Your developer may choose to use a “progressive enhancement” or “graceful degradation” experience for non-supported browsers, depending on the specifics of your project.
  Questions: Does it look and function consistently in the browsers we are supporting? Is there an acceptable (though possibly less beautiful or less functional) experience for non-supported browsers?

Was this series helpful? Do you have any other questions you’d like answered? Leave a message in the comments. Miss a step? Start over at the beginning!