This is part two in a five-part series.
In part one I talked about hiring us and the inital kick-off of project work.
Here, in part two, I’ll be talking about our process(es). Process is a big part of what a design or development team does. It’s essential in getting to a successful outcome for a project. However, as important as process is, it is not the end-all-be-all of a project. The final design, solution, product, brand, etc. are much more important than the process itself.
Sometimes it doesn’t feel like that, though.
So, Why Is Process Important?
Well, a good process is sometimes a big way design teams can differentiate themselves from each other. On a high level, having a solid process can show you know how to get from an idea to a fully realized solution. On a practical level, a good process helps you get the day-to-day business of design done.
Some designers will tell you they have a 3- or 4- or whatever-step process they use all the time. While this might be an honest statement in some small way, it’s far from the truth. The truth about a designer’s process is that it’s usually a bit different for each client, each problem, and each project.
And that’s how it should be. Anyone who tells you different is probably leaving out some important facts about how design works. Design is messy and creativity isn’t something you can distill into a science. Mistakes need to be made, lessons need to be learned and all of that. The same could probably be said for development.
It’s impossible to have one canned process that works for everyone and every project. What is possible is having a solid process that flexes to fit the needs of the people working on the project and the particular problems they’re trying to solve. A process should enable people to do great work and provide a road map for doing so. Nothing more, nothing less.
That’s what we strive for.
Our Process At A High Level.
Our process begins before we even enter a formal working relationship. We do as much as we possibly can to understand the needs of our potential clients, the problems they’re facing, the goals they’ve laid out for their project, etc.
This “discovery” or “research” phase carries on through the initial kick-off. We don’t overdo it, but we really do try to give everyone involved a pretty good snapshot of what we need to do, who’ll be doing what, and a plan to get to a successful resolution before beginning any real work.
As I’ve mentioned before, we also try to be flexible throughout the life of the project so we can make small course corrections along the way as needed (as opposed to taking major steps backwards and/or shifting focus radically along the way).
After discovery, we usually jump into a problems-solving or design phase. This phase is geared to be lean, iterative, and focused on practical solutions and deliverables. I think that when it comes to design, less exploratory work often results in a better final product. The reason for that is, it’s often the details that make a great design. The more time you have to nail down those details towards the end of the project, the better. Design doesn’t end when the photoshop comps are approved! We’re always dealing with scope, time, and budget constraints, so it’s important to spend time, energy and yes—money—where it matters most.
Once we’ve nailed down designs we’ll tackle development, which often requires a whole new process of its own. We revisit discovery with an eye toward fully scoping out what we need to build. We don’t often do a formal technical spec, as many of our projects don’t need that level of detail, but we do take the time to document everything we’ll be developing in as much detail as we can.
(Maybe you’d call that a traditional functional spec, I don’t know, I try to avoid semantic wrangling. Whatever works.)
On a typical project for us, development usually consists of front-end templates production, installing and configuring a CMS, and then integrating the two. We typically let one of our development partners handle anything beyond that. For example, on projects needing custom web application development, Blue Flavor will usually do all the front-end work and then (in a transparent manner) hand off any additional development to a chosen partner.
Sometimes development can be tricky, especially when we’re working outside of our front-end development/CMS wheelhouse, but we’ve found that the process doesn’t get too difficult if we’re honest about working with a partner and keep the lines of communication open.
Most often we’re working with our client’s in-house developers, and our process is perfect for that.
The Design Process In More Detail.
As I mentioned before, we try to keep our process lean, iterative, and flexible; and we prefer to focus on concrete practical solutions. Eliminating superfluousness from the design process means we can focus on problems, put all of our energy into one solid design or solution, and spend time and budget on what really matters.
So, exactly what does that mean? We start with a solid understanding of problems and goals. Our design process is geared toward avoiding what we call “solutioneering”, or prioritizing features and/or solutions over a good understanding of goals and problems. Avoiding solutioneering ensures we’re going down the right path and lets us make small course corrections, rather than huge changes in direction.
We generally spend a bit of time doing Information Architecture and or Interaction Design. In this phase we focus more on tasks and activities than we do on user details and fuzzy deliverables, like personas. That’s not to say we’re not user-centric in our approach—we are. We just get more bang for your buck by looking at what people do with a web site or application.
Again, it really depends on the project. I’m kind of trying to describe the typical scene here.
When it comes to creative—look and feel, visual design, etc.—we try to keep things lean. This means a short creative brief and a condensed and informal initial design phase. We don’t generally do things like mood boards, for example. I’ve never found them all that helpful. We also don’t generally do multiple comps. We prefer to focus on one solid design and iterate until we’ve got the best possible solution.
We also like to keep the design team small, especially on the client side. Over and over again, I’ve seen that a smaller, leaner, more focused team and approach will usually result in a stronger design. Of course we’ll adapt to our clients’ needs but again, the best designs are those that are focused. It’s hard to focus when you’ve got ten people all weighing in on a design. Design by committee simply doesn’t work well.
In the next part of this series I’m going to talk about how we do design and how our clients can ensure they’ve enabled us to get to the best possible design for their projects. So, more on that next time.
Scoping Development.
I’ll admit that we occasionally struggle with scoping and managing development, particularly when it comes to complicated dev work. The harder and more complicated the development bits of a project are, the more we struggle.
I don’t think this is uncommon. Development requires a different process that needs to be more rigid, especially in a work-for-hire situation, than design does. Because of this, we often avoid getting into projects with complicated development needs, especially when those needs aren’t well scoped out.
The key to a successful development phase is knowing, in great detail, what needs to be done before you begin doing anything. Beyond this, everything depends on the team. For example, we’ve worked with developers who prefer an iterative process (which jives well with how we work), and we’ve worked with developers who prefer a bit more structure. That’s worked out ok as well. Again, it’s about having a good handle on the scope, features, etc.
But take all this with a grain of salt. We don’t do much complicated development and I can’t speak with authority about the development process as it relates to anything aside from front-end development, which is pretty straightforward.
Our development work typically involves building/testing/fixing until things function how they should. When it comes to what we know (XHTML/CSS/JavaScript/CMS), this is usually a pretty painless process.
Common Deliverables.
You might be wondering what kinds of documentation we produce. We use deliverables to document design decisions and illustrate the completion of key milestones, but I want to be very clear—our process is not about creating deliverables. Our process is really geared towards a final solution. The artifacts matter, but they aren’t the end-all-be-all of the project.
Having said that, we try to document design decisions in as useful and practical manner as possible. I’m not going to get into the specifics every type of deliverable, but you could expect to see the following in an end-to-end application design process:
- A Project Brief. A project brief is a lightweight yet informative overview of the project. We use these on occasions where we feel a formal overview is helpful.
- Personas. These are narrative snapshots of a site or application’s users. We don’t do these often, but they can be very helpful during the discovery phase.
- Scenarios, Use Cases and/or Activity Matrixes. When doing heavy interaction design, such as the UI design for a web app, we like to identify what kinds of activities and tasks a potential user will be performing.
- Page Description Diagrams and/or Wireframes. Once we’ve got activities and tasks outlined, we usually begin to tie those to content and UI elements. Page Description Diagrams (PPDs) are a prose-like way to do that, with very little focus on actual look and feel. Wireframes take PDDs a step further by outlining layout and look and feel.
- Composites. When doing visual design, we’ll usually deliver comps built in Photoshop.
- Templates. We often deliver static XHTML/CSS templates for use by our clients’ internal teams.
- Functional Specs. When doing complicated development, we prepare a functional specs document.
For specifics about the kinds of documentation we create, see the notes and slides from my Web Application Summit talk.
Project Management.
We try to keep our PM overhead very low, since we don’t find a whole lot of value in over-management. Focusing on getting work done and keeping lines of communication open helps keep the PM load light.
We generally excel at project management, mostly because of our very straightforward approach. Our clients work directly with the team and don’t have to force all communication through a funnel. Project management is definitely intrinsic to our success, even though it’s not as important as the actual work we do.
Open communication, setting (or resetting) proper expectations, and making sure roles and goals are understood is generally all it takes to keep things running smoothly.
The Bottomline.
Our process is solid and lean, yet extremely flexible. We focus on getting actual work done and spending time on the final product. We work as iteratively as we can, while trying to clearly lay out milestones and check points.
Our goal is to get to a great design, even when the path to doing so can be winding. We do our best to roll with anything that comes our way.
Of course, much of our success comes from how our clients interact with us. We look at each project as an opportunity to team-up with our clients, who are just as much a part of that team as we are. In the next installment of this series I’m going to give some tips on how clients can best work through this process with us (especially when it comes to giving feedback, enabling us to get work done, and letting us help them help themselves).
This was (yet another) very interesting article Keith. Without stating specifics, you have provided a good overview of Blue Flavor’s processes. Your remarks about ‘solutioneering’ particularly caught my attention.
Your clients must be very grateful how your process and project management is centered on the work/results at all times and doesn’t get knocked off course along the way…that’s really important.
Scoping…yeah, that is a tough one (I’m getting a sense that this is one area that causes the biggest headaches for designers/developers right?)
Looking forward to the third article Keith! :)
Keith,
Thanks for sharing your process. I think it is shows very sound philosophy and appeals to me as one who wants to provide practical solutions to those I work with and their users.
I have really benefited from your discussions about problem solving and how that should be the basis of design decisions. I like that you think in these terms and not in terms of “features.” I think this leads to much better solutions.
Thank you sharing a bit of the Blue Flavor design process. Coming from a company that historically produces Mood Boards and the typical “3 Look and Feel Comprehensives”, I find it highly intriguing that you avoid both, and focus in on one recommended design solution.
While I can see the benefits in different methods, I see how your methodology could realistically allow for more focused time on the solution, and the refinements of the details in which make a great solution. I’ve seen many designers focus so much on options to either appease a client or a contractual agreement, and left with little time to really refine in the end.
In my experience, many clients seem to have been trained to expect to see several explorative options, rather than moving forward with the design team’s best foot forward. What are your thoughts around managing client expectations?
This was a great read and certainly something I would like to discuss with you in more detail.
I appreciate the openness of your process. I agree that focusing on too many deliverables throughout the process actually impedes progress toward the final goal.
How does content play into your process? Do you perform any standard content audits or have any strategic tools to focus the content?
Anthony - In regards to managing a clients expectations. If they wanted three comps badly and were willing to pay for that, we’d give them the option. However, usually once we explain that they can get much more bang for their buck (and I firmly believe that to be the case here) they are more than happy to go with one.
This rarely comes up to be honest. We usually explain our design process a bit up front and most often a potential client is good with that.
I have yet to see a good explanation about how three design options can result in one better design. That simply makes zero sense. The only thing it does is provide options, which are then usually subjectively compared against one another and them mushed together into a “camel” which is generally not a strong design.
No, I think the argument for one comp is usually a strong one.
I could see if you were using different designers for each comp how it might make some sense, but then again…you still have the “we’ll take the type treatments in comp #1 and the navigation from #2…”
Maybe this is an issue that I should write a separate post about. But if there is one thing I think I know about the agency world it’s that some of the traditional conventions were put in place to get more money out of clients NOT necessarily to get to the best design. I think this might be one of those.
Having said that, I’m open to heading another side of the story, I’ve just not heard an argument I’d consider very compelling.
Keith - Thanks for taking the time to elaborate. Your response is exactly what I was hoping to hear. I personally agree with your statements, especially that “the traditional conventions were put in place to get more money out of clients NOT necessarily to get to the best design.” I’d also like to add that it’s a waste of good creative energy to go through the motions just because.
I hope that more designers and design companies can start to be as upfront with their clients and confident in their craftsmanship, to focus their time as you have described, and continue to be open to sharing their process with others.
Keith,
this is the kind of article educational for both customers and other design firms and designers.
Thank you for sharing your experience.
We struggle with this to - even some of the best customers who have a really good idea of what they need still have bits and pieces of functionality in their heads that we discover along the way and have to adjust the project accordingly.