App Store is a competitive environment. Against more than 140,000 apps, all screaming for attention, how do you make sure your app gets its time in the spotlight? What does it take to get good media coverage? How do you get people to talk about your app—and, ideally, how do you get them to buy it and show it to their friends?

Following the simple rules laid out below, you will increase your chances in the battle for fame and glory. These tips might seem rudimentary or in-your-face obvious, but they are so often neglected in the heat of the moment.

This article is part II in a series covering the topic of Web Design. If you haven't already, check out Part I—The Anatomy of Web Design. Tiffani Jones, Matt Brown and Evan Sharp will contribute the remaining articles. Follow us on Twitter or subscribe to our RSS feed to be notified of their publication.

Riddle me this: How do you piss of a UX professional? The answer: Call him a "designer".

These days, user experience professionals look down on the word "designer" because it implies that their primary role is to paint pretty pixels. UX is more than that, they clarify. Much more!

Just how much? Well, here's a diagram (that uses pretty pixels) to explain how much more—

Holy guacamole, Batman! Elliptical hotness!

But wait! Does this diagram mean there is only one successful UX professional in the world? Steve "DamnItNotHimAgain" Jobs? Because no so-called "designer" can possibly wear all these hats.

It's time we end this madness! While we're squabbling over why one type of designer is different or better than another (and falling prey to one of the oldest colonization tactics in the book: divide and conquer), our industry continues to build crappy software. And without us.

Convergence in the Simulacrum

IA, content strategy and visual design are quickly converging on the Web. As design becomes democratized and users demand more than the "craigslist experience", business owners are discovering that the way to keep users on a site is to differentiate themselves through intelligent content and innovative design that exist within the natural patterns available to the respective mediums (browsers, phones).

In 1999, Jakob Nielsen wrote an article that was undeniably ahead of its time: Differences between Print Design & Web Design. He argued that anything that is a great print design is likely to be a lousy web design due to the inherent differences between the two mediums. Most notably:

• Print design is 2-dimensional while web design is 1-dimensional and n-dimensional simultaneously. The web experience is fundamentally a "scrolling experience" dominated by movement between pages through hyperlinks.
• Print is about seeing, web is about doing. The "look and feel" of a web site is dominated by "feel", i.e. the user experience. This is because doing always makes a stronger emotional impact than seeing.
• Print is immensely superior to the Web in terms of speed, type, image quality and canvas size. The Web has problems associated with low bandwidth, low screen resolution and limited screen sizes that affect the user experience significantly.

Fast-forward to 2010 and it's pretty easy to see how these differences have diminished drastically—or even disappeared. Users have become savvier and technology has improved. The leading edge of web design capitalizes on how minor these differences are today. Print-y web sites like Jason Santa Maria's personal blog or Carsonified's business site are just two examples of this. You can find hundreds more on web design showcases like Drawar.

I daresay to God that the Web is finally converging with Print. So, where does this leave our trusty wireframes?

The Problem with Wireframes Today

You can find hundreds of definitions of the word ‘wireframe' on the Web. Here's one that represents what's typically practiced today [courtesy webopedia]:

A wireframe is a visualization tool for presenting proposed functions, structure and content of a Web page or Web site.

Unfortunately, the most common interpretation of this definition practiced in workplaces leaves much to be desired:

A wireframe is a line drawing that dictates exactly what functionality and content is located where on a Web page or Web site.

This interpretation drastically limits the potential of a web design. It sets a glass ceiling for the visuals and copywriting, two supremely important aspects of great web design. It promotes the notion that visual designers and copywriters needn't bother themselves with size, location and functionality of the elements of a design and that their individual products—the UI and the copy—don't play much of a role in shaping the flow and interaction on a web site.

This may have been true in 1999, when we were all getting used to the new UX metaphors of the Internet. But it certainly isn't the case today, in a time where mediums and disciplines are converging and metaphors like the "back button" or "scrolling" have become muscle memory.

Bottom line? We need to update our interpretation of the word "wireframe".

Rethinking Wireframes

A little less than a year ago, Isaac Pinnock of Made by Many wrote an article titled, The Future of Wireframes? Our articles share titles and arrive at very similar conclusions, but they use some very contradictory terminology along the way.

Isaac wrote about terrible "functional wireframes" from the 90's being replaced with wonderful "visual wireframes" of today, for example:

10 years ago the first wireframes I used were about as functional as you can get – a long list of page elements: static text, dynamic text, input text, radio button and so on. They were universally awful. About the only concession to help people understand how the page worked was to group common functionality into individual tables.

The wireframes were functional rather than visual as they were used to describe how the page should be built. Certainly, when you consider the screen from a developer's perspective a list of different functional elements is probably quite logical.

However, from a user experience point of view this was a killer. Functional wireframes are incredibly difficult to read – the method of presentation gets in the way of being able to translate the information into a real screen, especially at the review stage.

This is going to seem very confusing, but unlike Isaac, I use the term "functional wireframe" in a very positive light and take for granted that wireframes are "visual". By attaching the label "functional" in front of "wireframe", I am asserting what is and isn't in scope for that particular wireframe. The first page of my wireframe deck explains this clearly:

Functional wireframes—call them whatever you want—strike a balance between functional specifications and traditional wireframes. They have some very powerful benefits, especially when the members of a design team have cross-disciplinary skills (this is usually the case today). Most notably:

1. They democratize layout decisions, allowing the natural synthesis of a more unified final design.
2. They encourage collaboration and allow designers (visual, IA, content, interaction, etc.) to arrive at a holistic vision.
3. They help manage client and stakeholder expectations by focusing the discussion on page-level functionality during reviews.

Of course, for functional wireframes to work, there is a higher tax on softer skills like communication, feedback loops, and trust. Functional wireframes are not for organizations that haven't grasped basic principles that allow us to predictably design great solutions that meet business needs.

But, as the MIX Online redesign case study demonstrates, functional wireframes can truly promote the behaviors necessary to create more cohesive designs.

The MIX Online Case Study

We created MIX Online's functional wireframes over the span of exactly one week (the IA phase). As promised on the introductory page of the wireframe deck, I attached a color code at the top of each wireframe to indicate my confidence in its layout. Here's an example of a profile page wireframe:

The process I used was pretty simple: I created a couple of wireframes a day, updated the deck and then posted it on both Basecamp projects. You may remember from Part I of this series—The Anatomy of Web Design—that the MIX Online stakeholders were restricted to one dedicated Basecamp project, while the design team was restricted to another. I served as the conduit.

On the stakeholder side, the MIX Online team was focused on finding gaps in my thinking and ensuring that I wasn't missing any needed functionality. On the design team side, Tiff, Matt and I were engaged in intensely iterative conversations—digging into the content strategy, formulating a strategy and tone for copy, brainstorming around visual design, developing a category/sub-category taxonomy, and so on.

What we didn't spend any time discussing was layout—in other words, the location of all the different boxes of information. Functional wireframes postpone layout discussions and ultimately rely on the Visual Designer to finalize layout of the various elements on the page. This is not to say that I didn't suggest page-level layout in my wireframes. In fact, I did—and in many cases, strongly so.

For the most part, though, I didn't get caught up in layout details. My primary interests were to ensure that I had created a sensible sitemap and captured all the right functionality to support our business. I was also focused on ensuring that I'd partitioned the functionality between pages to encourage the right behaviors among users.

You can download the final set of wireframes by clicking on the image below. I encourage you to compare the wireframes to the actual site. Notice that in many cases, even the layouts marked "green" didn't quite work out. For instance, the Labs page is one where Matt decided to go with a simplified layout similar to our prior lab page.

As a whole, this approach departs from traditional IA methods—which include providing an actual blueprint for the site, layout and all. But it's precisely this departure that is necessary to take designs to the next level.

In parts III & IV of this series—Tiffani's article on Content Strategy and Matt's on Visual Design—you'll see more examples and evidence relating to effectiveness of the organic functional wireframe approach. Follow us on Twitter or subscribe to our RSS feed if you wish to be notified of their publication.

Back to the Future

Daniel Pink argues in his book—A Whole New Mind: Why Right-Brainers Will Rule the Future—that software design is fairly unchartered territory, but will mature in this century.

Web design is one of the sub-genres of software design that's just started a slow crawl, characterized by constant retracing of steps, out of its infancy. Less than a decade ago, the introduction of WYSIWYG editors promised to deliver the holy grail of web design. Today, good ol' text editors like TextMate—the ancestors of WYSIWYG editors—are taking their place yet again.

The point is that the discipline of user experience could and probably will look completely different a few decades from now. IA as we understand it could cease to exist, and it could very well merge with visual design. The possibilities are endless.

Which is why we need to entertain the idea that we're doing it all wrong at the moment and embrace the notion of cross-disciplinary approaches whenever we get the opportunity. Functional wireframes are but one attempt at that.

Isaac Pinnock said it best in the conclusion of his article:

The best sites are those where there's a seamless divide between the look, the content and the experience. Being able to model an interaction and understand how someone moves through a site are crucial skills in this trilogy. It's time designers stepped up to the plate and claimed wireframes as their own.

  

Web design is a relatively young field. It's youthful, growing and made up of people from all kinds of backgrounds, many of whom lack formal design training. We have learned, and still are learning, as we go. I came into my first job as a Web designer for Boeing back in the mid-1990s, with no formal design training. I was lucky to get some training on the job, and I would guess that my experience there was similar to that of many who are reading this article.

I had the opportunity to work with some very talented and highly experienced designers who all had made the jump from other design fields to the Web. It was there, as part of that training, that I learned about critiquing, both giving and receiving, through regular design reviews.

The Problem with Charting Control Styling

Recently, my team needed some basic charting controls for a project we were working on, so I investigated the Silverlight Toolkit charting controls available on CodePlex. We quickly discovered that the Charting control styling was cumbersome in Expression Blend. I ran into the following issues:

• The Toolkit runtime DLLs don’t support editing styling templates
• The Themes approach that the Silverlight Toolkit employs doesn’t have design time support

If you’re looking to use the Silverlight Toolkit Charting controls, here are a few options for working around these issues.

Getting Ramped Up

I was pointed to a good blog from December 2008 that describes how to style the charting controls. The blog is written well, but dated—I’ll clarify any inaccuracies below.

I installed the Silverlight 3 Toolkit with the installer located on the home page of the CodePlex site. I then fired up Blend 3, created a new Silverlight Web project and added references to the Silverlight toolkit binaries: System.Windows.Controls.Datavisualization.Toolkit.dll and System.Windows.Controls.Toolkit.dll. Then I opened up the Assets panel by clicking the chevron on the left hand menu and chose the Chart control by clicking on it, as shown here:

Once I clicked the Chart control, I then created the control on the designer surface by dragging an area on it. It created a "Column" Bar Chart that showed pre-populated data.

I wanted to create a Pie chart, so I deleted the ColumnSeries node in the “Objects and Timeline” view by selecting it and pressing delete. This left me with an empty chart. I added a PieSeries by dragging one from the Assets panel into the chart control on the design surface; nothing changed visually since the bindings to the data source have not been defined as they were in the default ColumnSeries. I switched to the XAML view in the design window and added bindings to the data source. In order for the PieSeries element to bind to the PointCollection that was created when we created the chart control, I needed to add the following attributes: IndependentValuePath="X" DependentValuePath="Y" ItemsSource="{Binding}"

This is how the XAML fragment for the chart control appears:

<charting:Chart Title="Chart Title"> <charting:Chart.DataContext> <PointCollection> <Point>1,10</Point> <Point>2,20</Point> <Point>3,30</Point> <Point>4,40</Point> </PointCollection> </charting:Chart.DataContext> <charting:PieSeries Margin="0" IndependentValuePath="X" DependentValuePath="Y" ItemsSource="{Binding}"/> </charting:Chart>

The chart control can be bound to any data source. In this sample, the PointCollection data is supplied so that the designer will show some basic data on the design surface.

Blocking Issue

The tutorial I was following assumed that the designer had the Toolkit project’s source code in his or her project, rather than just a reference to the runtime binaries. That is to say, if you simply install the Silverlight Toolkit with the MSI file, adding the necessary binary references to your project will not allow the designer to modify the chart styles.

Here’s an image (circled in red) that shows that editing a copy of a template of the current selected item is unavailable.

The Workaround

At the time of this writing I still don’t know why the designer behaves this way with runtime binaries, but the workaround is to have the design solution also contain the source code for the Toolkit charting dependencies. You can download the entire Toolkit source code from the homepage of the CodePlex Silverlight Toolkit project by clicking on the download button, but you don’t need to add all projects to your solution to accomplish the goal.

Begin by deleting the existing references to the Toolkit runtime assemblies. Then add the following projects to your solution: Controls.Data.Toolkit, Controls.DataVisualization.Toolkit, Controls.Input.Toolkit, Controls.Layout.Toolkit, Controls.Theming.Toolkit and Controls.Toolkit. Lastly, add references to all these projects to the project that contains the page you want to create the chart in. Once you’ve added the references, the “Template Editing” option becomes enabled. From there you can modify the templates in the designer. The design surface will update visually as modifications are made.

Now it’s also possible to modify the DataPointStyle templates and the LegendItemStyle templates, which allow fine-grained control over how the data points and legend appear.

Erratum to Pete’s Blog Post

Pete’s blog post makes reference to a type: StylePalette. However, the correct type is Palette. The type’s name was changed after the December 9th, 2008 release of the Toolkit. At the time of this writing, the version from November 2009 is available.

Additionally, the path to the namespace reference in the XAML has changed from:

xmlns:datavis="clr-namespace:Microsoft.Windows.Controls.DataVisualization; assembly=Microsoft.Windows.Controls.DataVisualization"

to:

xmlns:datavis="clr-namespace:System.Windows.Controls.DataVisualization; assembly=System.Windows.Controls.DataVisualization.Toolkit" Themes

In theory, the themes support is very nice, since it’s very easy swap out the themes. However, you can’t author the theme ResourceDictionaries in Blend, since Blend doesn’t allow editing the XAML for a ResourceDictionary directly. As a result, you’ll find yourself jumping into the styling for a chart and manually moving it to a ResourceDictionary. Not the best designer experience.

Summing Up

The Silverlight Toolkit Charting controls work well out of the box, but if you are a designer and would like to restyle them, it will take a bit of work. Here is a link to much more useful information about the Silverlight Toolkit. A developer will have an easier time modifying the styling, but developers are not designers and generally can only take the design so far. Be aware that if you decide to use these charting controls, they aren’t particularly Blend-friendly. Perhaps this will change in the future.

Do you have some designer-friendly charting controls that you can recommend? Silverlight-based or not? Let us know. Leave a comment or if you tweet, follow us on Twitter to learn about new content, opinions and articles.

  

There has been an increasing and sincere interest in typography on the web over the last few years. Most websites rely on text to convey their messages, so it's not a surprise that text is treated with utmost care. In this article, we'll look at some useful techniques and clever effects that use the power of style sheets and some features of the upcoming CSS Text Level 3 specification, which should give Web designers finer control over text.

Keep in mind that these new properties and techniques are either new or still in the works, and some of the most popular browsers do not yet support them. But we feel it's important that you, as an informed and curious Web designer, know what's around the corner and be able to experiment in your projects.

  

  

Over the years designers have pushed themselves to create unique and inspiring designs. Companies have yearned to have websites which are innovative and make them stand out against their competitors. Yet charity websites have not progressed along with trends and expectations — they seem to have been designed for launch and then only updated with minor tweaks to suit the content.

It has become a recent trend for charities to look at their online identities and branding; spending money on creating user experiences which suit their user base, and over time getting people involved with their campaigns and messages.

Below we look at charity websites which have successfully developed their online brand using modern and creative ideas. We will also discuss how each charity website can be improved because, as we all know, not every website is perfect. There are always improvements to the design or usability that may have been overlooked by management, designers, or developers.

  

Inspiration can be a fickle thing. Most designers, when lacking ideas, turn to design galleries to find ideas. But there are a few problems with that approach. The most obvious is that when taking inspiration from similar mediums, there's a fine line between "inspired by" and "copied". To some extent, looking at established website designs can also be somewhat limiting, especially if you're looking for a fresh solution to a problem.

There are so many things designers could be turning to for inspiration outside of design galleries. We've cataloged a dozen of those places below, along with where you can find inspiration for each of them. Share any other inspirational sources you might have in the comments.

  

Business Web application design is too often neglected. I see a lot of applications that don't meet the needs of either businesses or users and thus contribute to a loss of profit and poor user experience. It even happens that designers are not involved in the process of creating applications at all, putting all of the responsibility on the shoulders of developers.

This is a tough task for developers, who may have plenty of back-end and front-end development experience but limited knowledge of design. This results in unsatisfied customers, frustrated users and failed projects.

So, we will cover the basics of user interface design for business Web applications. While one could apply many approaches, techniques and principles to UI design in general, our focus here will be on business Web applications.

  

  

Israel is a young country with an old heart. It has been quickly built up over the last 60 years as an independent democratic Jewish state and is shockingly cutting edge for a country so new.

It is a tiny surreal sliver of land smack dab in the middle of the Middle East: a very European, modern civilization… just programmed to Jewish tradition. Israel has great weather, nice beaches along the Mediterranean sea, fresh and tasty food and a warm and friendly culture. It is home to historic holy sites of the world's three major religions, and buses drive down streets whose stones are older than anything you'll find in Europe.

It feels as if Israel has one foot in Silicon Valley and the other in ancient Canaan — with an undercurrent of Middle Eastern hospitality and culture in this already multi-cultural society. And yet, English is commonly spoken here because many Jews from all over the world immigrate here regularly (not to mention the thousands of tourists from around the globe who pour in for sun, falafel, nightlife and a dash of biblical archaeology.) In some areas, you hear as much Spanish, French, Russian and English on the streets as Hebrew.

You may be interested in the following related posts:

• Showcase of Web Design in Russia
• Showcase of Web Design in Germany

Another generation of technology has passed and Unicode support is almost everywhere. The next step is to write software that is not just “internationalized” but truly multilingual. In this article we will skip through a bit of history and theory, then illustrate a neat hack called accent-folding. Accent-folding has its limitations but it can help make some important yet overlooked user interactions work better.

Whether it’s in front of a huge audience or a handful of executives, smooth public speaking is essential to a successful web design career. Yet most of us are more afraid of speaking in public than we are of death. In a lively give-and-take, Liz Danzico interviews Scott Berkun, author of Confessions of a Public Speaker, for tips on how to prepare for public speaking, how to perfect your timing, and what to do when bad things happen.

The other day I was out having a pint with a web-designer friend of mine, and she relayed a conversation with a client she'd had that day. I had to chuckle a little.

“So, Client X called me today, and she’d like to do a whole branding and website campaign,” she said.

I had heard about troubles working with Client X in the past. “Client X, huh? What’d you tell her?”

“Well, I gave her a standard ballpark figure, but told her I wouldn’t be able to get on it until the end of next month.”

“And of course she needs all of this done now.”

“Of course. So she suggests that she have one of her friends build the website while I work on the branding, and we might be able to get it out on schedule.”

“But you can’t start on this until the end of next month,” I said.

“Oh, but if someone else is building the website, then I should be able to do it now. According to her, of course.”

“Ah, yes. And this web designer is going to build the site without any branding or content, I’m assuming.”

“And Client X wants me to go ahead and ‘take the reigns’ on working with the web developer and just include her on the meetings as necessary.”

“Ah. So, project management, too. I see. And will you be writing content?” I asked.

“No, but she’d love me to help edit it.”

“Hmmm.”

“Oh, and if I could add a shopping cart, and some cool animation, that’d be great, too, but that might require more work with the web developer. Is that hard to implement?”

“Wow,” I said.

“Yeah,” she responded. “So, no, I’m not taking on the client.”

“Thank you,” I sighed. “I don’t know if either one of us would be able to stand having beers and talking about this for months and months and months. Because you *know* this would change 4 times.”

“Cheers to saying no.”

“Cheers.”

Where do *you* draw the line with projects? When do you push back on a feature, request, or even the project itself? Let us know by leaving a comment below and be sure to follow us @mixonline.

  

Using JavaScript has become increasingly easy over the last few years. Whereas back in the day we needed to know the quirks of every browser, now many libraries such as jQuery, YUI, Dojo and MooTools allow someone who doesn't even know JavaScript to spruce up boring HTML documents with impressive and shiny effects. By piggy-backing on the CSS selector engine, we have moved away from the complexity and inconsistencies of the DOM and made things much easier.

If you look at some of the code that has been released, though, we do seem to have taken a step backwards. In gaining easier access, we also became a bit sloppy with our code. Finding clearly structured, easy-to-maintain jQuery code is quite tough, which is why many plug-ins do the same thing. Writing one yourself is faster than trying to fathom what other developers have done.

The rules for solid, maintainable and secure JavaScript haven't changed, though. So, let's run through the seven sins of JavaScript development that will bite you in the backside when you have to maintain the code later on or hand it over to another party.

This article is part I in a series covering the topic of Web Design. Part II—The Future of Wireframes—is available for your viewing pleasure. Tiffani Jones, Matt Brown and Evan Sharp will contribute the remaining articles. Follow us on Twitter or subscribe to our RSS feed to be notified of their 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.

MIX

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.

Last year I had the opportunity to work with a very creative husband-wife pair, Matt Brown and Tiffani Jones. Their work was top-notch. They had recently started their own web design and content strategy businesses, ThingsThatAreBrown and Second And Park, respectively. I called Matt and Tiff (who's actually been working as the MIX Online editor for a few months now) with my fingers crossed, hoping they'd sign up to be part of the redesign team. Thankfully they did: Matt signed up to do the visual design, while Tiffani took care of the content strategy and copy. They brought along Evan Sharp (now at Facebook), the Principal of HeaderFooter, to do the markup and JavaScript. As far as dream teams go, I couldn't have asked for a better team.

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.

At-a-Glance

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:

1. Find the soul of the business
2. Figure out what to build
3. 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. Follow us on Twitter or subscribe to our RSS feed if you wish to be notified of its publication.

Who Sezs People Donuts Reads Anymore?

As this crafty tweet illustrates, Mr. Zeldman is Mr. Zeldman for a reason.

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.

Part III in this series of articles will cover the topic of Content Strategy. Follow us on Twitter or subscribe to our RSS feed if you wish to be notified of its publication.

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.

His message:

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:

1. Matt accepted the new direction. He asked to take a crack at refining it.
2. He came back with some concepts that merged his latest comp (we called it the "circles" comp) with mine.
3. I provided feedback to change a few things. He took another pass. Rinse. Repeat. Still didn't make the cut.
4. Oops. Time ran out.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.

Part IV in this series of articles will cover the topic of Visual Design. Follow us on Twitter or subscribe to our RSS feed if you wish to be notified of its publication.

From Comp to Code

Front-end markup is the design. Once a site is live, you don't edit it in Photoshop; you edit it in products like Expression Web, TextMate, and so on. Unfortunately, there are still scores of web designers who could care less about "programming". If you want to make a career designing for the Web, you need more than just a working knowledge of markup and scripting languages like HTML, CSS and JavaScript. They are to web design as the pen tool is to an illustrator. Seriously!

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.

Part V in this series of articles will cover the topic of Web Markup. Follow us on Twitter or subscribe to our RSS feed if you wish to be notified of its publication.

Phew, Maybe

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 Conclusion 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.

  

We’re excited to announce Incarnate for WordPress version 1.2. Significant work has been done with the plugin to address issues that arose with earlier versions.  Because WordPress theming engine’s flexibility, there were number of cases where the plugin didn’t play nicely with WordPress themes.  We’ve fixed these issues and the plugin will now work as expected with most themes right out of the box.  In fact, we’ve confirmed that Incarnate for WordPress is compatible with the following themes (including the 10 most popular as listed here).

• Arclite 2.02
• Arjuna X
• Atahualpa 3.4.5
• Comment Central 1.2.3
• Constructor 0.7.7
• Cordobo Green Park 2 0.9.502
• Dark Wood 1.7
• Mystique 1.72
• Inanis Glass 1.3.6
• LightWord 1.9.6
• Luxury Press 1.4
• Lysa 1.2
• Monochrome 2.7
• Multi-Color 1.6
• Organic Theme 1.9
• P2 1.1.3
• Piano Black 1.3
• Pixel 2.0.0
• WordPress Classic 1.5
• WordPress Default 1.6

 

Incarnate still doesn’t work by default with some themes—sometimes it takes a little manual tweaking. To address this, we’ve improved our instructions and documentation. 

One example of a theme that takes additional tweaking is Composito, which TommyLee’s blog, The Spider King uses. In this case, we had to change 2 lines to the comments.php file to get Incarnate working. First, we had to change line 28 of comments.php from this:

<p class="avt"><img src="<?php gravatar("R", 45, get_bloginfo('template_url')."/images/avatar-replace.png"); ?>" alt="Avatar" /></p>

To this:

<p class="avt"><?php if(function_exists('incarnate_for_wordpress_insert_avatar')) { incarnate_for_wordpress_insert_avatar($comment); } ?></p>

Second, the following line had to be added at line  62.

<?php if(function_exists('incarnate_for_wordpress_insert_ui')) { incarnate_for_wordpress_insert_ui(); } ?>

Moving forward, we will document themes which are known to work but require additional tweaks like this.  Let us know if you find one.

  

The email newsletter is a powerful marketing and communication tool that has various useful functions. It reminds your users about you; it informs users about your products; it tells them what you have been up to; and it helps you build a unique relationship with them. Users like email newsletters if the newsletters bring them value.

The fundamental rule for creating an email newsletter is to give it interesting, relevant and up-to-date information that is enjoyable to read. Users sign up for newsletters hoping be informed about things that they would not otherwise be able to find out about. In this article, we'll discuss some guidelines for designing and distributing email newsletters. Each point will be accompanied by both good and bad examples.

You may be interested in the following related posts:

• Design and Build Email Newsletters Without Losing Your Mind (and Soul)

  

Today we are glad to release a Free Medical Icons Set, a set with 60 original medical icons in .png 32 bit in resolutions 32×32px and 128×128px. This set was designed by the user interface design agency Centigrade and released exclusively for Smashing Magazine and its readers. The icons can serve as great in-app icons for desktop or RIAs in the medical domain. With perspective and reflective effects these can be a real stunner on landing pages or in touch screen application menus.

You can use the set for all of your projects for free and without any restrictions. You can freely use it for both your private and commercial projects, including software, online services, templates and themes. The set may not be resold, sublicensed, rented, transferred or otherwise made available for use. Please link to this article if you would like to spread the word.