As you build out these solutions, you want to keep communication open with your internal users to verify the solutions are working well. There are three angles you want to approach from.

Talk to a Broad Cross-Section of People

At this point, you’ve likely already identified people you want to run through solutions with via your user research, but we like to expand from there when we’re putting forth possible solutions. Ensure you hear from:

• Multiple attitudes. Talk to your champions, but also talk to your diehard critics. These are the people you will never please no matter what you do, and you can learn valuable things from them.
• Multiple roles. Talk to the people doing the work of entering content, not just their bosses or directors. Talk to admin staff. Talk to developers. Talk to designers and product managers. Talk to students. Talk to teachers.

Present Information in Multiple Forms

Different contexts can help trigger different responses to information. For example, a list of content types on paper is read differently than that same list on a CMS edit screen, which is read differently than how the page will render for the end-user.

Here are two ways we presented content types to users during different phases of a project.

On the left is an early draft of the content types and their relationships. On the right is a page that editors would interact with when going to create content.

These two presentations and the questions that went along with them garnered a lot of different insights into the key questions:

• Do these content types make sense?
• Can users figure out which ones are best to use for their use cases?

In an attempt to break away from “News” as a content type, which seemed a little too prescriptive for its various use cases, we attempted to rename it to “Update.” This referred to an update of any kind, which seemed more appropriate for how people used it.

In the first presentation, users seemed ok with this naming. However, when we presented the editorial screen, we immediately saw a pattern of users confused by the new name. They kept asking, “What is it we are updating?”

In the context of an editorial interface, users were reading the word as a verb instead of as a noun. Changing it back to “News” cleared up all of the confusion. Validating our solution in different contexts allowed us to spot this issue before it caused potential problems down the road.

Multiple Reviews

You need to be providing more than one chance to validate your solutions. Changes need to be re-verified, and while some of these modifications will appear to be small and minor, they can have a major impact.

The more times you can get things in front of users, the better your solutions will end up being in the end.

All of this verification and re-verification also helps you build bridges and break down silos (this work never really ends). The more people you talk to, the better chance you can identify additional champions that can help you down the road. The more you listen to and implement feedback, the more trust you build.

This all pays off with greater buy-in and acceptance as your project rolls out and, since many of your stakeholders will already have some familiarity with what you’re doing, easier training.