“Nodes.” “Taxonomy.” “Rule of thirds.” “Breakpoint.” “WYSIWYG.”
For those of us in the industry, who work on website projects day in and day out, these terms and phrases are commonplace. That is to say, easily understood and tossed around with a certain degree of casualness in daily conversations.
For our clients, though, these words and others we use so frequently while discussing website projects, might as well be an entirely different language. It’s easy to forget how confusing and overwhelming building a website can be for people who don’t work in the industry.
If you’re not careful, and very intentional about client communications, these sort of “tech talk” language barriers can create tension (and unexpected time delays) throughout a website development project. For example, if a client doesn’t realize that approving a sitemap means approving the navigation of their main menu, or that their decision on taxonomy terms has structural implications for their entire site, you can find yourself going back to the drawing board and having to explain launch delays.
To make sure internal and client teams are speaking the same language, CHIEF uses a variety of tactics to communicate technical information at important touchpoints throughout the redesign process. Taken together, they help engage, inform and empower the client through the website process.
Let’s be honest, sitemaps are weird and require a bit of imagination. Traditionally, they are developed as boxes on paper that are supposed to represent many (but not all!) of the pages on a client site, and most of (but again, not all!) the site’s content organization. It’s no wonder that so many clients struggle to understand what exactly they’re looking at when they approve a sitemap. Next time you have to get a client to sign off on a sitemap, try drawing it with them. Sitemap workshops can sound daunting, but are incredibly helpful tools to help your stakeholders really understand what a sitemap is and gain buy-in from the get-go. One of CHIEF’s most recent redesign projects benefitted from having the client actually draw their own sitemap, which the team then compared to the one we had created. The exercise allowed us to discuss all the reasons why they were different, and why our recommendations were important to follow in some cases, and less so in others. It also uncovered entire sections of the website the client wanted us to accommodate but had not yet mentioned to us—which we otherwise would not have found out about until right before launch.
Wireframes are another often eyebrow raising website development deliverable. Designed to convey what content will be on key pages, wireframes use only modular boxes with placeholder language. Many agencies include annotations about what each section on the page is used for, what kind of content goes there and how basic functionality will work—but these notes often get lost in the mix, or provide room for interpretation that can cause problems later on. The solution? Developing dynamic wireframes. Creating clickable wireframes requires more work on the upfront but will ensure clients have a fuller understanding of each page presented, thereby mitigating hasty and half-understood approvals. With dynamic wireframes, you can walk the client through a user’s journey for a website that requires a sign in, show them exactly what results will appear when a user clicks on a taxonomy term, how their breadcrumb will work, and even in some cases, showcase hover-state or dropdown styles early on.
There are also situations where even clickable wireframes don’t provide the level of detail needed. This could be because the website is very complicated, or perhaps you have a client who has never gone through the process of a website redesign. In such cases, it may be worth the additional upfront time necessary to prototype the site. A prototype is a mid-to-high-fidelity model of the final user interaction of your website. Prototypes give clients an opportunity to see more details of the visual elements of your site, and also usually allow them to experience the first-level of the user interaction. The general idea of a high-fidelity prototype is to represent as close to the final product as possible. While it takes longer to create a prototype than a wireframe, it’s still less time than building and revising the front (or back!) end of a website. In order to clear up confusion clients might have about their website’s features and functions, it might be well worth the investment to get sign-off on a prototype early on in the project. Watch the video below to learn more about inVision, a tool we use to build prototypes.
Rather than relying on long-form documents or in-person presentations, CHIEF has been experimenting with working one, or a few, of the above strategies into our website redesign process. By bringing the client in early, and making sure they understand how content strategy, design, ux and development work together, you can keep projects on-time, on-track and under budget.
Got any tips for managing clients that may be green in the digital sphere? Share them with us on social media, we’d love to hear from you!