{"id":9891,"date":"2015-11-14T02:01:46","date_gmt":"2015-11-14T02:01:46","guid":{"rendered":"http:\/\/proxystudio.uxpin.com\/?p=9891"},"modified":"2020-04-22T06:37:43","modified_gmt":"2020-04-22T13:37:43","slug":"how-to-use-ui-patterns-to-prototype-faster","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/how-to-use-ui-patterns-to-prototype-faster\/","title":{"rendered":"How to Use UI Patterns to Prototype Faster"},"content":{"rendered":"

If there\u2019s a pattern to using patterns, it lies in the tools designers use to create them. <\/p>\n

Having a standard library of reusable, easy-to-access elements is vital because the faster we build prototypes, the faster we can iterate through them. Quick iterations in the beginning lead to more time for development. Development time translates to beating deadlines. And that means happier clients, stakeholders, and users.<\/p>\n

\"image02\"<\/p>\n

Photo credit: Free UI Kit<\/a><\/em><\/p>\n

So it\u2019s not surprising that designers take full advantage of pre-made elements for low-fidelity and high-fidelity prototypes.<\/p>\n

But pre-made patterns have their drawbacks, and overcoming their shortcomings takes effort and awareness of what is going on \u2014 and how ignorance of that process is actually strength.<\/p>\n

Explaining the Gray Box<\/h2>\n

Those who use prototyping tools face a difficult challenge. <\/p>\n

Elements in their designs must represent specific components like input form fields, text blocks, and images. They also need variety: not just \u201cform fields\u201d but text areas, radio buttons and single-line input fields; not just \u201ctext\u201d but paragraph text boxes of any size and shape; placeholder images, imported photos and plain ol\u2019 \u201cpic goes here\u201d boxes.<\/p>\n

\"Sample<\/p>\n

The challenge is creating elements that clients and team members understand without dictating the final look-and-feel in a prototype. It\u2019s not about using the best <\/i>fidelity \u2013 it\u2019s about using the right fidelity. <\/p>\n

Start with a lo-fi prototype so you can explore user flows and basic usability (with feedback from users and your team), then iterate into a hi-fi prototype after testing. Don\u2019t dive immediately into high fidelity, no matter how tempting the idea of visual finesse. <\/p>\n

\"image03\"<\/p>\n

Above: A pattern in a lo-fi prototype with just enough detail (left) and somewhat lacking in detail (right) to indicate what\u2019s going on.<\/i><\/p>\n

The easiest \u2014 and most common \u2014 solution is to start with grayscale boxes that may (or may not) get filled in later. Gray boxes are design-agnostic, meaning they could apply to anything. Boxes say \u201csomething will go here, we just don\u2019t know what yet\u201d or \u201cpay attention to the big picture, don\u2019t get bogged down in the details.\u201d<\/p>\n

Thus most prototyping tools, including UXPin<\/a>, come with many pre-made elements that could mean many things. Unadorned boxes, for example, can stand in for images or header backgrounds. Buttons can let testers submit forms or signify calls to action. But sometimes gray rectangles are a little too vague. Even those responsible for the design can forget what every abstract shape means.<\/p>\n

The opposite approach is to create more recognizable, less generic objects. Radio buttons and checkboxes don\u2019t have to resemble each other. Browser windows can have round corners on the outside, and sharp corners inside their frames. Text of varying sizes sets headings apart from paragraphs, and paragraphs apart from calls to action. The more specific an element is, though, the less likely it will get used. Not every every project will need, say, a calendar or video window.
\nThe best prototypes bridge the gap that includes generic and specific objects. These objects become patterns as people learn to recognize them for what they are. Patterns emerge from understanding what, exactly, each element is without spelling it out. The prototype is therefore fast to create and provides just enough detail for users to focus on accomplishing tasks.<\/p>\n

\"image00\"<\/p>\n

Above, a more-specific object (top) communicates its purpose better than an abstract set of unlabeled shapes (bottom).<\/i><\/p>\n

Pattern Libraries Are Prototyping Shortcuts<\/h2>\n

Prototypes are built with a set of patterns, often called libraries, that contain elements designers don\u2019t have to invent. At the time of this writing, UXPin<\/a> has more than 900 of them. <\/p>\n

It\u2019s easy to drag a pattern into a design and discard it later. This allows designers to focus on solving problems without gnashing their teeth over visual design details. Instead they can design for user actions like whether or not to let travelers give hotels a star rating, or if that\u2019s overkill. <\/p>\n

Designers should make decisions, not patterns.<\/p>\n

\"Hotel<\/p>\n

In programming terms, patterns are instances of a class; in practical terms, they\u2019re shapes in a sidebar you drag into your design. Make as many as you need of the same thing. \u201cWhat if we have a calendar here?\u201d designers ask, and drag-n-drop one into place. Patterns are disposable. Prototyping tools make them inexpensive.<\/p>\n

Let\u2019s look how UI pattern libraries help you prototype faster while making the design easy to understand.<\/p>\n

Reusable elements<\/h3>\n

The mockup above recreates a standard search pattern with a twist: This one\u2019s geared for finding a hotel. It includes some technical (and practical) requirements like check\/out dates, number of people and location. <\/p>\n

Notice that the whole design uses only three kinds of elements: Text, input fields, and a single button. They\u2019re instantly recognizable for what they are. Not only that, but they\u2019re arranged almost identically. A text label is set atop each input field, making them easy to copy\/paste throughout the prototype.<\/p>\n

In the beginning stages of design, visual details don\u2019t matter as much, so it\u2019s more important that the design structure makes sense (which UI patterns help).<\/p>\n

Custom libraries<\/h3>\n

One-off elements are quick to create and customize. Whenever you need to repeat yourself precisely, though, you need some smarts.<\/p>\n

\"Hotel<\/p>\n

Certain parts of a project tend to remain the same on every screen but, like anything in development, change over the course of the project. For example:<\/p>\n