Navigation

Overhauling our discovery process

A 4 minute read written by Alaine June 24, 2014

Share this post on

So we’re redesigning yellowpencil.com. Our website is ancient by Internet standards (2012 is basically the dark ages), and our company’s grown a lot since the last iteration. We have different things to say to different people these days.

But it’s tough to find time to deliver internal (aka non-billable) projects in between all that client work. And like our clients, we’re dealing with timeline and budget constraints. So we’re making some major changes to our process, so we can be nimble and flexible while still delivering high quality work.

Our goal is to make our process as lean as possible, while still getting the insight and feedback we need to be successful and make sure everyone’s happy with the final product. This will be the first step in redesigning our entire company’s project process into a Leaner (yes, capital “L”) model.

So in this ongoing series of blog posts, I’ll be taking you through our experiments with the new yellowpencil.com project process. You can learn from our successes and not-so-successes, and maybe try it out yourself.

Extra-lean discovery

Discovery is the first part of all of our projects: we have to get to know our client and what we want to achieve. Our usual discovery process is pretty thorough. Since our projects usually last a year or more, we sometimes spend weeks talking to stakeholders and users to find out everything we can about an organization. This wouldn’t cut it for yellowpencil.com – we don’t have enough time, and we already know a fair bit about the company and the requirements, since, you know... we work there.

So we pared down our usual discovery activities and deliverables and stuck to:

A prioritized (and quick) list of requirement epics

We created a concise list of epics that capture the scope and priority of the things we wanted to accomplish with our new website. This list was definitely not as detailed as what we’d create for a real client, but that was the point – we wanted to get the major requirements down on paper as quickly as possible so we could move on. Our leadership team went through the list and prioritized them.

Why this was awesome: It got our leadership focused on priorities instead of I-want-it-alls. They understand that we’ll build the stuff that most benefits us, but we might not have time for everything. Ideal in a small budget and short timeline situation. It also keeps the project team focused on the highest-value work.

Post-it note user profiles

Actual user research can take a lot of time and budget. We had neither, so formal user research was out. But! We still wanted to make sure we weren’t designing for ourselves – it’s hard to avoid bias when you’re designing for your own company.

So we spent a morning creating what we call “post-it note user profiles” – quick, messy stories about our five most important user groups, like “Robert the municipal government CIO”, and “Sarah the transit company communications manager.” We defined their traits, motivations, and pain points to help us create better content for their needs.

Why this was awesome: Statistically significant? Okay, maybe not. But they’ll help align our project team and stakeholders on who we’re designing for, and help us prioritize features and content according to our audiences and what they need.

Collaborative competitive audit

We do competitive audits for almost every client. They help both our team and the client’s team get to know the competitive landscape, and gather ideas for the project. But they’re usually pretty hefty documents – 40 pages or more. We needed the insight without the documentation burden.

So we did a collaborative competitive audit. We developed a series of questions based on our requirements (“How do other companies communicate their culture?” “How do other companies explain their process?”), and got everyone in the company to throw examples into a collaborative Google Docs presentation. Then we spent half an hour at beer ‘o clock discussing what works and what doesn’t work on all the examples we pulled together.

Why this was awesome: it let us have a collaborative, critical examination, instead of a passive, one-sided document review. We all examined our assumptions and dissected what was really working on the examples we found, leading to more considered design work later on.

Internal card sort

We ran an online card sort (using our very favourite tool, OptimalSort) with the whole YP team. We analyzed the results and did a short presentation on our findings to the whole company.

So why test with YP employees when the whole point of the website is to talk to external users, you ask?

Good question. You see, this one wasn’t so much to get insights on the IA or navigation structure. Our goal here (somewhat sneaky, I’ll admit) was to teach the rest of our team – developers, project managers, system admins – about our creative process. How do you organize website content? How do you label it? It ain’t easy, folks! The process gave everyone on our team a chance to be an IA-for-a-day, and gave them tonnes of insight into how we work: the activities we do, the insights we look for, and how we use our research to inform the design.

Why this was awesome: everyone felt bought-in and involved in the process, leading to a happier team and more support for the project.

So what’s next?

We’re now knee-deep in the design and content creation process, creating wireframes, content models, and style tiles. Stay tuned for more blog posts about our design process (and the final product, of course).

And hey, if you have questions about our lean discovery process, give me a shout! Would love to talk more about what we’ve learned in our journey so far.