So we’re redesigning our website. And since that apparently wasn’t enough for us, we’re overhauling our entire discovery and design process while we’re at it (we’re underachievers like that).
But as it turns out, this internal project has also taught us a lot about working with our external clients. We’re learning that the most important part of building websites isn’t the way we work. It’s the way we communicate.
So here are some of the tactics we’ve used to get better feedback from our team as we redesign yellowpencil.com. Borrow these ideas for your next project, and try them with your team or clients. And hey, let me know how it goes.
Talk to people early and often
Over-communication has been the key to our success. At first we were reluctant – would this lead to a design-by-committee (aka terrible) website? Would we be stuck forever in an endless loop of feedback hell?
Spoiler alert: we weren’t. Everything was fine. Here’s how we pulled it off:
Get feedback as soon as possible
We usually like to wait until we have “something” to show. It’s scary to let people see unfinished work, or decisions you’re not sure about yet. But we found out it’s never too early to let people into the process – talking through the foundational work like competitive audits and mood boards together helped everyone understand the decisions that came later. And it builds trust across the team.
But don’t take my word for it – here’s what one of our teammates had to say:
“Getting to see everything, even in-progress unfinished stuff was especially fantastic. We always knew what the current project status was, and it was never too late to provide feedback or input.”
Make it a regular event
We held open-invite critiques and presentations every Friday at beer o’clock. No matter what we had, we’d show it and talk about it together. Grab a beer, sit in a boardroom and talk about work – what could be better?
Just kidding, that sounds kind of boring. We were worried that no one would show up. But it surprised us how much people actually liked these sessions. We thought we’d have to twist arms and knock heads to get people to attend, but they were almost always full. And if we weren’t able to meet, people were actually sad. Or they feigned sadness for our benefit. Either way I’m going to call that a win.
Even our project managers enjoyed themselves:
“At every YP.com presentation, I feel like I’m experiencing what our clients feel and expect. All the worries before the meeting: 'will the new website and design will really represent our company?', or 'will it really showcase our culture?' The experience so far has given me lots of insight into the design process, and a new perspective that lets me relate more to our clients.”
Structure the conversation
We design websites every day, so we take the ability to talk about them for granted. But it’s hard for people to give feedback on a process or product they don’t understand – what’s up for discussion? What’s set in stone? What’s helpful?
You can help your team give better feedback with a few easy steps:
1. Always start with the history
Every week we started our meeting with a summary of everything we’d done to date, and how we got to where we were. It might seem a little redundant, but it’s important to frame the discussion. “Oh yeah, we did talk about why this colour palette worked,” or “right, I remember why we decided to call it that.” It reminds everyone that they’ve already been a part of the decision-making process.
2. Talk about why you’re doing this
If you don’t spend all day designing, it might be tough to understand why a style tile is important, or why your content strategist cares so damn much about labelling conventions. Explain why you’re doing each thing you do, and how it will benefit the end result. “This style tile will help us set the direction for the real website design. We can iterate quickly and talk about visual language without getting bogged down in the details.”
As one of our developers put it:
“Seeing the small fragments, from sketches to style tiles, turn into an actual visual design was astounding. It’s hard to visualize how it will all come together when you see all the small pieces on their own. And then it does!”
3. Tell them what makes something “good”
I’m not a developer. If someone showed me a block of code they wrote, I would have no idea how to evaluate its goodness or not-so-goodness. It’s the same with content or design work. Especially with visuals – people often have a “gut feeling”, but don’t necessarily have the background or the vocabulary to articulate it.
So help ’em out. When I present a sitemap, I give everyone guidelines on what makes a sitemap successful. Does it map to our users’ tasks? Does it use our customers’ words? Are there multiple ways to access information?
That way, instead of relying on their gut, people can give feedback on how well you’re meeting your real success criteria.
4. Be explicit about what you want feedback on
Be super clear about what you’re looking for. Ideally it should map to the success criteria you talked about earlier. Even better if it’s focused on your end-users (not your stakeholders). I like to give people two to three questions to answer in their feedback. If you have a whiteboard nearby, write ‘em down. If the conversation gets off track, point people back to those questions with a gentle “that’s great feedback, but what do you think about those questions we talked about?”
Bring people into the process
This was the biggest (pleasant) surprise for me. We brought our internal stakeholders directly into our process by having them participate in feedback surveys and card sorts. We put them through everything we normally would with our end-users.
And while it didn’t give us actionable data the same way end-user research would, it was amazingly great for buy-in. Our team – project managers, developers, and system admins alike – started to understand the complexity and value of the design process. “It’s hard to organize all this content!” I heard over and over. “You guys do this for every project?” Best of all, that led to more valuable feedback, because everyone participating had more insight into the process. Success all around!
More kind words from kind coworkers:
“The review meetings were great. I didn’t know much about the discovery process our clients go through. I had heard of tasks like "card sort" before, but never knew how one was done or the real benefit of doing it. The review meetings gave me a better grasp of what the other teams actually do and why discovery is important.”
We’re almost done the design phase, and our CMS build is in full swing. Keep an eye on our blog for even more lessons learned as we continue to learn ‘em. And get in touch if you have any questions about our discovery or design work – I love to chat process.