Do UI Patterns Destroy Innovation?
We have been using patterns to solve problems for a long time. Generally people (in our industry) would define a pattern similar to this definition found on wikipedia
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
Are we pulling the emergency brake on innovation when we resort to using a pattern just because it’s been used successfully before? Henry Ford said, “I cannot discover that anyone knows enough to say definitely what is and what is not possible.” Mr. Ford has actually said a lot of inspiring things in regards to innovation.
Sure. There is the usability argument that if people aren’t familiar with it they will shy away. People like the cozy and fuzzy and tend to migrate towards what they are comfortable with, so there are considerations to be taken. But if your innovation breeds experience, people will use it.
Patterns are a great to use as inspiration and to see what has and can be done, but they are not the holy grail and by definition, using them is not being innovative. There are times to use them as described but I would take them with a grain of salt. Look past what has already been done and find a better way. Maybe your innovation will be the next pattern.
A FEW PATTERN RESOURCES
ui-patterns.com/
uipatternfactory.com
quince.infragistics.com/UX-Design-Patterns.aspx
developer.yahoo.com/ypatterns
uidesignpatterns.org/designPatterns
patterntap.com
Agree? Disagree?
We would love to hear your thoughts!
Grab the Feed
Great question.
My thought is that UI patterns encourage innovation, not destroy it. UI patterns provide us with a base functionality which can then be customized for the needs of the solution that is required.
Usability is key – no matter what design is added, the user must know what function will be performed from an action input to an interface.
While these points are valid I don;t believe they are that black and white. For instance, customization of a pattern rarely results in innovation, and while I agree usability is *a* key, it’s not *the* key.
There is something to be said about the value and reward that comes from user discovery. There is a strong emotional attachment to end-user problem solving. It makes the experience that much more enjoyable.
I don’t think they destroy innovation. I think having common U/I patterns for common tasks allow you to focus your innovation where its needed, such as coming up with patterns that are unique to your project.
I’m a big believer in using design patterns with the caveat that they are guidelines for the holistic architecture, however that does not discount the value of on-going innovations of sub-patterns. For example, a pattern for calendar widget could be designed in a variety of ways. Perhaps a more innovative way can be designed and implemented for that pattern which can be applied in context over a library of other calendar widget patterns. Ideally you are able to plug in the patterns or widgets (I use this term loosely) within a context where the overall design architecture has been defined – e.g. if you are creating an application based on the inductive design paradigm or architecutre then apply patterns that help keep the overall design holistically cohesive. The bottom line is that a balance is necessary, it helps having a standard refernce for best practice to maintain consistency, and ideally those patterns have been usability tested, yet on-going innovation of new sub-patterns is required for on-going evolution.
Yes, but that’s okay.
I feel that UI patterns inhibit innovation, with the trade-off being usability, as you mentioned. Intuitive designs are the ultimate goal.
If you focus on the most intuitive way for your user to perform “action X”, patterns are an amazing resource. They give you the understanding of what has and hasn’t worked in the past.
Once you understand the current way that users are interacting, you can then experiment with ways that it could be improved.
I agree with Dan and the point that patterns are only a starting point. This is a good article and my follow-up question: what’s the intention behind innovation — to solve a problem for the user or to stroke an ego?
I think for most innovators, the ego has to be there to begin with. Egos get a bad wrap sometimes, but can be taken too far.
Patterns are traditions. They developer over time because we observe that they work. However, like any other tradition, at any time when we determine they no longer work due to a change in circumstances, attitude, expectations, etc, we must reassess them. And like traditions, we should never blindly follow them, “just because that’s the way its always been done”.
Patterns are a great help in speeding along the development of a UI. When an entrepreneur is trying to launch a new Internet product, they don’t necessarily have time to reinvent the UI wheel. They see a need in the market, they fill the need, they launch as rapidly as is feasible, and then interact with consumers to fine tune it. At that point, after the launch, is the best time to question the patterns; put them to the test, and look for new and innovative ways to solve the problems of their customers and make the site/application easier to use.
I might have read this wrong, but I don’t think after launch is the best time to question the patterns.
If you are going to use patterns do develop rapidly, you should look at them when doing your usability testing. Too often we see a sites glory end when the “publish” button gets pressed. In the film industry you’d hear, “…we’ll fix it in post”. But then funds run out and you see the Coke can sitting in the swamps of Degobah.
No good web site ever ends after publish. It’s not like a movie that has a final edition that is shipped. A good web app is never done. I didn’t mean to imply that you shouldn’t ensure that your UI works before first release, but I don’t believe in huge long product development time frames to get it perfect up front. 37 Signals apps are a great example. The original releases were no where near as polished as they are today. They got something out there, then continued to refine as they observed usage and listened to customers and used it themselves. And they will continue to refine them for as long as they are running.
Yep, totally agree with you!
Simply put, yes, design patterns inhibit innovation.
1) Real innovation is visionary and disruptive – to industries as well as to the patterns at the interface with their users.
2) The corporate mediocracy typically will emphasize patterns to the detriment of the user and so the business. (See Google as designed by marketing managers. They’d get everything right, pattern-wise, and fail in the most obvious way. http://webusability-blog.com/google-by-marketing-managers/.)
3) If you don’t have the gift of vision or the luxury of time for creativity refined by rounds of iterations based on user testing… in other words, if you need to knock out some design, patterns are there to copy. And it’s no small matter that having a design pattern to point to can cover your butt when blame is running downhill.
The answer depends on what you are trying to do. If you seek inspiration for solutions to a commonly recurring problem, UI patterns can help innovation. Using them allows you to move on so that you focus on what in your design actually requires innovation. If you seek to create something that is entirely new, on the other hand, appropriate patterns probably aren’t available.
You make valid points all of them. I think that we want to be heard as much as we don’t want to leave comments in the wrong circumstances. It’s a human response to a human problem — as contadictory as we all are.