The Discovery

This is the second post in my series on Clarity, the website development process I created. This post will cover the first of six phases, Discovery.

Discovery encapsulates a critical point in the life cycle of a project. It’s when I learn more about the client and the details of their project. It’s also when I determine if this client is a good fit for me and if I feel I can complete the project to my standards. Most importantly, this is my opportunity to explain to the client what they can expect from me, and what I expect from them.

Before I get into all that though, I want to give some space to who I created Clarity for. I don’t think I outlined that clearly in the first post. This is a process I developed for clients who haven’t been given the kind of attention they deserved in the past. They’ve got broken, neglected, and poor performing sites because an opportunistic developer who didn’t give a shit about their businesses needs hacked something together to make some fast cash. Clarity is for the client who needs a trusted partner to interpret their needs and do the right thing for them, without having to ask or even know what “right” is.

Because the type of client I described needs my help the most, I made the process as robust as possible, and put research at the center of it. My goal with Clarity is to undo the damage of a bad website by building a well made replacement that becomes an important sales and marketing tool for their company. Let me just climb down off my soapbox here and get on with the Discovery Phase of Clarity.

Okay. Discovery is exactly what it sounds like — I learn about the client’s company and the high-level details of their project. In getting to know the clients business, I go beyond the basics and try to get to the root of how their new website can work for them rather than merely exist as a pile of information. What makes their company unique? What makes their product or service unique? What are the things they are taking for granted? What aren’t they communicating? What are their challenges? How can I add value to their team? Where are your bathrooms?

I also ask questions related to the scope of the project like who comprises their in-house team; who their competitors are; their likes and dislikes, goals, and any technical information they can share. Ideally, I conduct this interview in person, but a conference call can be just a productive. The answers help me begin to focus in on what types of goals I should consider for the site as well as how much research I will recommend.

If the answers come quickly and are consistent; it’s a good bet they know what they need. If my questions raise more questions, I may recommend further research to help the client realize what it is their site needs to do. Finally, the Discovery phase gives me insight into how the client’s company is organized, the internal politics, timelines, budgets, and motivators. All of which are instrumental in determining how I will deliver the best product possible. It can be an intense process at times. One that can drift into areas most developers are happy to gloss over or ignore entirely. In the end though, the website is the better for it.

Furthermore, I, and my client, have a clear understanding of what needs to happen on the project. They also have a clearer understanding of what to expect from me, and vice versa. At this point I have enough information to quote the project. Work begins as soon as I get sign-off on that bad boy.

In the next post I’ll cover the first phase of that work, Research, and how it builds on the Discovery phase and sets me up to make informed design and development decisions, and work at my most efficient.