Designing for print and the web are two very different processes. And believe it or not, there's still a lot of confusion about this. Let me first start by freeing your mind of at least one thing that keeps this confusion alive: the image we think of when we think of design. You know the one I mean. The solitary designer, sitting at her messy desk — but messy in that work-is-fast-and-beautiful kind of way — surrounded by images, production samples, and paper, perhaps staring intently at a screen, scrutinizing some detail she'll want to get just so before finally calling this all-nighter quits. This is the stuff of Design Sponge.
It's really a quaint image, one that most designers still haven't let go of despite the fact that it really bears no resemblance to the reality of interactive design. In fact, we're emotionally committed to that image because it employs the full range of our contradictions — our desire for thoughtful, even leisurely, creative work, coupled with our need to validate it by hours of arduous martyrdom. But, this is holding us back. It causes us to make the wrong choices about how we approach our work, from the earliest stages of ideation and planning, all the way through production. It causes us to isolate when we need to collaborate. It causes us to oversimplify when complexity needs to be apprehended, as well as overwork details far beyond any reasonable expectation of use. It causes us to think of edges where there aren't any, and endpoints at the times where things are actually just getting going. In short, the wrong kind of pre-visualization will make for the wrong process and the wrong product.
I really have no business trying to correct this. At its root, it's a psychological problem that cannot be solved by words. It's bigger than our professionalism, and bigger than the sort of problems that I'm qualified to write about. So while perhaps out of scope for this platform, don't for a moment underestimate the reality of what I've described. I've explained what I'm about to share with you — a step by step web design and development plan — enough times to know that a plan alone does not a successful designer make. Like any of our great, human struggles, you've got to first admit it exists before any method will help you overcome it. And yet, it's just possible that I'm making much more of this than need be — that all you really need is a bit of insight into how the web design and development process works. Who's doing what, and how, and when.
Either way, you're in luck. What follows is just that: a straightforward outline of how we do things with a bit of explanation here and there.
Let's start this plan with planning.
What I mean by planning is a focused time during which a team solidifies a project's parameters. Imagine people discussing things around tables. Oh, and whiteboards — we love those.
What's happening here is that the client brings to the table their business objectives, and the team responds with a strategy to meet those objectives built upon a wide range of best practices that make up their expertise. The audience is identified. A content strategy is developed. A data flow is sketched out, which properly orients the website that will eventually be built among an informational ecosystem which includes its content management system (CMS), a customer relationship management tool (CRM), and a marketing automation platform. The group figures out how long this project will take, and how much it will cost. All these details are documented, and a plan — similar to the one visualized below — comes together.
This could take anywhere from hours to weeks, depending upon, well, all kinds of factors, but for now, we'll just call it "project size."
And yes, the client pays for this; it is work.
Next, more planning. But this time of a more concrete variety. We call this prototyping. A prototype is essentially an interactive wireframe that describes the information architecture of a website, as well as aspects of its user experience. The interactive component — that it's clickable and navigable just like a website — is what makes this form of documentation so superior to a typical wireframe, which fails to communicate simply because its trying to describe screen-based interaction with static, printed pages. A prototype bridges the gap between printed site maps, lists of technical requirements, and the final website by serving as a form of documentation concerned with informational hierarchy and functionality, not aesthetics. It's a dress rehearsal, but without the dress. That's why it's grey.
To be fair, the relationship between prototyping and design is fuzzy. I've already written an exhaustive piece on just that, which I'd recommend you open and save to read later when you're ready to dig deeper into this subject.
For now, let me quickly review the sequence of prototyping.
The order in which you actually build a prototype may be, in some places, somewhat counterintuitive. To bring clarity to that, I've broken this process down into six typical stages which tend to elapse over the course of 6 to 8 weeks.
Stage 1 involves identifying the overall page structure of the website and organizing pages within navigation menus in order to make them all intuitively accessible to users and indexable by search engines. Pretty straightforward. Two simple recommendations for this process: 1) consolidate! You probably don't need five different pages to describe your company culture. This principle applies across the board, because the most typical website user session is a brief one. Longer sessions are valuable because those users gain exposure to so much of what you have to say. But that doesn't apply when you're squandering their attention. 2) Speak human. There's little reason to name your blog anything other than "Blog" — especially not in the navigation menu — unless you want to make sure that nobody reads it. Really, "The Thinkery" is not nearly as clever as you think it is, and it definitely doesn't tell anyone what sort of content experience to expect. So don't do it. Also, really? The Thinkery?
Next, in Stage 2, the key landing pages should begin to take shape. These are the pages that articulate areas of expertise, services, or products. The stuff that puts you in business. More than simply accounting for them in the structure of the site, this stage should involve specifically outlining the information that these pages will provide and organizing it within a usable template.
Here is also a good place to think about how many unique templates the site will need to have. Even though visual design has probably not reached a specific layout stage (it may be running concurrently with prototyping depending upon how long the prototype has been in development or whether bigger-picture design work is being done), it's good to be able to anticipate how labor-intensive that process will be.
Stage 3 is similar to the previous one, but rather than focusing on the most important informational pages, you should now devote your attention to those pages containing supporting content. Supporting content is the material central to your content strategy — newsletters, whitepapers, case studies, blogs, videos and the like. Ideally, you've already decided upon which content platforms make sense to your marketing plan (in the planning stage) and are feasible for you produce in a sustainable manner. A helpful resource here might be a piece I recently wrote on the four stages of content marketing.
Once those are in place in your prototype, you'll need to give some thought to calls to action. What are you offering your users? What do you want from them in return? Those are essential questions to ask. Answering them will help you decide upon the specific conversion points (forms) your site will contain, as well as the specific information you will require (fields). Once those decisions are made, you might extend that conversation to address a longer-term progressive profiling plan, depending upon whether you are doing any marketing automation at that point.
Since your brain will be fried by hyper detail, it's a great time to make it hurt more by taking what I call a "metadata break" in Stage 4. Hey, no pain, no gain. I'm kind of joking, but it is important to pause after Stage 3 and focus in on the metadata that each type of content you create will contain, and how that information will support related content and search tools.
Two examples might be in order here: 1) Tag clouds used to be all the rage. They were very "web 2.0." But then we realized that, given the opportunity to completely undermine a potentially-useful system, we will. You know what I'm talking about. First, we called them "clouds," and nobody has any idea what that means. So strike one. Then, we stuffed them full of redundant stuff because each time we wrote a post, we tagged it a little differently. So we ended up with posts tagged with several different tags that essentially meant the same thing: "branding," "brand strategy," "brand alignment," "re-branding," "brand positioning," etc. And then the next time we wrote something about branding, we tagged it something else. This makes for a giant cluster of words in our tag cloud that nobody will have patience to sift through. You thought I was going to use cluster in a different way, didn't you? Having learned our lesson, we decided to just hide the tagging system. It's still there, but it powers our related content tools, so that if you're reading a post about branding, it shows you five other posts on the site that have the most tags in common, and in order of recency. This keeps the content experience fresh and relevant to the user. You still need to show restraint with your tagging in order for this to work. But I generally recommend thinking through your tags early. You might also have a separate and shorter list of categories that are displayed visually as a filtration tool. Again, you'll want to decide upon those first. 2) Let's say you have products to sell. All of them will have obvious attributes to display on the product's detail page. But sometimes, those attributes need to be indexed differently in order to make searching better. For example, if you sell a t-shirt that comes in five different colors, often the alternate images on the product detail page cover the color options. But the specific words — red, blue, white, grey, black, etc. — need to be associated with that product in the site's database and then indexed by a website's search and filtration tools in order for a customer to be able to type in "red" in a search bar and get products that are red that may not have the word "red" displayed on their pages. Other attributes that might need to be searchable but not always displayed might be sizes, weights, materials, or type names (e.g. "clutch" or "tote" if you're shopping for handbags).
Got it? Great. On to Stage 5.
Stage 5 is focused only on your website’s home page. Since you’ve identified the structure of the site, its content, and how it will engage with users, a sense of priority should now be clear and help to make home page content decisions simple. It can't contain everything. The more you put there, the more you need to focus on priority. Though we've all moved past fussing about the fold, the homepage is one place where I think that still matters. You've got just a few seconds to create the right first impression on a visitor, and if you've not properly prioritized what that visitor sees within those first seconds (yes, like literally what's on top vs. beneath that), you may lose them entirely.
Finally, Stage 6. This one is really an accounting process. It's where we figure out all the various integrations the site might have — with email tools, CRM, marketing automation platforms, incoming feeds, inventory reconciliation, payment gateways, etc. Often, these integrations will make functionality possible that has already been discussed in earlier stages, but at this stage, all the invisible logic involved in them would be documented. That also includes gathering and storing login credentials for these systems and their APIs. I can't tell you how many times we've gotten weeks into development and realized that we can't continue because we never received the username and password for a client's CRM account. Duh. So Stage 6 is boring, but very, very necessary.
Now, we can approve the prototype. This prototype is the final source of truth as far as the project's scope is concerned. So it's imperative that it be as clear as possible, heavily annotated, and made accessible to everyone involved so that nobody be left in the dark about what will be built once production gets underway. Note: that does not mean printing out every page of the prototype, initialing them, and faxing them around or whatever. You laugh, but this has been done.
I mentioned earlier that the visual design process may begin before a prototype is resolved. We begin this process by creating mood boards, which we often refer to as prototyping, too, except rather than information architecture, we're working on the imagery, colors, textures, and typography that make up the look and feel of a website. So think of them as design prototypes. As you might imagine, these documents might look like a webpage layout at first glance, but closer inspection reveals that they're actually pretty collage-y. They exist to articulate how things will feel, not how they will work. While the prototype focuses everyone's thinking on information and structure by being unencumbered by aesthetics, mood boards focus everyone's thinking on how aesthetics relate to the brand and purpose of a website by being unencumbered by specific page structure. By keeping them separate but relatively in parallel, we make it easier to think about the right things at the right times.
Once the prototype and mood boards are approved, the look and feel of a website can be applied to the resolved structure. This produces what we're used to seeing in the web design process: specific page layouts that look as close to how they'll look to a user as possible. Stock images of handshakes and everything!
This often requires multiple rounds of revisions, as you can imagine. Some day I'll write something on just that, and specifically how to preserve what we call the "narrowing funnel," but for now, I just want you to be able to envision how this process — the thing I'm assuming you're most familiar with — fits in with the overall program.
Once the prototype and designs are approved, production can begin. This is the coding part. I constantly use pizza as a metaphor to emphasize that the web design and development process is far more complicated than placing an order and waiting for it to arrive. Instead, it's more like placing an order, revising it many times, and then making the pizza yourself. Except for maybe this one step in the process. The actual programming isn't something that you should expect to be closely involved with. So maybe this is like a bit of the really technical parts of pizza making consolidated into one phase — the making and throwing of dough, the firing of the oven, the baking, etc. — or maybe this is just where the metaphor breaks down.
In any case, production is when the thing we've been planning and designing actually gets made. You can expect it to be a quiet time, relatively. Because of that, we use this time to take care of some other things…
Marketing Automation Setup
…things like setting up marketing automation systems!
While the developer has his or her head down, focusing on all that beautiful mathy stuff, you can turn your focus to setting up marketing automation accounts, learning how they work, and planning the logic for things like drip nurturing campaigns that begin with your soon-to-be-baked site's calls to action. We guide our clients through this process step by step, which usually takes a good portion of the production time. There's a lot to learn and many details to account for. But it's ideal to have a marketing automation plan in place before the site's completion so it can be tested along with the site during the quality assurance phase, rather than separately.
Remember, if your website is collecting information via calls to action, that information is going to be received and processed through your marketing automation system's logic. So, that needs to be set up before the site can be finished.
Feedback! (a.k.a. Quality Assurance)
The feedback phase — also known as Quality Assurance (Q.A.) or the "tweaks" phase, depending upon who is mentioning it and why — is purgatory. Not purgatory in the modern parlance, an ambiguous waiting period in which we awkwardly await the next thing. I mean purgatory in the medieval, purging of ego through repeated thrashings and laborings and weeping and gnashing of teeth yet with a small bit of hope for reprieve someday, someday. It's the long stretch of time where you will feel like you are comprehensively failing, because, no matter how good the plan, no matter how beautiful the design, no matter how excellent the code, there will always be things that need to change once you've seen them finished. On that note, I'm going to self-quote from an article I wrote just about a year ago on how to do usability testing, because everything I really want to say about why this feedback phase always feels painful and disappointing comes down to one idea (just substitute Q.A. for "usability tests"):
"There are no perfect launches. It's appropriate that we refer to launching a new website as "going live"; a "live" website begins to change radically and rapidly once it starts being used, which demands ongoing maintenance: bug fixes, design tweaks, functionality changes, and the like. Though we were anticipating a focused round of work a year after launch — what we often refer to as a "Phase 2" — we had been consistently maintaining our site since its relaunch, discovering things that we just would not have been able to anticipate until it began to be used. I say all of this to answer what I can imagine might be anyone's response to the kinds of things usability tests reveal: "Why didn't you build it that way in the first place?" The answer is simpler to say than it is to experience, but I assure you that the reality is sound. You can build a website with all the intelligence, care, earnestness and good intentions possible, but you will find that some of your decisions were good guesses that proved wrong.
One of the wonderful things about the web is that it is interwoven with the people who create and use it, making it an organic entity and environment that is just as unpredictable as the rest of our lives so clearly are. Our job is to continually adapt what we do and how we do it as we learn new things by observation — it's all a work in progress. So, moving on: usability tests will reveal better ways of doing things that you've already spent time and money doing differently. It's ok; that's exactly what they're for."
Or, more succinctly, "You don't find anything out until you start showing it to people." Those are David Kelly's (founder and CEO of IDEO) words.
So now you know why. The how is pretty straightforward, though it's done through a combination of things. Before we reveal the completed site to our client, we do a preliminary round of quality assurance based upon a test plan put together by the project managers who have guided the project since the beginning. A portion of the plan covers general functionality testing that would be relevant to just about any site, but the meat of it would probably be custom to the functionality and logic unique to the particular site being tested. Once that process has been run, the resulting feedback is delivered to the developer, who can address any mistakes or adjustments that need to be made.
Additionally, the site needs to be tested in different browsers to make sure it appears and functions consistently in the various contexts in which we expect it to be used.
Once these steps are taken, the client can be trained on how to use their new site and begin the process of content entry — which, incidentally, is really a form of quality assurance itself. After all, David Kelly's principle extends to everyone involved in a project like this, not just those of us in the kitchen.
This is why I began by describing the feedback stage in terms of how it feels. What it is? Pretty straightforward. But how it feels and how we respond to that is what makes or breaks a project. This is when project managers run out of steam. This is when clients feel disappointed or mislead. This is when designers lose hope. This is when developers lose patience. Unless, that is, we are prepared in advance for setbacks and able to appreciate what has been accomplished thus far. It really is a matter of expectations and outlook. I have a rather pessimistic post-it note on my office wall that reads, "Expectation is disappointment waiting to happen." There's wisdom there. But if one expects a bump in the road, the jostling is far less unpleasant.
Launching a website, or "going live" as we say in the biz — good god, I said biz; no, I typed "biz," which is far more egregious — is really a brief moment in the grand scheme of things. It typically takes just a couple of hours of coordination and technical maneuvering, after which comes another round of testing just to be sure that going from a staging environment to a live one didn't break anything. After that? Beers. Or whatever form of celebration you see fit. Cake is also nice.
After that, well, it's really just the beginning. Now the public will start using your site, which tends to change everything ;)
So, there you have it: the web development process.
Minus, of course, any technical detail whatsoever. And probably a million other details. Ok, so let's face it, at the risk of sounding grandiose, this has been to web development what a survey course would be to something like history or philosophy: Just barely scratching the surface. But you've got to start someplace, right? What I hope is that this gives you a view with a bit more clarity than what you may have had before. If there are specific questions or points on which you'd like some clarity, please let me know in the comments below. Each of these sections are tips of their own icebergs, and I'm happy to plumb the depths a bit more if need be. Thanks for reading!