Kevin Cheng  

Design Trends and Design Patterns

January 23rd, 2006 by Kevin Cheng :: see related comic

Design trends are very much like fashion; they’re transient in character and often cyclical in their appeal. The popularity of gradients, for example, are like bell-bottom jeans, rising, falling, and then rising again in popularity.

Conversely, [design patterns][1] are the standards which emerge in interaction and visual design through repeated use. With a design pattern, a standard way of solving an interaction problem is stated and followed for the sake of predictability even if sometimes, it is not the absolute optimal design paradigm for the problem at hand.

When do we choose to follow a design trend versus a design pattern? Following a trend seems to be very short sighted in design whilst following design patterns can be restrictive and to many, stifling in creativity. Each also have their own benefits. So once again, [it depends][2].

## Design Trends
Often, design trends are followed simply for the sake of being hip. Take a look at the past decade and try to recall the excessive use of animated gifs, frames, drop shadows, Flash and even Ajax. Each were appealing and cool and signified some level of “hipness” at the time. Oftentimes, the trendiness extends beyond just design into the actual technical implementation.

Following a design trend does have its place. Just because it’s a fad doesn’t mean it’s not serving the audience. In fact, if the audience desired are those who are “hip”, then appealing aesthetically to these people is key, even giving them the impression of a more usable experience. Interestingly, within these fads are micro-design patterns which exist for that audience alone. The practice of tagging is something that the majority of web users still don’t understand or haven’t been exposed to but within a subset, there are certainly patterns emerging on the way to input and present them.

Of course, there are some design trends that simply make sense. The [Yellow Fade Technique][3] is a great example of an elegant solution to user notification. While that interaction is associated very closely with “web 2.0″ websites, the concept of using more subtle animations on sites will certainly be here to stay.

##Design Patterns
One popular design trends of late is the use of text without underlines or at times, even color differentiation, to represent links. We eschew the use of ugly blue links in favor of more color coordinated link text and remove the underlines until hover to reduce the clutter and visual noise on the pages. Yet the blue underline is so ingrained in us that I’m sure a reasonable number of readers were tempted to click on “web 1.0″ in our comic. The blue underlined link (and the associated purple visited link) is an example of a simple design patterns - in this case, patterns very strongly programmed into web surfing behavior.

I’m personally not a huge fan of design patterns because I believe in designing for the context of the situation and patterns feel like a restriction upon that. However, every designer inadvertedly follows design patterns of some sort. Tabbed browsing, left or top navigation, pull down menus, error messages are all examples of design patterns. Like the blue underline links, we could break from convention and follow “what’s cool” (marquee scrolling navigation, anyone?) but it comes at the cost of expected behavior.

I remember several years ago, I saw a great Flash demonstration of some very creative navigation systems. One of these was a revolver like icon for the navigation. The “revolver” would rotate and the selected “bullet” would zoom in and become the new page. The transition was intuitive and elegant, but didn’t conform to any convention for navigation. I never saw it again.

##Trend Patterns
Like the Yellow Fade Technique, there are rare cases where design trends turn into design patterns. Take a look at [Flickr’s Tag Clouds][4] page. Here’s a page which uses size to indicate more than headings. The gestalt effect of the larger tags easily indicates which tags are more frequently used by Flickr’s users. Upon seeing it, it makes complete sense. Yet it would have been so easy to simply show a descending sorted list with the tags and number of photos using that tag in parenthesis (much like what we have for comments in the Active Threads column on the front page).

Maybe a design trend is really an experimentation - a candidate - to become a design pattern. Or maybe design patterns are just longer lasting design trends.

[1]: “Interaction Design Patterns”
[2]: “It Depends”
[3]: “The Yellow Fade Technique”
[4]: “Popular Tags on Flickr”

28 Responses to “Design Trends and Design Patterns”
Stef Tof wrote:

While learning from the success in software development, I see more and more ppl talking about applying design pattern in UI design. I am glad to see the author’s comments on the design pattern. I am not a fan of “design pattern” too. So just want to share a few words here.

Design pattern is first introduced by the architect, Chris Alexander around thirty-years ago. Design pattern is heavily criticized that it kills creativity in architectural design, though surprisingly it becomes a huge success in computer science/software engineering when the Gang of Four picked the theory from the garage of architecture.

Undoubtedly, the value of pattern language in software development is significant. However, the value in UI design is very little. Personally, I think those suggests applying pattern language in UI design have never do UI design before. UI designers and software developers are solving different natures of problems. I like to use the concept of “wicked problems” to describe the problems we face in UI design. (

“Wicked problem” means “The problem is not understood until after formulation of a solution”. Due to this characteristic, applying design patterns in user interface design is inappropriate because we actually don’t know what the problems are, but designers will know the problems better and better when they are solving them. Those who have done UI design should know, design is a process which need to go through cycles of reflections and modifications. The main mistake of applying pattern languages is this assumes design as a input-process-output paradigm which is never happened in design.

Design patterns just like any case studies is useful for, say, training new designers . I strongly oppose the use of patterns in UI design because I have experienced how this inhibits creativity. Creativity is what our field really needed - Break the rules instead of following rules.

Martijn van Welie wrote:

It find it funny that many people, including you as I read, find that patterns may ‘restrict’ designers. Patterns simply document solutions that have stood the test of time in some way or another, but it does not say anywhare that you should ONLY use patterns in your work or stick to them by any means!!! Instead, they could give you a headstart by identifying solutions that you could consider. If there is not anything there of your liking every designer is of course free to invent new stuff.

The main power is in my opinion to avoid starting always totally from scratch as if nothing was ever learnt. For example, when designing a new sportscar we know from experience that a vehicle with 4 wheels, each at a corner, works well and that a power-to-weight ratio of 1:1 is close to ideal. And that if you want nice handling, the weight balance should be 50:50 front/back. Now, you could say that these facts (or patterns) limit the designer but unless the designer comes up with a brilliant new solution, the designer will have to deal with it…Recently we have been seeing a lot of 3 wheeled prototypes from European car manufacturers which indeed are different and undoubtable designed by ‘unrestrained’ designer. Fact is, they suffer from instability and bad handling….history repeats itself….

Jenifer Tidwell wrote:

I think that’s exactly what design patterns are — longer-lasting design trends or experiments that have “outgrown” their original context and are now found in many places. They’re good ideas that provably work — they make UIs easier to use — but they aren’t as general as principles or heuristics. However, they do help designers apply those principles correctly, by describing more concrete solutions that can still be used creatively in different contexts.

You say that you’re not a fan of patterns because you “believe in designing for the context of the situation.” Of course. But I think that’s exactly what patterns are good at. (So maybe you and I are using different definitions of “pattern,” but it’s still a worthy discussion.)

Error messages? Nah — too general to qualify as a design pattern. Same-page error messages that appear at the top of the page, placed so that the user can understand and fix the problem easily? Sure, that’s a pattern. It’s well-defined and supported by design principles, but adaptable to different situations.

Pull-down menus? Maybe, but they’re fairly low-level and standard, especially on desktop apps. An “action panel” set aside on the UI, where actions are dynamically placed and organized? That lets the designer be more creative within certain boundaries, so I think it’s more pattern-like.

(While I’m here, do you mind if I promote the UI patterns book I just wrote? It’s called “Designing Interfaces: Patterns for Effective Interaction Design,” and it’s published by O’Reilly. Look for the duck on the cover.)

Kevin Cheng wrote:

Martin: great points regarding patterns. Perhaps I have this mindset based on some patterns I’ve seen, which to your example, goes beyond saying that 4 wheels is the best solution and ventures to say “you can use 15″ or 17″ rims but nothing else”. Maybe those aspects aren’t patterns at all and are more classified under corporate standards and I’ve been blurring the lines between them.

Jenifer Tidwell wrote:

And Stef — what’s wrong with cataloguing UI solutions that are known to work?

I don’t think anyone’s recommending an unthinking, uncreative “input - process - output” paradigm for using design patterns. The best uses of them I’ve seen are by people who are aware of them, do creative work, and can pull them out of their mental toolboxes right when they’re needed. Patterns might even suggest innovative thinking in a direction a designer hasn’t considered yet.

(That holds true for both code patterns and UI patterns.)

Kevin Cheng wrote:

Error messages? Nah — too general to qualify as a design pattern. Same-page error messages that appear at the top of the page, placed so that the user can understand and fix the problem easily? Sure, that’s a pattern. It’s well-defined and supported by design principles, but adaptable to different situations.

Actually, that’s what I meant by error message design patterns. I should have been more specific. Thanks for putting it much more eloquently than I did =)

A lot of people try to overtly promote their site or product through our comments (it seems they feel designers love phe n t erm i ne) so we’re usually kind of wary of it but we don’t mind people promoting work when they are contributing to the discussion and the work they’re promoting is directly related. So here’s the Designing Interfaces: Patterns for Effective Interaction Design link!

Jared Spool wrote:

If done well, a design pattern is really only a technique for a design team to “stand on the shoulders of giants” and leverage the work of the past.

What happens, all too often, is teams don’t realize that some critical thinking has already occured, which could be valuable to their current context. In those cases, having a well-designed pattern library can really work wonders, saving design time and getting to the a working design sooner.

But, new problems do require innovative solutions. When innovation is truely needed, the pattern library takes a back seat to problem understanding and solving. Once a solution is available, however, it should be entered back into the library for others to take advantage of.

In my mind, we haven’t dealt with the scale issue: what happens when a library has 3000 patterns in it? I’m sure someone will come up with an innovative approach to that when it happens.

Great minds are thinking alike. I wrote an article on patterns today too: The Elements of a Design Pattern

Dmitry Nekrasovski wrote:

Stef - In addition to what previous posters wrote, you may be interested to know that Christopher Alexander came up with the concept of patterns to counter what he saw as the predominance of uncreative, cookie-cutter solutions to problems in architecture. Patterns can certainly be over-applied (as can any other design tool), but that doesn’t mean that they are designed to limit creativity - quite the opposite.

John Allsopp wrote:

I think in part the attitude of “patterns=limitation” stems from a misunderstanding of what a pettern is. A pattern is not a template, it is, to quote Alexander, “a problem which occurs over and over again … and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” [my emphasis].

Stef Tof wrote:

Of course, Alexander do not aim to introduce pattern to counter creativity. No one will do this! However, i haven’t yet seen any great architects today have applied patterns successfully to design (anyone can give me an example??).
Pattern is used to document solutions?? For each problem, how many solutions are there? there are not only a few. Number of solutions can be huge. So, should patterns document all solutions? but, can we?

I agree patterns can be treated as a collection of good design examples? so that, we can learn from the past. However, what’s differences from case studies? I think the value of patterns is it saves time from re-applying them to recurring problems. However, i can’t see the benefits of applying the same solution to the same problem. For example, I can observe ppl start copying the WIMP idea to the web interface though it has been accepted in desktop applications. However, WIMP is not the only way to interact!

Darren Hoyt wrote:

Anyone else getting 404s for the Yellow Fade images?

niblettes wrote:


Here’s some very pointless trivia…

I think the gun barrel site you remeber was a very old version of (flash and website design company from Puerto Rico–I think).

You might find a version archived at*/ I can’t tell because I won’t install the flash player.

Nick Finck wrote:

Interesting that this article of yours published on the same day as our artocle on Web Presentation Patterns which focuses on the programming techniques such as MVC to display page states and so forth.

Phil Wilson wrote:

If you don’t use underline on your links, how can I differentiate, or even tell, if two links are next to each other? Just by looking, I can’t. Provided there is a hover state which applies a different style to the link, I will be able to tell when I mouse the mouse over the link, otherwise, not a chance.

This is not reducing “the clutter and visual noise on the pages”, this is bad design.

Jenifer Tidwell wrote:

Stef, we don’t know whether great architects have applied patterns in their work, because we don’t have access to their thought processes!

I have many useful UI books on my shelves, most of which stay there 99% of the time. But I still “use” them, in the sense that I’ve read them and internalized them — they changed my thought processes and perceptions back when I read them. In any given project, do I “use” them? Yes, but not explicitly. That’s how I see a lot of software developers use code patterns.

By the way, there’s a good architecture book called “Not So Big House.” Its author, Sarah Susanka, says that Alexander’s patterns have been “a very useful tool in their office. … We use the book to help clients think about and describe how they want to tailor their house to their lifestyle and how to make it comfortable.” (page 11) So these architects do use patterns explicitly.

Diarmad McNally wrote:

Perhaps some of your ’scariest interfaces’ would have been better if the designers knew about patterns…

Kevin Cheng wrote:

Darren: I didn’t notice that until you pointed it out. I wanted to give credit to 37signals for popularizing it but since they aren’t keeping the page updated, I’ve changed the link to a tutorial on it.

Niblettes: that’s definitely the site. I recognize that url. Thanks! Too bad it’s no longer there (and the webarchives ones don’t either).

Nick: Collective consciousness. As Jared mentioned, UIE also published an article on patterns on the same day.

Jason Yip wrote:

A few people have already commented on this but I’ll still add my thoughts just to emphasise the point.

Saying something like “would have been better if the designers knew about patterns” is equivalent to saying “would have been better if the designers studied how other good designers had solved similar problems and why”. How many great architects have studied how other great architects solve design problems? I’d be guessing all of them.

The “Patterns movement” is about trying to document the decision-making process of expert designers in an attempt to communicate to both other experts and novices. Patterns exist whether or not someone has documented them or not.

Reading a “pattern” doesn’t mean you understand the “pattern”. The most important aspect of any documented Pattern is an understanding of Forces and Context. In other words, understanding Why.

If you only solve problems based on how others have solved problems, then yes, perhaps that is restricting, and even foolish when the context is sufficiently different. Understanding Why deals with this and when the context is sufficiently similar, it’s rather foolish to not be aware of what others have already learned.

J. Scott wrote:

I appreciate what Martin is doing. Christopher Alexander himself, in his introduction to Gabriel’s book, completely slams GoF style design patterns as missing his entire point. He says that what is really needed are design patterns for the interaction between the user and the program (as Martin is doing) and not a bunch of BS about internal implementation details, which would be like claiming design patterns applied to the microlevel of how to cut the lumber to make the desks in the buildings.

Thank you Martin. Keep up your important work.

J. Scott wrote:

Correction: Martijn not Martin. Sorry. And Jenifer also. Great work both of you.

Martijn van Welie wrote:

There is one more thing I’d like to emphasize and that is that patterns are all about context. When writing patterns one of the most difficult things is to figure out in which context the solution actually works well. When I write them I think of aspects such as the type of user, complexity of the task at hand, available screenspace, number of elements/objects involved in the tasks, and so on.

Accurately describing the context in which the pattern ‘works’ is probably the most difficult part in pattern writing. That is why you can find many patterns that almost leave it out and basically say ‘have this problem? Here is the solution’.

The context is also the differentiatior in terms of seeking solutions for similar problems. One problem may have several solutions and it is the context that will say when each solution is applicable. At the same time, if the available patterns do no match you particular context, the solutions will not help you much, except for the fact that you now know that those solutions are not the right ones for you. Since designing is basically the process of eliminating options until one is left, this will still bring you further in the process.

Martijn van Welie wrote:

@ Jared: ….just out of curiosity, which pattern libraries did you look at for your study? I’d love to see them as well…

Paul Brown wrote:

I know I’m a little late to this bandwagon and that this is off topic, but “a power-to-weight ratio of 1:1 is close to ideal”? What the hell units are you using, man? The very top line of sports motorbikes is just about knocking on 1 bhp/kg claimed although to my knowledge none have been proven. No production car can get anywhere near.

Even American cars can struggle to more than 1 bhp/tonne, so I am baffled as to what you had in mind.

A little less off topic, “design patterns applied to the microlevel of how to cut the lumber to make the desks in the buildings”, well I like my desk level with drawers that open and close, so I would say that design patterns applied very much to the cutting of material for the desks. There is a worrying trend recently to think of the interface as more important than the system behind it, but that is just as stupid as the opinion that the system matters and the interface doesn’t; the system can’t do its job for the user without an effective interface and an effective interface to system that doesn’t function is just plain pointless. Both are vital.

J. Scott wrote:

Irrelevant. You just don’t get it.

If calling something a design pattern and quoting Christopher Alexander, it makes sense to actually look at Alexander’s work rather than making up stuff randomly. (And BTW, Alexander is not the one who came up with this stuff, it was Mollison, who Alexander credits.)

Alexander’s design patterns had nothing to do with how to rivet the girders. They have to do with the interaction between the building and its occupants. They look at how the design of the building makes their lives and work better.

Martijn van Welie wrote:

@ Paul Brown….well, if I remember correctly a Formula 1 car nowadays has about 850 bhp and has to weigh less than 600 kg including driver! So actually it is a bit better than 1:1….and a F1 car is quite ’sportive’ isn’t it? ;-)

Darian Glover wrote:

I’ve been creating “design patterns” for a few years in a software development shop. The double quotes are to acknowledge the term may not be the most accurate as you will learn. The process started out of necessity as prior to my arrival the development process was that the developer wrote the application. Slowly we’ve added requirements gathering, testing, and design. It is a government contract and, as with most places, demand exceeds resources. We have over twenty developers, sixty applications, and the kind of chaos that fills Dilbert strips.

I was first hired because my designs looked good. Quickly they found out my designs also worked well. As the sole designer I could not possibly keep up with the demand. So entered the concept of design patterns for others to follow. The Java guys were using patterns and I adopted the term as apparently did everyone else. As Jared points out in his article organizational culture plays a role.

We are setting up a design library, but it is targeted at the developers and not other designers. What we have been doing is incorporating the designs into modular, reusable code files for the developers. I was fortunate enough to have two developers who leveraged my work into reusable code and it has caught on. Now the work is in educating the other developers on what should be used where and when, hence a library.

The problem I must deal with is that for my situation these “patterns” are multiple things rolled into one.

Specifications: use ‘user name’ and not ‘username’. The following fields are required…the following are optional…
Style Guide: The color palette consists of… Page layout is three columns…
Requirements: The page content will be accessible and meet Section 508 requirements… Page weight will be limited to under…
Implementation: The CSS classes are… The code modules are…

Which I believe is John’s point on misunderstanding. Maybe I can come up with a better term and displace the buzz on AJAX :)

To address Kevin’s points. There are fads and there are trends. Only time will tell the difference.

sk wrote:

Darian brings up a great point… design patterns are a great way to promote good design among the big community of developers who also design parts of their applications.

Designing for context is ideal when one is trying to take good design to excellent design but not so much when resources are tight and you want to bring applications from bad design to acceptable design. I think this is a great way to evangelise good usability. It is certainly not User Centered Design and does not claim to be such.

btw Jenifer’s book is a good read :)

Devdas Bhagat wrote:

This is late, but there are users of the program other than “endusers’. The source code is meant for humans to read and understand. Design patterns help in communicating with the users of the source code.

J. Scott is simply missing who the users are.

Leave a Reply

OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?