{"id":10028,"date":"2015-11-24T03:52:52","date_gmt":"2015-11-24T03:52:52","guid":{"rendered":"http:\/\/proxystudio.uxpin.com\/?p=10028"},"modified":"2024-09-09T19:43:18","modified_gmt":"2024-09-10T02:43:18","slug":"the-designers-guide-to-prototyping-better-with-developers","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/the-designers-guide-to-prototyping-better-with-developers\/","title":{"rendered":"The Designer’s Guide to Prototyping Better With Developers"},"content":{"rendered":"

Although wireframing and prototyping are two different tasks, they both represent a web or mobile interface in its most fundamental stages.<\/p>\n

Meant as an explorative exercise and an early visual specs document, wireframes are a natural part of the design process<\/a>. And as we described in the Ultimate Guide to Prototyping<\/a>, you can then turn a wireframe into a low-fi prototype by adding interactions or jump directly into a paper prototype.<\/p>\n

Photo credits: <\/i>UXPin<\/i><\/a><\/p>\n

Just because the design team creates the wireframes and prototypes doesn\u2019t mean that developers have nothing to offer. In fact, developers can share early opinions while the wireframes are still rough, which helps catch small nuisances and even offer potential improvements for rough layout concepts.<\/p>\n

In this piece, we\u2019ll explore some guidelines for wireframing and prototyping so that they communicate the experience as clearly as possible to other designers, developers, and stakeholders.<\/p>\n

Wireframing for Developers<\/h2>\n

The best way to approach a wireframe is as a blueprint for the product team.<\/p>\n

Before adding any details, you must first lay out the headers, footers, content areas, and the relationships between these page sections. In our experience, we prefer to first wireframe the homepage (so we can start to think about content flow at the broadest level), then dive into landing pages and finally secondary pages (like About Us or Contact).<\/p>\n

If developers are expected to code an HTML prototype straight from wireframes, then it\u2019s important to give them as much information as possible. In this case, you\u2019ll want to lean towards higher fidelity with crisp typography, richer colors, and high-resolution images since the wireframe will serve as the primary visual reference. If you prefer wireframing on paper, we recommend the \u201csketching in layers<\/a>\u201d technique since it provides more structure and detail than standard freehand sketching.<\/p>\n

\"image06\"<\/p>\n

Photo credits: <\/i>UXPin<\/i><\/a><\/p>\n

On the other hand, if you\u2019re going to iterate the wireframe into a rapid prototype<\/a> using a specialized tool, then the wireframe doesn\u2019t need to be as formal (although annotations are still helpful for later reference). In this situation, your prototype instead serves as a living representation of your technical specs.<\/p>\n

 <\/p>\n

\"UXPin<\/p>\n

Photo credit: <\/i>UXPin<\/i><\/a><\/p>\n

When wireframing, clear explanations are vital because designers, developers<\/a>, and non-technical stakeholders should able to review your designs and quickly understand how they work. The best wireframes incorporate notes in the margins expressing which elements should be clickable, animated, or dynamic in any way.<\/p>\n

\"image01\"<\/p>\n

But you can also create similar documents for telegraphing the intent of pages or page elements to developers. Here are a few common supplementary documents (which we first described in The Guide to UX Design Process<\/a>):
\nStoryboards<\/b> \u2013 Storyboards focus on the movement of elements and which links direct to which pages, creating a visual narrative for the entire team. Some links may not even load pages, but instead trigger effects like dropdown menus or modal windows. Created through sketchboarding<\/a> or digital mediums, storyboards give developers a snapshot of the entire experience so they understand why some complex interactions might be necessary.<\/p>\n

Flow charts \u2013 Flow charts are similar to storyboards except they focus more on content itself. A website flowchart<\/a> usually resembles a visual sitemap, except in a more multi-directional format that is more descriptive than the traditional tree structure. Detailed flow charts can be extremely helpful for developers since you could annotate how content is served (e.g. whether a lightbox is triggered via Javascript event or AJAX). If you lack the technical knowledge, map out the site pages in the flowchart, then collaborate on the technical notes with the developer.<\/b><\/p>\n

\"Flowchart<\/p>\n

Photo credit: <\/i>UXPin<\/a><\/i><\/p>\n

Personas<\/b> \u2013 Like we previously discussed, the strongest way to align design and development is to focus everyone on user needs. Don\u2019t just include job titles and demographics. Dive into fears, ambitions, behaviors, goals, and habits. Create lightweight personas<\/a>, print them out for the product team, and let them become everyone\u2019s best imaginary friend.<\/b><\/p>\n

While you want to keep documentation as light as possible, don\u2019t underestimate it\u2019s power for updating developers as fidelity increases.<\/p>\n

In our experience, developers tend to be highly logical people who enjoy the security of tangible visual requirements. When you treat design documentation as a collaborative tool rather than a \u201chand-off-and-pray-for-the-best\u201d document, you\u2019ll find that developers will know what to build and designers will have a quick reference for popular and unpopular ideas.<\/p>\n

Whatever your documentation methods, make sure they complement rather than supplement your design process.<\/p>\n

Prototyping for Interaction<\/h2>\n

When putting together digital interfaces, look at all the design features as a set of jobs. Each element on the page must help advance users toward completing their goal(s).<\/p>\n

As described in Interaction Design Best Practices, think in terms of components rather than page elements. Which components on the page require action? What task does this action perform?<\/p>\n

An interesting point to note is that developers speak the language of interaction. Developers review a wireframe\/prototype and mentally formulate how it should be built. In some instances, developers might even mirror a rapid UX prototype with their own quick HTML\/CSS\/Javascript prototype to test the interactions.<\/p>\n

This is the beauty of designing for interaction: it helps everybody in the creative pipeline.<\/p>\n

When designing for interaction, you\u2019ll spend most of your time in prototypes. It\u2019s harder to wireframe interactions since you\u2019ll need plenty of annotations, but it is certainly possible (and especially helpful for mobile interactions where you want to quickly show gestures).<\/p>\n

Regardless of your process, the most important thing to remember is that you design just the right level of fidelity. Otherwise, you might jump headfirst into a hi-fi prototype (dragging your developer with you on complex discussions around animations\/interactions), when all you need is a low-fi prototype to explore structure and page flow.<\/p>\n

Be proactive and set the right expectations around the design, because stakeholder feedback also indirectly affects developers.<\/p>\n

When possible, work with the product manager or project manager to outline a project map so everyone knows what to expect regarding the number of drafts, possible revisions, and levels of fidelity for prototypes & wireframes.<\/p>\n

Testing, Gathering Feedback & Revising<\/h2>\n

Make sure you invite developers to all feedback sessions, whether it\u2019s a simple user interview<\/a> a moderated usability test<\/a>, or an internal feedback session.<\/p>\n

Conducting usability testing with developers<\/b><\/h3>\n

Not only can you both synthesize feedback in real-time, collaborative user research creates a stronger sense of joint ownership and creation. Interestingly enough, Xerox actually sends their designers with service engineers during on-site visits<\/a> to deepen their understanding of how customers use the products.<\/p>\n

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

Photo credit: <\/i>\u201cWikimedia User Testing\u201d<\/i><\/a>. Blue Oxen Associates. <\/i>Creative Commons<\/i><\/a>. <\/i><\/p>\n

Of course, collaborative usability testing isn\u2019t just about sending pairs of people into the field to observe users.<\/p>\n

As we described in the Guide to Usability Testing<\/a>, it can be as simple as drafting up the core tasks together, then presenting the tasks to 5-7 users and asking them to think aloud as they interact with the prototype. Study which features draw the most attention right off the bat and which receive negative reactions. Then after the test is over, ask follow up questions with your developer about where they felt most confused and experienced greatest difficulty.<\/p>\n

Team Feedback & Fixes<\/h3>\n

Usability tests are meant to pinpoint issues or potential problem areas, but they don\u2019t always generate solutions. This is why teamwork and further discussion is required to flesh out the best solutions for individual problems.<\/p>\n

Here are five UI\/UX ideas to keep in mind regarding usability 101<\/a>:<\/p>\n

 <\/p>\n