(Part 2 of 3) Website Blueprints: Invaluable Website Consulting
Today’s blog post is a continuation of my interview with our lead Website Blueprint consultant, Rob. If you’ve not already read Part 1 of this interview, I recommend you do that first before reading today’s post.
What’s the final deliverable in a Website Blueprint consulting project?
Erin: So, you've mentioned a couple of times that high level executives, all the way to programmers or developers, are going to be looking at this document—at the final Website Blueprint.
Can you tell our audience what is the final deliverable? Is it some extremely complicated, complex document with a summary in the front? When a client gets a Blueprint, what are they going to be looking at and do they usually need a walk-through?
When delivering a Blueprint it's going to be a PDF document that's written in a way that's very conversational, that somebody without technical or web knowledge could sit down and read and understand. We also will intersperse important technical details. There are times when one individual who's reading it might be okay with skipping over those details, and another individual might be really interested in those details. We consider this document as the bridge between the technical team and the non-technical team.
So, if you're in a situation where, either in your current project or in the past, there has just been difficulty getting everybody on the same page, the goal of the Blueprint is to do that in a way that we can all read. We prepare our website project Blueprints in a way that is very approachable, very human, very conversational, while still conveying all of the important details and requirements.
So, while some sections might be more interesting for one person versus another, depending on their exact goal, the goal is really to make this digestible and understandable for everyone, so that we can all work together from the exact same starting point, when everybody is engaged in this project in different ways.
Will a Blueprint cover just functionality, or is there more?
Erin: Rob, will a Website Blueprint have information in it that covers only a website's functionality, or do Blueprints have information about other parts of a website, such as design or online marketing?
Rob: It will cover the whole picture.
There are times when design and SEO, for example, will be really important parts of the project and, in that case, those will be addressed as part of the Blueprint, in addition to the technical stuff, which is more under the umbrella of programming. The other thing that we like to talk about, at least to some degree in Blueprints, is business goals and why we've chosen to prioritize things in certain ways, based on the business goals that the client has shared with us.
So, there will be times when we say, based on what you've told us, we think this item should really be a priority because it really forwards this specific business goal. And then, maybe this other item can be sort of like an afterthought or less important because it's like a bell or a whistle, but it doesn't really hit those key business goals that we've discussed.
So, we try to cover the whole gamut of design and research or marketing and other business goals that are not necessarily directly related to programming, and if those things are still important in the big picture of the project, those will be addressed in the Blueprint as well.
You can’t plan everything in a large, complex website project…right?
Erin: For the large website and app projects, it's obviously impossible to map out or plan every single detail of a final product, and a lot is learned during the project, no matter how much planning goes on in advance. You can't plan everything.
It's just a matter of fact that website projects never go exactly according to the initial plan, no matter how much you plan.
So, I'm curious if you can tell our audience about whether there's a danger related to over-planning when it comes to the Blueprint, and how do you try to avoid planning out too much, so that you can handle the need for flexibility that's required during large scale projects?
Rob: There are a few ways that we approach this. The first and most direct way that we do it is by specifically aiming to create phases of the project as part of the Blueprint. So, if we see something where we know this is going to be a six month or even a nine or twelve month project, we might say, okay, let's look at the first three to five months, and let's call that phase one, just to give you an example. Then we'll say, okay, what are our top priorities? What do we need to do to get this application or website online in a way that makes it useful, makes it hit a number of our key business goals, and allows us to create mini projects within the larger project?
What's nice about that is it's usually pretty easy to clearly define a phase one when we're doing the Blueprint project. So we can walk away from the Blueprint saying we know what we're going to do in the next three months or six months or whatever phase one looks like, and here are items one through ten that are going to be included in that scope.
Then, if we think about the second phase, we can say okay, here are the ideas for phase two in a rough order of priority, but we're not actually going to sit down and hash out every detail at this point, because we know that phase two is going to be informed, in a big way, by what we learn and experience during phase one and also by users or customers telling us what they like and what they don't like about what we did in phase one.
There could be an unlimited number of those phases over the course of time as we work on a project, especially for something like a web application where it's kind of a living, breathing organism that goes beyond the standard website.
So, especially where there's interactivity and stuff like that with your users, there's basically always going to be room for improvements in the next phase. So, to sum that up, we like to work in phases. We like to envision a project in phases. What that allows us to do is clearly define what we call a minimum viable product, or perhaps something a little bit more than that. Basically, that means get something great online, but also accept that it's not going to have every single feature on the wish list at that point.
Based on what we learned during that process, we start to work our way down the wish list in future phases where we make other pivots or changes in future phases. That’s the main way we avoid getting into too much perfectionism or too much thinking out many years into the future. I think there's a place for that, but you don't want to be planning lines of code that are not going to get written for six months or a year, because then you're getting too granular and, in some ways, it risks that you're missing the point of what you're doing.
We like to help our clients get something up and running and working as soon as possible. We look at that as a phase one or a minimum viable product. And then we like to plan out future phases in a very rough sketch type of way, as part of the Blueprint process, without feeling like we need to know everything that's going to happen that far into the future.
Erin: Exactly, because, no matter how good anybody is, you don't know what's going to happen. We're always surprised and there are always changes and there are always new things that are learned in every project that we work on.
Rob: And the other big thing that we like to do is establish that understanding and that kind of framework very early on in our relationship. I think that the discoveries and the discussions and the consulting that we do with the Blueprint really helps make that clear and gets everybody on board and on the same page with that approach.
Not every programmer and not every agency is going to be comfortable with that agile development approach that we take, where we're saying, we understand that there are things we don't know and can't know at this point and we're actually planning for that, because we know we're going to learn as we go. That's exactly why we break our website consulting projects into easily digestible phases, and that's why we are setting up this project in a way that keeps things flexible, so we're not beholden to decisions we made six months ago, if those decisions are no longer the best thing to advance our business goals.
We like to do everything that we can to create a culture of flexibility as early on in the process as possible. I think that really benefits everyone. It gives you the ability to pivot when you need to pivot, and it also gives you the ability to not get stuck in the weeds of very specific things that may or may not be that important in the bigger picture.
Tune in next week for Part 3 of 3 of my Website Blueprint interview with Rob.