The Anatomy of Web DesignFeb 18, 2010 In Process By Nishant Kothary
We redesigned MIX Online in the Winter of 2009. In this article, I’ll share how we did it. In elaborate detail
This article is part I in a series covering the topic of Web Design. Part II—The Future of Wireframes, part III—A Common Sense Content Strategy, and part IV—Discovering Trustworthiness are available for your reading pleasure. Evan Sharp will contribute the final article. Follow us on Twitter or subscribe to our RSS feed to be notified of its publication.
Yes We Can
Apple is the undeniable master of timeless marketing. Take this example from an ad they ran in the late 90′s:
Here’s to the crazy ones, the misfits, the rebels, the troublemakers, the round pegs in a square hole, the ones who see things differently. They’re not fond of rules and they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them, because they change things. They push the human race forward, and while some may see them as the crazy ones,we see genius,because the people who are crazy enough to think they can change the world, are the ones who’ll do it.
I’d be stupefied if that doesn’t inspire you on some level. It’s a cliché, but it brings to life one of our deepest and most innate evolutionary traits: the desire to make a difference.
OK, I’m about to get a little emo on you. Ready?
At Mix Online, we like this cliché. We believe that, on many levels, Microsoft embodies it. We see Microsoft’s unparalleled ability to make a global difference. We have faith in its thousands of smart and well-meaning thinkers and innovators.
We’re also aware of Microsoft’s imperfections. In its short lifetime, the Microsoft Corporation has been both lauded and harangued for its leadership, greed, innovation, distrust, philanthropy, bullying, reinvention, plagiarism, competitiveness. Being part of this machinery, we have an intimate understanding of our company’s wonderful—and not so wonderful—attributes.
Enter the Mix 2.0 Redesign.
Like the MIX conference, MIX Online’s goal is to create a better conversation between Microsoft and the world, and to provide a forum where thought-leaders from within and without the corporation can have an honest dialogue. We want to be an open-minded, collaborative petri dish of ideas that make the Web more powerful.
In other words, the MIX brand is built on making a difference. On getting a big corporation to do not-so-corporate things. With the MIX Online redesign, our overarching goal was to allow this vision to permeate all our efforts—from creative direction to information architecture to design to copy. In hindsight, the idea feels as natural as pinching a screen to zoom in on a picture.
What follows is a detailed summary of our latest redesign. It’s 30 pages of the good, the bad, and the ugly.
Grab a seat.
Hire the Best, Get out of the Way
In Web Design from the Gut, I wrote about how our first design was a guerilla effort. Being a new team, we didn’t have much budget or time. Fortunately this time was different, and I had the freedom to assemble a team of experts.
I once heard the quote, "If you hire people who are smarter than you are, you prove you are smarter than they are." The quote is cheeky, but helpful. I’ve made it a habit to test my intellect whenever it comes to hiring. I try to hire only the best.
In our industry, we have a habit of hiring great design agencies, and then micro-managing them. It always leaves me scratching my head. Why hire professionals with specific expertise and then tell them how to do their jobs?
You there, Mr. Astronaut. I think you should lose the helmet. It looks silly and the press will mock us.
What I confirmed during this project is simple: let the subject matter experts do their jobs. If their decisions and advice make you uneasy, it’s not just because they’re no good; it’s probably because you don’t understand their methods. That’s why they’re subject-matter experts in the first place.
It’s easy for us to relinquish control to professionals like doctors and lawyers. It’s a little more difficult to do it with folks who do this mushy UX thing. It often takes an active leap of faith, but trust me: it’s well worth it in the end.
The most common, politically correct web design process diagram goes somewhat like this:
But the process our little team used—and to be perfectly honest, it’s the process that more closely resembles the real-world web design process—went somewhat like this:
All told, it looks something like our web design and development visualization: A Website Named Desire.
I’m going to explain the process a bit more linearly, so our brains won’t melt.
Discover like Columbus
Every software design phase is marked with some sort of a discovery phase. In layman’s terms, discovery is about figuring out the goals of said software: functional, aesthetic, performance, and otherwise.
There are thousands of ways of "discovering". I favor processes with minimal overhead, controlled collaboration, and quick decision-making through empowerment and delegation.
If I had to break it down, there would be three steps:
- Find the soul of the business
- Figure out what to build
- Ramp up the production team
1. Find the Soul of your Business
OK, I’m about to get a little touchy-feely again. Don’t get misty on me.
A business is like a person: it has a personality, dreams and fears. Maybe even a soul. When figuring out pragmatic requirements, though, we often overlook a critical step: searching for the soul of the business.
The elusive and frustrating thing about soul-searching is that you can’t do it overnight. In my case, I was lucky to be at the table when we founded MIX Online. I was able to help bring its soul into being and nurture and evolve it. And since a few of my coworkers were instrumental in incarnating the Mix brand, I didn’t have to search far to find insight into the soul of the business.
But what if you weren’t there when your business was born? What if you didn’t see how it got here?
Well, someone was. Go find that person. Then spend some time getting into his head. He’s most likely that guy everyone calls "bitter" and "jaded". "Not to badmouth Mr. X—because really, I do think he’s very smart and talented—but I would be careful about listening to his opinion. He’s a little bitter and biased." Jackpot! You’ve found your man. He’ll help you find the soul of the business. It’s up to you how you choose to embrace his thinking as you design or redesign, but it’s knowledge that you must possess before you can move forward. Call it research.
2. Figure Out What to Build
This is the easy part, because it’s already on everyone’s minds. Now you just need to get it on paper.
I sent the team a quick email asking for a bulleted list of items—what new features/requests do you have in mind for the MIX Online redesign? I also reached out to a few folks outside the team.
It’s often more useful to collect this kind of data in a passive and personal medium such as email. The alternative of scheduling a meeting is inefficient; things fall through the cracks and meetings frequently lead to discussions that are unnecessary at such an early phase.
I received a high-level list of features from several members on the team. I took all the items and added them to our Basecamp project as a To-do list titled "Stuff We Want" Bucket.
I followed that up with a 1-hour meeting to go through each new item. Should we have a "share" button or a retweet button? Should we enable blogs per lab or have a single blog for all labs? Should all types of posts or just promotional banners for labs be "featured" on the home page? These are the types of questions we discussed.
Before we knew it, the list was on paper and the context was in my head.
I conducted another simple exercise on our Basecamp site to get an idea of what sites the team liked. Each teammate provided me with 3-5 web sites that they felt "set the bar" and a brief write-up about each. This was a really good and useful way to get the team involved.
Here’s an example of one of the sites Joshua picked:
Joe Clark’s blog—Still a favorite for me. His design reflects the sensibilities of someone steeped in web philosophy. The content is front and center, no annoying chrome or boxiness; it is all about document flow. You are invited to just engage with his stream of consciousness, instead of being assaulted with a bunch of "features" competing for your attention and pinching you in the arm as you walk by. Nice typography, and everything has an "outline" feel with appropriate emphasis at header levels. Has personality combined with intelligence (YOU ENJOY FAWNY.BLOG). I even like the hover effects, nostalgic in a non-kitschy way.
We kept discovery exercises simple and quick, and made them about filling the blanks. Focusing on the bigger questions—like, "Do we want to support IE6?" (it turns out that we didn’t)—helped immensely. The key? Learn as much up front as you can, so you can be free to start production.
3. Ramp up the Production Team
If you want a design to exceed expectations and truly make a difference, the entire production team must internalize its goals and requirements. Ideally, you want the team functioning as an individual. Of course, you don’t get to that sort of unity overnight. But you can definitely get there through constant, transparent communication.
The first step is to set the right expectations. Matt, Tiff and I got on the phone a couple of times when we kicked off the project, and I spent some time dumping my brain on them: we talked about how MIX Online come about, what the reasons behind our prior design choices were, what types of problems we faced, what are our content goals were, and so on.
I also focused on getting them to feel the way I felt about the project’s goals. For example, during one of our conversations I said to Matt (of course, I’m paraphrasing here because I’m not insane enough to record my own quotes), "Take this project personally. Approach it as you’d approach something you’re designing for yourself, like your own portfolio site. Don’t worry about formal deliverables that you give other clients. Just focus on what you think is absolutely necessary for you to be successful." These types of brutally honest conversations helped morph a set of individuals into one a person. They got us to Gestalt, so to speak.
Matt and Tiff supplemented these phone calls with a few discovery exercises of their own, to get specific about where we wanted to take the visual design and content tone.
I’d describe my relationship with Matt, Tiff, and Evan as controlled collaboration. For example: I set up a separate Basecamp project just for the four of us to encourage complete transparency. It may come as a surprise to you that nobody from the MIX Online team (not even my manager) was privy to the discussions on that site; it was strictly for the design production team. In fact, the MIX Online team has yet to see it.
The point is to avoid randomizing your team of producers. Dedicating an exclusive communication channel such as an independent Basecamp project ensures that the Creative Director serves as the conduit between the production team and the stakeholders, deliberately controlling collaboration among participants. While this put more responsibility on me, the end result was exponentially better.
Inform Your Users, Architect Your Business
I wanted to begin this section with the customary, "What is the definition of IA?" spiel. But, when I searched the Web hoping to find a definition, I got this. Yes, it left me scratching my head, too.
So, what is IA?
Colloquially speaking, IA is the process of laying out all the information that will be presented on a site or application in a way that makes navigating and interacting with the site easy. IA generally culminates in a set of wireframes that encapsulates the web site’s layout and functionality. Here’s an example from the IA deck I created for MIX Online:
Although this definition is apt, I have a problem with our colloquial understanding of IA, because it promotes a very trivial view of the concept.
When it comes to the Web, the a site’s information architecture is very closely related the company in question’s business model. In fact, the IA of a site is generally its business model framework. The IA of Twitter—the layout and prioritization of content on any given page—is the business of Twitter. Similarly, the IA of Facebook is the business of Facebook. The crazy uproar in which a million users signed up for a protest group when Facebook "redesigned" its site happened because Facebook attempted to change its IA. (And in almost every case, you can see that Facebook was really trying to reposition itself.)
Part II in this series of articles—The Future of Wireframes—covers the topic of wireframes and IA.
Who Sezs People Donuts Reads Anymore?
This section is about content strategy. As a comprehensive introduction to the topic, I offer you Kristina Halvorson’s epic article on A List Apart, The Discipline of Content Strategy. Then take a gander at this wonderful collection of articles.
In plain English, content strategy means, "Come up with a darn plan to publish content that’s relevant to your audience. While you’re at it, be sure it’s tonally uniform, searchable and syndicated in a smart way. Content is king. Treat it like royalty. If you write, they will come."
While this is not applicable to every business, it is certainly very applicable to MIX Online. I asked Tiffani to come on board for the MIX Online redesign to help us elevate content as the centerpiece of our site and to design content (copy) that would help us communicate our goals and spirit to users.
Content as Centerpiece
MIX Online publishes a lot of content. Writing is a big part of our business model. We publish articles (longer shelf-life content written by experts) and opinions (more current commentary written by us) about relevant topics ranging from web design to web culture. We also write lab notes, which are more technical posts about labs we’ve created.
It’s safe to say that we started with a pretty well thought-out content strategy. During the redesign, Tiffani helped validate and refine it by collaborating with Matt and I during the IA and visual design phases.
On a much more tactical level, we also paid a great deal of attention to the visual display of content; I alerted Matt about our historical readability issues and how important it was to fix these in the redesign. An informal web typography study I conducted earlier in the year was a good starting point for this endeavor.
Content as Visual Element
While the world may not be ready for blogazines (I dare you to read the highly charged comment section of this phenomenal post by Smashing Magazine. Your eyes will pop out.), the time is ripe for a more magazine-y feel for web design. Aside from adding visual interest, purposeful web copy integrated into the visual design tricks users into reading what they’d generally ignore. A great example is Mike Kus’ Carsonified redesign. Click through the pages and marvel at the masterful harmony between copy and visual.
A Picture Speaks a Thousand Words
And finally, it’s time to talk about painting pretty pixels.
The visual design phase is where vision, goals, content strategy, and information architecture all come together to form a set of near pixel-perfect comps (high fidelity mockups of what the pages will look like once produced). As Steven Seagal once said, "It doesn’t work if the bad guys kill his mother’s uncle’s friend’s neighbor’s pet dog. You’ve got to make the stakes high." Amen, Officer Seagal. The stakes for this phase are stratospherically high.
As much as UX professionals detest being labeled pixel stylists, the dirty truth is that presentation often trumps everything. You could iterate on refining interaction models or incessantly revise web copy, but pick the wrong shade of blue and you’ll derail months of careful experience design.
Generally speaking, the visual design phase reveals our humanness—our biases and prejudices, quiet agendas, irrational actions, and diverse portfolio of imperfections—in full effect.
Speaking of which…
As someone who usually finds himself on the other side of predictably irrational behavior and who has managed many emotionally charged situations, I was caught off-guard when I found myself perpetrating irrational behavior during the visual design phase.
Since I’m already skinny-dipping my way through the design process, I may as well share the story for the good of humanity.
Designers, Behavioral Economics, & Frankenstein: A Short Play written in style of the hit TV series, "24"
I’ve managed many visual design phases in my career, but this was the first time I’d been the primary stakeholder.
Matt said all the right things when we first talked about art direction. His art boards were spot-on and I felt completely in sync with him. As he started visual prototyping, I nudged him to start with the Writings template—the page that hosts article, opinion and lab note content (i.e. the template for this page). This deviated from his usual process, which started with the home page, but he liked my idea of using content-heavy templates to set the tone of the design. Content Precedes Design, I sermonized.
As we communicated on Basecamp, I started getting the sense that Matt had a bit of "designer’s block" going on; he would write saying he was almost ready to show me the concepts, but then back off at the end of the day saying he needed some more time. This, by the way, is perfectly acceptable and natural from a creative process perspective. Separately, he was taking this design personally, so I expected that to have a higher cost in the form of unpredictable timing.
In hindsight, I have to admit that I was a little concerned because the delivery of the first finalized comp was a dependency for the MIX 10 event site that Blue Flavor was developing. Their Creative Director, Kevin Tamura, was waiting to see our direction so he could align the MIX10 site’s direction with ours. The creative direction of another very high traffic web site was going to be based on ours—so when we locked on ours, we had better be sure of it.
Matt finally posted the best direction from all his prototypes.
And, my response on Basecamp:
In a gist, I felt it was a credible effort, but didn’t hit the bar we’d set. I didn’t show it, but I was really worried. Matt shared the comps for his other directions with me (the ones that didn’t make the cut compared to the above one), but this just added to my nervousness. My lizard brain kicked into defensive mode.
Had I communicated the vision poorly? Had Matt misunderstood the vision? How did I misjudge our being in sync? Maybe Matt wasn’t as good as I previously thought? The last fear was particularly worrisome and difficult to accept; it jeopardized the project and left me questioning my own judgment.
We had some follow-up discussions and agreed to reboot. Matt went back to the drawing board.
If this were a TV drama, this is where the scene would pause on a close-up of my face looking conflicted, my eye twitching ever so slightly and my expression cocked into a thoughtful frown. And then the narrator (a calmer version of myself with a much deeper voice) would step in to analyze the situation. The voice would gravely say:
Nishant doesn’t know it yet, but he is slipping into the grip of predictably irrational behavior. Ironically, it fits patterns published by his very own hero, Dan Ariely. Among the various irrational biases weighing on Nishant is a powerful one related to supply and demand. Behavioral economists call it "arbitrary coherence". Simply put, it illustrates how the initial price for a product is largely determined "arbitrarily", but once that price is set, it shapes what we are willing to pay for both for that product and related products (coherence). In more general terms and put into context, first impressions are scientifically proven to resonate over a long sequence of decisions—resulting in us over-estimating or under-estimating the value of products or services. Even designs.
The paused scene would then begin playing and show me walking up to my machine. I sit down, launch Photoshop, select File > Open > /templates/base_grid.psd, and resave it to the desktop as mix_online_reboot.psd.
Oh no he di’nt!!
Yes, I was now so anxious that I decided I had to take matters of visual design into my own hands.
A day later, Matt posted a Basecamp message titled "Design ReBoot!" He was excited and optimistic about the rebooted direction, and of course, there was also a comp attached.
And the comp:
Notice how similar it is to the design we launched? Instead of jumping for joy and seeing a diamond just waiting to be cut, I sent the following response to Matt on Basecamp:
Translation: Pretty nice design, but I don’t really think we’re in sync. I don’t think you’re going to hit the bar. It’s not your fault and I’m not at all mad. Admittedly, I have some preconceived notions about where I think the visuals need to be going. I think it’s time I take over (which I did this morning, btw).
Going back to our little lesson on "anchoring", my first impression of Matt’s work for this particular project had effectively made it so that I couldn’t see any of his subsequent work as "brilliant" anymore.
And thus, I had set into motion a crazy chain of events.
The next day I posted a message on Basecamp auspiciously titled, "MIX Online: A Fresh Direction". Here it is:
I had gone ahead and comped out a design in a day’s time (in hindsight, it’s painfully obvious that this was a first attempt thrown together in a few hours). Here’s the comp (we later branded it the "alphabet" comp):
I’ll fast forward now. The chain of events that followed:
- Matt accepted the new direction. He asked to take a crack at refining it.
- He came back with some concepts that merged his latest comp (we called it the "circles" comp) with mine.
- I provided feedback to change a few things. He took another pass. Rinse. Repeat. Still didn’t make the cut.
- Oops. Time ran out.
- I finally decided to invoke a "come to jesus" moment—we were taking the Frankenstein approach of mixing and matching directions and elements that didn’t work, I said. The approach was destined for failure. Matt and Tiff agreed.
- Tiff, Matt and I got on the phone to discuss; he was still gently pushing his circles comp and at this point, I couldn’t understand why. After all, he’d admitted that it wasn’t up to the mark. I knew him better than to push something like this just for personal gain.
- We hit stalemate on the call with neither one of us being able to objectively articulate our sides. I said I needed some outside counsel; I was going to talk to Joshua.
- Joshua pointed out that both directions were good and there was no way to tell which one is "right" for the community. We discussed some more and finally agreed that we needed a third party—an unbiased individual who’d seen neither design—to weigh in. We walked to Thomas’ office, but he wasn’t there.
- I called Matt and said that it was a coin toss at this point; we were going to get Tommy to pick and were waiting for him to return. As the call continued…
My favorite work from you to date.—Jesse wrote Matt
… Matt said something that completely caught me off guard. He said that he really believed that the circles comp was the absolute right direction for us. It was the first time he’d said it with heartfelt conviction. He also added that he’d sent the circles comp to a friend and well-known rockstar designer whose work I admire, Jesse Bennett-Chamberlain. He said that it was Matt’s best work yet in his career. I told Matt that I really appreciated the honesty and that I’d get back to him in a few minutes. We hung up.
Everything went into slow motion for me after that call. I walked back into Joshua’s office and relayed what I’d just heard from Matt. We launched back into a discussion. At one point Joshua said something like, "Didn’t you say that one of the reasons you thought Matt was the ideal choice for this job was because he represents a large segment of our audience? If he feels so strongly and is putting his neck on the line here (and the concept has been endorsed by a very credible designer who we believe is in our target audience), then maybe we should take the plunge."
By this point in the conversation, I was already sobering from the influence of irrational behavior. But Joshua’s point really drove it home for me; it’s what finally snapped me out of the weird state.
Matt and I exchanged a couple more messages:
By now, Tommy was back. We decided that we should get his take just to be safe. That unto itself was a comical situation because we rushed him into my office, showed him the concepts for the first time, made him pick (he picked "circles"), and then sent him off all in a matter of five minutes or so.
I sent this final message:
And, so they lived happily ever after:
In a gist, the situation went something like this: Matt’s initial comps failed to inspire, despite his selling them as a good direction for MIX Online. He conceded to my opinion, which we both look back at as being right. This inadvertently lead me to set a low anchor for his subsequent visual concepts. When a much stronger comp ("circles") presented itself, I was unable to see it for what it was—a gem—because I viewed it relative to his initial comps. To make matters worse, he didn’t fully sell it to me, so I was convinced that my review of it was accurate. And believe me: I thought I was being completely objective through all of this.
It took external intermediation (which, to my credit, I proactively sought out from Joshua and Thomas) and a verbal slap in the face (Matt finally "getting real" on a phone call, peer merit badges and all) for me to snap out of it.
So, let’s put this into perspective. I’m a fairly self-aware designer and behavioral economics enthusiast. I have years of experience designing and building for the Web, and like to think I’m pretty good judge of web design. I also have a respectable amount of working knowledge on the topic of irrational behavior. Heck, I’ve written about it on a number of occasions in our Opinions column! Yet, I got caught up in this situation!
Is it any wonder that non-designer, otherwise perfectly rational stakeholders exhibit all sorts of odd behaviors on design projects?
There are so many lessons you can take away from this situation. Lessons like, design is often a tedious and excruciatingly human process that tests interpersonal communication skills. Or, you don’t just land on a great design solution; you iterate towards it. The list goes on.
But, if there’s one thing I’d like you to walk away with, it’s this: we’re all prone to irrational behavior. The sooner you realize this—not just as a designer, but as a human being—the better. Admitting this will help you shepherd situations and make better decisions. You’ll start seeing situations through a clearer lens, with almost superhuman x-ray vision at times. While superpowers have their downsides (for instance, you may have to wear spandex and a muscle tee), you can’t deny that they come in handy.
Upwards and Onwards
Once we locked on the "circles" concept, it was pretty much smooth sailing. I took on two roles: providing Matt with my first impressions and nit opinions about each page, and putting myself on point to ensure that the desired functionality and interactions didn’t fall through the cracks.
Since we used functional wireframes (wireframes that suggested, but didn’t dictate, layout and positioning of functionality), Matt had a lot of flexibility as he comped. My only requirement was that he included the functionality I presented on every wireframe. Placement and size of the information blocks were up to him.
In a sense, I gave Matt an illustrated list of the functionality I believed to be important for each page. Matt took the wireframes and Tiffani’s wonderful copy and assimilated it so that it made sense visually and experientially. In many cases (such as the Labs page), Matt deviated pretty drastically from the suggested layout based on his experience and intuition.
This is the beauty of functional wireframes: they sensibly blur the boundaries between IA and visuals. I’ve found that this process tends to produce more cohesive designs—both functionally and aesthetically. I see this becoming more of a trend as we forge ahead on the Web.
From Comp to Code
If you’ve kept up with our design evolution, you already know that one of our concerns was front-end markup quality. Markup quality is not just a purist concern, even though there’s some dogma around validation, semantic markup and so on. If you’ve ever managed a living, breathing high-traffic web site, you know all too well that things like redundant CSS, over-classing, divitis, non-semantic naming conventions, poor organization of code, ambiguous inheritance chains, etc. can quickly stagnate your business. There is a very high compounding cost to fixing HTML and CSS issues when you start with a bad foundation.
Take a simple example, in which you’d like to increase the size and line-height of the type on a particular page (we wanted to do just this for article pages because of readability concerns). With a well-executed code base, you’d probably just write a simple declaration for the container DOM element or modify an existing one—you’d go to a line of code and update it. Twenty minutes tops to check-out, update, test, check-in and publish the new code.
With a bloated and redundant front-end code base, however, you’d be faced with a trickier exercise that would probably involve ripping out and writing markup, updating multiple rules, writing new rules, more testing and then some. It could take anywhere from an hour, up to a few hours (high cost). In such cases you always end up with suboptimal solutions that introduce more volatility into the code base (compounding cost).
Eventually, you reach a state where you’re afraid to update the site, because it’s like a house of cards that could collapse any time. Or, you have to allocate a tremendous amount of resources to solve simple problems. For a small grassroots team like ours, this is not feasible. When you’re dealing with a bloated front-end code base, I would definitely recommend a "rip and replace" strategy as an early option.
It takes a special kind of front-end web developer to give you a scalable, maintainable markup foundation. HTML/CSS development is as much about technical chops as it is about determination, ability and the deep experience that comes with dealing with the ambiguity and contradictions of browser inconsistencies over years. I was very fortunate that Evan (who was brought on by Matt) turned out to be the textbook example of a front-end web developer.
I had to do very little to help Evan succeed at delivering what we needed. I wrote what you might call a "Markup Standards" plan: a requirements document for the front-end code. Here it is:
This seeded a quick and healthy discussion about the type of code we wanted and enabled Evan to hit the ground running.
Approximately 10 days later, he delivered a code base so good that I literally wanted to lick it. He continued to iterate on it for a few days, until all the cross-browser kinks had been worked out.
This concludes the narrative portion of this article. In other words, I’ve told you most of what I deemed important enough to share about our design process (and then some). There’s just one last thing I’d like to relay.
The Madcap Log
When we started this project, I had the crazy idea of keeping a log of every moment I spent on it (including just "thinking" about it, which I tagged as "Reflection"). I created a spreadsheet on my phone and started logging everything. And I mean everything. Here are a few entries:
- Aug 30, 10-11 AM—Thinking about layout in bed
- Sep 3, 5:30-6:00 PM—Experimenting with color wheel and Kuler
- Oct 4, 9:00-9:30 PM—Sketching Lab wireframe in bed
Much to my amazement, I kept this up until the moment we locked on the circles comp (including the little irrational episode).
You can download the full log here if you’re interested. In the meantime, let’s quickly analyze some of the data.
Here’s a bar chart of the hours I spent per week on the project.
As you can see, I tracked my activities for a total of 9 weeks (45 workdays). The average time spent per day (based on a 5-day work week) was about 3.5 hours. This makes sense because the MIX Online 2.0 redesign project was approximately half my workload during those months, and I didn’t really slip any of my other responsibilities.
Another interesting pivot is the hours I spent on each type of task (category).
Now, keep in mind that this is the time invested just by me, the Creative Director, before the production-heavy phases like visual design and markup began. Also recall that I stopped logging my time right after we signed off on the circles comp.
Nonetheless, one interesting insight is how much time I spent just on "process", i.e. overhead. Some examples of items tagged "process":
- Official project kickoff on Basecamp
- Draft of MIX10 Conference Execution All-up plan
- Sign-off on plan with management
- Created draft schedule in Basecamp
- Worked on schedule + discovery
Despite our lightweight process and minimal bureaucracy, the ongoing process tasks accumulated to a time value larger than any other category. Another way to look at it is that I spent 33% of every work hour on process!
What does this imply?
The idea that you can free up your time completely by outsourcing a job is a misconception, at least when it comes to software. My experiences have shown that the 33% number is fairly accurate, if not optimistic. In fact, the number is usually closer to 50%. It’s easy to see how hiring outside help could double your responsibilities.
The final visualization I’d like to share shows all the tasks plotted over a timeline. Note that every point on this chart denotes the start of one of seven types of activities.
Notice any interesting trends? Maybe if we add some area layers per category we’ll see it.
Aside from looking like an abstract painting of the Fail Whale, this version of the visualization shows how non-linear the design process can really be (and was, in our case).
Notice how the various phases organically blend into each other. Look at how IA and Visual Design overlap, for instance. Or how Discovery never really ends. Also, notice how the violet Process layer is present throughout the lifecycle of the project.
Another interesting insight is related to timing of tasks. Take this cross-section of tasks that occurred between 6 pm and midnight:
If you look closely, you’ll see that several creative and analytical tasks (IA and visual design) bled into the nighttime. Ever heard the stereotype that inspiration strikes after-hours? Maybe there’s some truth to that.
It’s interesting that much of the research occurred after hours, too. This may seem a little odd, but it makes perfect sense. Who has time to read and browse the Internet at work, after all?!? When it comes to design, research is usually about drawing inspiration, catching up on cultural trends and immersing yourself in freeform thinking. Such activities are usually best performed at home without the flood of emails, meetings and drive-by interruptions we encounter at work.
Was it Worth It?
At the time of this writing, the MIX Online redesign has been "live" for 60 days. It’s too early to tell whether the redesign was a runaway success for our business. But, there are some very positive signs indicating that we met and exceeded many of our goals.
For one, the readership of our content has gone up almost threefold, as has the average discussion frequency per writing. Check.
And since the redesign, we’ve checked in more CSS updates than we’d checked into our source control in all of 2009. Finger-lickin’, maintainable code FTW. The process of marking up writings has become much quicker, too. Check.
Our traffic (you didn’t think I’d end this article without saying the word "traffic" at least once, did you?) has gradually trended upwards in the past year; the slope has gotten sharper since December. Check.
The buzz online has been great, from enthusiastic tweets applauding our new face to being featured on all the major CSS showcases. The icing was Drawar, one of our favorite web design showcases, crowning us as the best site of 2009 from a pool of 1100 stellar contenders. Check.
Finally, do we now feel like we have a very solid foundation to build upon? Gauging from our hallway conversations, I’d have to say… Check.
In theory there is no difference between theory and practice. But, in practice, there is.
So there you have it—our design process laid bare, victories and imperfections alike.
I’ve found that the design process in the real world barely maps to neat little process flow diagrams and elitist definitions taught in school and used to kick off presentations in our workplaces; Marcus Fairs wrote an insightful piece about this a few years ago. This is not to say that design has nothing to gain from a solid structure and process. In fact, they have much to gain, as this case study demonstrates.
But we—designers and stakeholders—must be careful to not bring along with us the idealism, elitism, presumptions and dogma that characterizes much of the design that’s practiced in organizations today. Dustin Curtis’ American Airlines episode and Doug Bowman’s legendary goodbye letter to Google are just two examples of how such process dysfunctions are entrenched in our software design culture.
We must also develop and stay true to our overarching vision. In MIX Online’s case, keeping focused on making a difference gave us confidence to experiment with a new team and organic process, and helped lead us through snags in the project.
The bottom line? Smarter hires, more resources, more time, fewer managers, rational stakeholders, less overhead, stronger leadership, and sensible project management are intrinsic to creating great designs—but they cannot take the place of a strong mission and sense of purpose.