Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Interaction design pattern
open-in-new
<h2 id="history">History</h2> <p>Patterns originated as an <a href="/facts/Design_pattern_(architecture)/2VmTfS9F">architectural concept</a> by <a href="/facts/Christopher_Alexander/Hrd2muer">Christopher Alexander</a>. Patterns are ways to describe best practices, explain good designs, and capture experience so that other people can reuse these solutions. </p><p><a href="/facts/Design_pattern_(computer_science)/mV7r4egw">Design patterns</a> in computer science are used by software engineers during the actual design process and when communicating designs to others. Design patterns gained popularity in computer science after the book <a href="/facts/Design_Patterns_(book)/sYDxSGc9"><i>Design Patterns: Elements of Reusable Object-Oriented Software</i></a> was published. Since then a pattern community has emerged that specifies patterns for problem domains including architectural styles and object-oriented frameworks. The <a href="/facts/Pattern_Languages_of_Programming/0L2nEmLa">Pattern Languages of Programming</a> Conference (annual, 1994—) <a href="http://hillside.net/plop/pastconferences.html">proceedings</a> includes many examples of domain-specific patterns. </p><p>Applying a pattern language approach to interaction design was first suggested in Norman and Draper's book <i>User Centered System Design</i> (1986). The Apple Computer's Macintosh Human Interface Guidelines also quotes Christopher Alexander's works in its recommended reading. </p> <h2 id="libraries">Libraries</h2> <p>Alexander envisioned a <a href="/facts/Pattern_language/U0Xbp7nx">pattern language</a> as a structured system in which the semantic relationships between the patterns create a whole that is greater than the sum of its parts, much like the way that grammatical relationships between words make language meaningful.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> While some collections of patterns attempt to create the structural relationships needed to form a language, many others are simply an assemblage of patterns (and thus are more appropriately termed pattern libraries.) </p> <h2 id="mobile-interaction-pattern-libraries">Mobile interaction pattern libraries</h2> <p>The popularity of mobile devices such as smartphones and tablets usher in a need for a library of mobile interaction design patterns. </p><p>This need is driven by: </p> <ul><li>Differences in user behavior and interaction on mobile devices such as swipe and tap gestures, vis-a-vis interaction on a Desktop GUI, which is mouse-driven</li> <li>Differences in physical attributes between a mobile and a desktop device e.g. screen size, touch screen, etc.</li> <li>Design guidelines recommended by mobile OS e.g. iOS, Android</li></ul> <h2 id="elements">Elements</h2> <p>For patterns to be helpful to the designers and developers who will make use of them, they need to be findable and readable.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a><a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a><a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> </p> <h3>Common elements</h3> <p>Though pattern descriptions vary somewhat, many pattern libraries include some common elements: </p> <ul><li>Pattern Name: Choosing a clear and descriptive name helps people find the pattern and encourages clear communication between team members during design discussions.</li> <li>Pattern Description: Because short names like "one-window drilldown" are sometimes not sufficient to describe the pattern, a few additional lines of explanation (or a canonical screenshot) will help explain how the pattern works.</li> <li>Problem Statement: Written in user-centered language, this communicates what the user wants to achieve or what the challenge is to the end-user.</li> <li>Use When: "Context of use" is a critical component of the design pattern. This element helps people understand situations when the design pattern applies (and when it does not.)</li> <li>Solution: The solution should explain "how" to solve the problem, and may include prescriptive checklists, screenshots, or even short videos demonstrating the pattern in action.</li> <li>Rationale: Providing reasons "why" the pattern works will reinforce the solution, though time-pressed developers may prefer to ignore this explanation.</li> <li>Examples: Each example shows how the pattern has been successfully applied This is often accompanied by a <a href="/facts/Screenshot/efJKoKp5">screenshot</a> and a short description.</li> <li>Comments: Including a place for team members to discuss the use of the pattern helps maintain an active resource and keeps the team engaged.</li></ul> <h3>Optional elements</h3> <p>Pattern libraries can also include optional elements, depending on the needs of the team using them. These may include: </p> <ul><li>Implementation Specifications: A style guide with detailed information about font sizes, pixel dimensions, colors, and wording for messages and labels can be helpful for developers.</li> <li>Usability Research: Any supporting research from usability tests or other user feedback should be captured. This can also include feedback from developers, customer service, or the sales team.</li> <li>Related Patterns: The pattern library may include similar patterns, or it may be organized into a hierarchy of parent and child patterns.</li> <li>Similar Approaches: Since there are likely to be many possible solutions to this problem, teams may want a place to capture similar alternatives.</li> <li>Source Code: If the code is modular enough to be reused, then it can be included in the library as well.</li></ul> <h2 id="reasons-to-use-design-patterns">Reasons to use design patterns</h2> <p>Benefits of using interaction design patterns include: </p> <ul><li>Teaching novices some best practices and common approaches</li> <li>Capturing collective wisdom of designers across many uses and scenarios</li> <li>Giving teams a common language, reducing misunderstandings that arise from the different vocabulary</li> <li>Reducing time and costs in the design and development lifecycle</li> <li>Making usable designs the "<a href="/facts/Path_of_least_resistance/jqyV9uzK">path of least resistance</a>"</li> <li>Eliminate wasted time spent "reinventing the wheel"</li> <li>Ensuring users have a consistent and predictable experience within an application or service</li></ul> <h2 id="advantages-over-design-guidelines">Advantages over design guidelines</h2> <p>Guidelines are generally more useful for describing requirements whereas patterns are useful tools for those who need to translate requirements into specific software solutions. Some people consider design guidelines as an instance of interaction design pattern as they are also common approach of capturing the experience in interaction design. However, interaction design patterns usually have the following advantages over design guidelines: </p> <ol><li>Abstract guidelines, like the <i>Eight Golden Rules of Interface Design</i> by Shneiderman, do not suggest how to solve a problem like many interaction design pattern, and cannot be used for interdisciplinary communication. Furthermore, guidelines do not provide an explanation as to why a particular solution works.</li> <li>Concrete guidelines, like Macintosh Human Interface Guidelines, are too tailored to a specific interface, and therefore are not as effective when applied to other interfaces (especially non-Macintosh interfaces).</li> <li>Other problems with guidelines are that they tend to be too numerous which makes it difficult for designers to apply the right guidelines. Also guidelines assume an absolute validity while usually they can only be applied in a particular context. A result of that is also that guidelines often tend to conflict just because they lack describing a context.</li></ol> <p>Guidelines and patterns are not necessarily conflicting, and both can be used in conjunction to identify the problem and then create a valid solution. </p> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Design_pattern/bHvkoxsu">Design pattern</a></li> <li><a href="/facts/Gameplay/kGVFkkjx">Gameplay</a></li> <li><a href="/facts/Elements_of_Design/ApVTLx2V">Elements of Design</a></li> <li><a href="/facts/Information_architecture/xhAHVzA7">Information architecture</a></li> <li><a href="/facts/Interaction_design/6aKgJFNW">Interaction design</a></li> <li><a href="/facts/Interactivity/9LeFR3ru">Interactivity</a></li> <li><a href="/facts/Interface_design/bHpLP1ae">Interface design</a></li> <li><a href="/facts/Mobile_interaction/UacJfYSY">Mobile interaction</a></li> <li><a href="/facts/Sonic_interaction_design/ssleIvwc">Sonic interaction design</a></li> <li><a href="/facts/Usability/zuAnqu9Q">Usability</a></li> <li><a href="/facts/User-centered_design/1qLwIbSw">User-centered design</a></li></ul> <h2 id="further-reading">Further reading</h2> <ul><li><i>A Pattern Approach to Interaction Design,</i> by Jan Borchers, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-471-49828-9</li> <li><i>A Pattern Language for Web Usability,</i> by Ian Graham, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-201-78888-8</li> <li><i>Interaction Design Patterns für NFC-basierte Electronic Data Capture Anwendungen</i> by Andreas Prinz, Prinz Publishing, Dieburg 2014, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-3-9816875-0-7.</li> <li><i>The Design of Sites: Patterns for Creating Winning Websites (Second Edition),</i> by Douglas K. van Duyne, James A. Landay, and Jason I. Hong, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-13-134555-9</li> <li><i>Designing Interfaces: Patterns for Effective Interaction Design,</i> by Jenifer Tidwell, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-596-00803-1</li> <li><i>Designing Social Interfaces: Principles, Patterns, & Practices for Improving the User Experience,</i> by Christian Crumlish and Erin Malone, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-596-15492-5</li> <li><i>Interaction Design for Complex Cognitive Activities with Visual Representations: A Pattern-Based Approach,</i> by Kamran Sedig and Paul Parsons, <a href="http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1057&context=thci">AIS Transactions on Human-Computer Interaction 5(2), 84-133</a>.</li></ul> <h2 id="external-links">External links</h2> <ul><li><a href="https://www.interaction-design.org/literature/article/10-great-sites-for-ui-design-patterns">10 Great Sites for UI Design Patterns</a> at Interaction Design foundation</li> <li><a href="https://developer.yahoo.com/ypatterns/">Yahoo Design Pattern Library</a></li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>Coplien, James. "A Pattern Definition". Bell Laboratories. Archived from the original on 2007-02-09. Retrieved 2008-11-24. <a href="https://web.archive.org/web/20070209224120/http://hillside.net/patterns/definition.html" target="_blank">https://web.archive.org/web/20070209224120/http://hillside.net/patterns/definition.html</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>"What's a Pattern?". Yahoo!. Archived from the original on 2008-12-04. Retrieved 2008-11-24. <a href="https://web.archive.org/web/20081204010012/http://developer.yahoo.com/ypatterns/page.php?page=lifecycle" target="_blank">https://web.archive.org/web/20081204010012/http://developer.yahoo.com/ypatterns/page.php?page=lifecycle</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>Tidwell, Jennifer. "Common Ground: A Pattern Language for Human-Computer Interface Design". MIT. Retrieved 2008-11-24. <a href="https://www.mit.edu/~jtidwell/interaction_patterns.html" target="_blank">https://www.mit.edu/~jtidwell/interaction_patterns.html</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>Pemberton, Lyn. "Genre as a Structuring Concept for Interaction Design Pattern Languages". University of Brighton. Archived from the original on 2006-10-22. Retrieved 2008-11-24. <a href="https://web.archive.org/web/20061022190840/http://www.it.bton.ac.uk/staff/lp22/genredraft.html" target="_blank">https://web.archive.org/web/20061022190840/http://www.it.bton.ac.uk/staff/lp22/genredraft.html</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Spool, Jared. "The Elements of a Design Pattern". User Interface Engineering. Archived from the original on 2008-12-20. Retrieved 2008-11-24. <a href="https://web.archive.org/web/20081220050709/http://www.uie.com/articles/elements_of_a_design_pattern/" target="_blank">https://web.archive.org/web/20081220050709/http://www.uie.com/articles/elements_of_a_design_pattern/</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Malone, Erin. "Implementing a Pattern Library in the Real World: A Yahoo! Case Study". Boxes and Arrows. Archived from the original on 2008-12-07. Retrieved 2008-11-24. <a href="https://web.archive.org/web/20081207023837/http://www.boxesandarrows.com/view/implementing_a_pattern_library_in_the_real_world_a_yahoo_case_study" target="_blank">https://web.archive.org/web/20081207023837/http://www.boxesandarrows.com/view/implementing_a_pattern_library_in_the_real_world_a_yahoo_case_study</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Kunert, Tibor (23 June 2009). User-Centered Interaction Design Patterns for Interactive Digital Television Applications. Springer. ISBN 9781848822740. Retrieved 2009-07-06. <a href="9781848822740" target="_blank">9781848822740</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> </ol>