I wrote a new article for Smashing Magazine called Design Patterns: When Breaking The Rules Is OK:

W’d like to believe that we use established design patterns for common elements on the Web. We know what buttons should look like, how they should behave and how to design the Web forms that rely on those buttons. And yet, broken forms, buttons that look nothing like buttons, confusing navigation elements and more are rampant on the Web. It’s a boulevard of broken patterns out there.

I go on to the discuss the history of design patterns, and under what circumstances it’s ok to go off the beaten track and try something new. Enjoy!

Very true words from Peter Rojas in Generosity, empathy, and disruption:

I just don’t think it’s possible to build an amazing product or app or whatever without being able to empathize with and understand the person who is supposed to be using it. On some fundamental level great design is able to get into the mindset of a user and anticipate, guide, and delight. None of that is possible without empathy.

He also sums up why companies who make complex, ugly, and bloated enterprise software should be very scared — their competitors are going to come out of nowhere:

Generosity and empathy are becoming the big blind spots not only for many big companies, but often for entire industries (like financial services) which have drifted so far from any human-centric principles that they feel ripe for real competition from companies that decide to play the game differently. You can see it in the basic lack of respect in the way customers are often treated, and you can see it in so many of the sub-par products that are being produced because no one cares enough about the end user to make them better.

Christopher Butler wrote a good post on the relationship between Ego and Design, and how to structure design feedback better. It’s called Your Ego Is a Bad Designer, and he starts by explaining why development projects usually begin to go wrong during the design phase:

Design—specifically, when we start making visual decisions—is the first point in a project when we begin to engage one another in emotionally vulnerable ways. Every point in the process is an opportunity to second guess who is in control? and how do I feel about that? but design lacks the social decorum of sales negotiations and the regimentation of information architecture planning that would otherwise provide some structure for handling these potential conflicts. There’s simply no way to anticipate how the client will feel upon seeing that first mockup, or how you will respond, designer, to that initial deluge of feedback.

He then shares his approach to sharing work with clients, and structuring their feedback in a positive and helpful way. I also like the way he makes us as designers responsible for the success of a project:

We don’t fail at design because we lack tools, time, money, or the right clients. We fail at design because we lack insight. We don’t fail at design, we fail our design.

For more on design critiques, see these three great posts:

• Do you want critique, or a hug? How to gain valuable criticism on your design
• Moving from Critical Review to Critique
• Giving Better Design Feedback

Oliver Reichenstein takes on the tendency to put social media sharing buttons all over a site in Sweep the Sleaze. This part in particular is something I’ve thought about as well:

If readers are too lazy to copy and paste the URL, and write a few words about your content, then it is not because you lack these magical buttons. If you provide excellent content, social media users will take the time to read and talk about it in their networks. That’s what you really want. You don’t want a cheap thumbs up, you want your readers to talk about your content with their own voice.

By the way, in case you haven’t seen it — Oliver’s team just did a gorgeous redesign of their iA site. Be sure to check out his post Responsive Typography, which goes into some of the details.

Nishant Kothary takes a passage from a Jay-Z book and turns it into a great commentary on grid-based design in Rap it in a Grid:

The reality is, a grid makes the act of solving design problems seem predictable, but says nothing for supplying the appropriate design solution. The grid is akin to the beat. But it’s hardly ever the flow, which is the true design solution.

I’ve never fully bought into the “user experience cannot be designed” argument. You could say I’m biased because user experience design is how I choose to make my living, but I would (surprise!) disagree with that as well. Consider this paragraph from Chris Dixon’s excellent post The experience economy:

Experiences make people happier than products (a fact that scientific studies support). The popularity of experiences like music concerts has skyrocketed compared to corresponding products like music recordings. Apple, the most valuable company in the world, maniacally focuses on product experiences, down to minute details like the experience of unboxing an iPhone. Customers want to know where their food and clothes come from, so they can understand the experiences surrounding them. The emphasis on experiences also helps explain other large trends like the migration to cities. Cities have always offered the trade-off of fewer goods and less space in exchange for better experiences.

The main argument against experience design is that we can’t control context of use, no matter how hard we try. But the above examples are all cases where we can control enough of the context of use to make a reasonable assumption about the type of experience the majority of users will have. The same goes for web sites — through creativity and a little user testing, we can get to a similar level of comfort with how most users will experience our sites/apps.

So, don’t give up, experience designers. We can build great experiences for our users (while also meeting business goals at the same time).

Matt Simmons wrote a great post on designing elegant solutions for when users inevitably make mistakes on your system. In Engineering Infrastructures For Humans he uses the example of ash trays in airplanes to make his main point:

You don’t engineer your systems with the belief that none of your computers will ever break. That’s insane; you KNOW they’re going to break. So don’t assume that your users will never break the rules. Build in graceful failure as often as possible, whether you’re designing a user interface or a security policy.

The ash tray story is really interesting, so be sure to click through to his post.

South African bank Absa just rolled out their new online banking portal. There are two things about this launch that raise red flags for me. First, from ABSA rolls out new Internet Banking revision:

This launch follows a successful trial with the bank’s 36 000 employees over the past few months. The trial allowed the project team to identify and solve any defects and gauge the response from users, via over 1 300 feedback emails received from employees.

It’s shocking that we still have to talk about this, but let’s just state it again, as clearly as possible: You are not the user. You cannot test a system on employees — who know all the intricacies inside and out — and think that you’ve done appropriate user testing. There are plenty of solid arguments and evidence for this, but for now I’ll just quote Jakob Nielsen:

One of usability’s most hard-earned lessons is that “you are not the user.” If you work on a development project, you’re atypical by definition. Design to optimize the user experience for outsiders, not insiders. The antidote to bubble vapor is user testing: find out what representative users need. It’s tempting to work on what’s hot, but to make money, focus on the basics that customers value.

Also see Myth #14: You are like your users and You are not your user, which both have a lot of great points and research around this.

Second, there’s this quote from the Head of Retail Markets at ABSA:

The development of Absa Online saw up to 140 individuals, working across three continents, putting in an astonishing 450 000 man-hours of development work. Four million lines of code were written in this, a “first-of-its-kind” technology deployment in South Africa.

Well, that is just silliness. As one of the commenters on the article points out, it’s Bill Gates of all people who said, “Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.”

The size of the project, how long it took, and how many people worked on it is completely immaterial. What matters is if the thing works well to help real users accomplish their goals. I really hope it does, because this looks like an outrageously expensive project. Hopefully it doesn’t become South Africa’s version of the Four Seasons $18m redesign.

I’ll probably never get tired of articles about Comic Sans. And as far as they go, Jenny Ambrose’s What’s the Deal with Comic Sans? is a pretty good one. Here is Comic Sans designer Vincent Connare in his own words:

There was no intention to include the font in other applications other than those designed for children. The inspiration came at the shock of seeing Times New Roman used in an inappropriate way.

I love the irony of this. As Ambrose points out:

Here we are in 2012, discussing the usage appropriateness of a typeface created in 1994, which was in turn created in response to that very same typography appropriateness problem.

And round and round we go. Also see my small contribution to this debate.

I’m a big fan of Stephen Few and his approach to data visualization. His book Show Me The Numbers: Designing Tables and Graphs to Enlighten has been immensely helpful in my work as a user researcher, and I’ve been lucky enough to attend one of his excellent seminars. So I’ve been really interested to hear his viewpoint on the latest Infographic craze that’s taking the pageview world by storm.

I am personally not a fan of the Infographics that are passed around on Twitter every day. Most of them are confusing and only meant to drive eye candy-derived traffic with no intention to communicate data clearly. I think we pretty much hit rock bottom with this Mashable monstrosity called “The Internet Is Ruining Your Brain”. For some fun reading, also see Dan Frommer’s How Infographics Are Ruining The Web, and Megan McArdle’s Ending the Infographic Plague.

But now, Stephen finally weighed in on his blog with a very sensible argument about the nature of data visualization, and where common web infographics fit into that universe. He starts his article Data Art vs. Data Visualization by making an important distinction:

There are as many definitions of data visualization as there are definers, but at the root of this term that has been around for many years is the goal that data be visualized in a way that leads to understanding. Whatever else it does, it must inform. If we accept this as fundamental to the definition of data visualization, we can judge the merits of any example above all else on how clearly, thoroughly, and accurately it enlightens.

By data art, I’m referring to visualizations of data that seek primarily to entertain or produce an aesthetic experience. It is art that is based on data. As such, we can judge its merits as we do art in general.

He goes on to give three reasons why it’s harmful when data art masquerades as data visualization.