Wireframe Wednesday

Free iPhone UI Template | Envis Precisely

Wed, 22 Feb 2012 08:44:00 -0800

Today we have some fresh iPhone UI Sketch Templates from our friends over at Envis Precisely. Templates are free to use. Enjoy!

Permalink | Leave a comment »

Introduction to wireframes | Joel Laumans

Wed, 15 Feb 2012 09:39:00 -0800

This presentation from Joel Laumans was an introduction to wireframes for first year students of interaction design at University of Applied Sciences Rotterdam.

Permalink | Leave a comment »

4 Strategies for Working With Designers Without Killing Each Other | UX Magazine

Wed, 08 Feb 2012 09:53:00 -0800

Fourteen years ago, in my first job where my title was “Information Architect,” I clashed with a designer. We were working at a large advertising agency that was known for stunning design work. The art directors wielded a level of power at the agency that I have never seen anywhere else, and the result over the decades was a portfolio of gorgeous print and TV ads. The design-first method had worked well for this agency, winning them awards and a long roster of Fortune 500 clients, so they naturally decided to use this approach in their newly launched web department, too.

Things went well for a while, until I attended a kickoff meeting for a new website project. The designer came to the meeting with an already completed graphic design, before any information had been provided about who the site was for or what it would do. This designer had been at the company longer than me, and she had been happily designing sites without an information architect for several months. As far as she was concerned, this was a process that worked well for her, and why shouldn’t it? She had complete control of the site, her designs looked lovely, and they were not in any way influenced by user needs, site goals, or reality.

What followed was a long, drawn-out battle for control of the site between me and the designer. This battle usually sounded something like this, played out again and again:

Me: And when you click on this button where does it take you?
Designer: I haven’t worked that out yet, but it’ll be fine.

At the time, I thought I had encountered a particularly obstinate designer, but in fact I had just bulldozed my way into the biggest challenge in information architecture (IA): navigating the line between beautiful design and usable IA. Because this was early in the web world, the agency had yet to learn about this balance between usability and design, and I hadn’t either. And in the intervening years, things haven’t changed much. Designers still want to make things beautiful, UXers still want to make things usable, and those two goals are frequently at odds. What has changed for me, though, is the approach I now take to working with designers.

1. Get the Right Designer on the Project

We don’t always have the luxury of selecting the designer who will bring our wireframes and prototypes to life, but on occasion this happens. All UXers should have a roster of designers who are UX-friendly who they can call when the opportunity arises. More and more frequently, I have clients who either ask us to handle design or ask for designer referrals. When this happens I always feel like I’ve won the lottery. I have a collection of designers I’ve met over the years who are great at working with highly functional sites; if you have the opportunity to influence the designer selection, you need to be ready to jump in with names and portfolios.

2. Don’t Just Throw Wireframes over the Fence

Last year, I worked on an unusual project where the timeframe was so compressed that there was no time for wireframes. Instead I spent many, many hours each day on the phone with the designer discussing the interface, working out where each element should go and exactly how it should function. While I wouldn’t recommend this process as a rule, the end result was a beautiful working relationship and an interface that we were both thrilled with.

Many agencies are structured such that designers are just handed a stack of wireframes and told to execute on them. The end result tends to be either a site that looks like a very pretty version of the wireframes, or one that is only very loosely based on the UX design. To strike the right balance that prevents designers from either taking an overly literal interpretation of wireframes or from developing their own new interaction models, designers need to be involved early and often. As soon as you’ve got a few wireframes done, pull your designer in to start mocking up a visual design so you can work together through anything that needs to be rethought.

3. Give Designers Space to Do Their Thing

People go into design because they want to express their creativity, to play with shapes and color, and to have fun doing it. In some ways, information architects just come in and rain on designers’ parades by imposing structure and preferring the obvious over the unique. But there are designers out there—more and more all the time—who look forward to working with information architects because working off of wireframes makes their jobs easier. These designers still want to play and have fun, and (in the right place and time) new and interesting designs and interactions can make people happy, so it’s a good idea to include a design-centric section on sites that warrant it, where the information architecture takes a back seat to the design. This works for areas of a site that needs to provide a visceral feel for a brand, or portfolio sections of sites that need to showcase work or case studies. If you respect the designers’ need to create something beautiful, they are more likely to respect your need to create something usable.

4. Don’t Discount the Importance of Design

It’s important to remember, as Don Norman has famously said and Dana Chisnell recently reiterated, that beautiful design makes people happy. Good UX design is the backbone of good visual design, and one cannot exist without the other. Back when I was engaging the designer at my first IA job in thermonuclear warfare, I did it because I only barely registered design as something that mattered to the user experience. But the joy inherent in beautiful design is important as well, so sometimes when a designer overrides your UX design on aesthetic grounds, the designer is right. UXers need to weigh the pros and cons of all design decisions very carefully in order to determine where visual design should triumph over UX design, and vice versa.

There are still struggles, of course, and there are projects where designers want to go one direction and the UX team wants to go another. But I do seem to encounter fewer and fewer all-out wars between design and UX teams. When designers and UXers work well together, the ultimate winners are the users, who get a product that is not only easy to use but lovely to interact with.

via uxmag.com

Hana Schank for UXMag on strategies to avoid team clashes when working on a web project.

Permalink | Leave a comment »

Wireframing for responsive design | Boagworld

Wed, 01 Feb 2012 03:40:00 -0800

I’m conscious that some people in the web industry, including myself(!) may be getting tired of hearing the word ‘responsive’ in everything they read. We shouldn’t be, because I don’t think it’s going to change any time soon (not until the next big web paradigm shift at least) and mobile will only become more important as time goes on and the device numbers grow and they technology evolves.

Get used to it. We, the content designers, have to be just as responsive as the interfaces we create, adapting to change as it happens. To do this we need to learn to think differently.

Responsive thinking

We now have to design and think responsively. Our layouts and our pages need to gracefully fit the device they are being viewed on. Whilst they don’t necessarily have to be perfect in all browsers across all devices, they do have to look good and present a better user experience when compared to pinching and zooming a mobile browser rendering our pages at desktop size. With statistics on mobile browsing indicating that more people will soon be accessing the web from mobile than from desktop, we have to think carefully right from the beginning of any new site we design.

This presents a new challenge. If we are going to wireframe our site designs, then we need to think and therefore wireframe them polymorphically, i.e. they will change shape in different situations. As we consider and add elements to what is basically the blueprint for our design, we have to ensure that everything can morph gracefully to higher and lower resolutions. Changing layout as necessary, making use of wider resolutions more effectively and possibly omitting some of the content altogether at lower resolutions (a last resort of course).

Therefore, if we wireframe this…

then we really need to also show this in our wireframes for a portrait 768pixel wide table view:

down to this on a mobile phone portrait width:

We can’t just make assumptions about how the site will adapt and leave clients in the dark about these decisions as we continue development regardless.

Mobile first

We can’t continue to think through the wire framing process from a blinkered desktop perspective. It’s not going to be easy though. Many of us spent years advocating fixing width or maximum 960px width designs. The thought of our previously rigid designs suddenly being unbuckled and able to jump around and change layout can be unsettling.

Really, we need to start our wireframing from narrow widths outwards, or ‘mobile first’ ensuring that we can serve our content to the lowest common denominator and expand on this progressively as more resolution becomes available to work with on wider screens.

From now on we need to mentally deconstruct our site as we create our wireframes, mentally breaking it down into columns and elements that can not only exist side by side, but also above and below each other. There is no fixed interelationship any more. By starting with narrow screen devices we can ensure we solve narrow width problems first rather than running into them later on when time may be short.

Design constraints

Try as we might, there is no getting away from the fact that responsive thinking challenges our design options and certain approaches will not be as easy to implement as easily as others. Strong grid designs morph more readily as we down-sample the grid to single columns more easily than a more organic design. Also, even numbers of columns provide easier wrapping options than odd numbers of columns. For example, expanding a single column narrow site to a wide design with 5 columns could present more of a challenge than a design which expands to 6 columns. A 6 column design allows column steps of 1 X 6, 2 X 3, 3X2, then 6 X 1 columns… whereas a 5 columns would be uneven – 1 X 5, 5 X 1 with no even steps in between. Of course, we have every opportunity to switch our grid at different breakpoints, but this inflicts a further development overhead.

Wireframing compromises

If our desktop layout has a major call to action in the right hand column, where the middle column isn’t actually as important as either column 1 or the call to action:

is it necessarily right that we mechanically do this?

This may be the natural response of stacking columns left to right and this may be the result if there is little thought applied to how things transpire in a narrow resolution. This may be a more appropriate solution:

In addition to considering it ourselves and any html consequences of moving content around at different breakpoints, we also need to demonstrate to our clients that this has been thought through during the architectural process of the site design and not just arisen as a consequence of changing the layout. Thinking through the best way of presenting a site is more important than the practical considerations of swapping content with media queries.

Compromises are inevitable

In the example above, what if the call to action element was an advert? Will advertisers consider that it’s position at the bottom of the page content be as prominent as it was before? Again, we need to decide in collaboration with the client and demonstrate on the wireframe how everything will appear and agree on the inevitable compromises that must occur. Advertisers will undoubtedly be much happier with this situation:

Conclusion

There is no getting away from it, to show a complex website on a narrow screen device such as a mobile, there will have to be compromises. If comprises aren’t made in the content (i.e. we are still giving the whole site without removing content), then compromises will inevitably occur in positioning of the content. On a mobile page there are really only 2 hot areas, the header and the footer, both of which will need to carry important navigation options for our site. Everything in between is fairly equally weighted. Let’s hope noone ever starts referring to the ‘fold’ when it comes to mobile, or things are going to get very complicated indeed.

Whatever our solutions, we need to quickly wireframe our intentions to demonstrate both to our clients and to ourselves that we are thinking mobile first, ensuring that width problems are all solvable from the outset and that as we scale our wireframing upwards content can neatly and evenly adapt to fit desktop widths.

via boagworld.com

Leigh Howells takes a close look at wireframing for responsive design.

Permalink | Leave a comment »

Sketches and Wireframes and Prototypes! Oh My! Creating Your Own Magical Wizard Experience

Wed, 25 Jan 2012 08:33:00 -0800

Why is every conversation about wireframes I’ve encountered lately so tense? For instance, at a recent UX Book Club meeting whose topic was a discussion of some articles on wireframes, the conversation moved quickly from the actual articles to the question of what a wireframe even was. What the discussion came down to was this: no one knows the answer, and trying to find it feels like a wild-goose chase—or like wandering off on our own down a yellow brick road to find the all-knowing and powerful Oz to figure the answer out for us.

The Wizard of Oz asks questions like: What is courage or heart or a brain? Who should define them for us? As I see it, UX design suffers from similar definitional issues. We don’t all mean the same thing when we say sketch or wireframe or prototype. So how can we all get on the same page? There are differences between a sketch, a wireframe, and a prototype, but how can we understand the distinctions and the best use of each? And what is their value as communication vehicles? Let’s discuss what separates a sketch from a wireframes from a prototype.

Sketches

“The intention of sketching is to separate design from the process of making.”

Sketching and design emerged during the medieval period, so these concepts are nothing new. However, what I believe many people forget is that the intention of sketching is to separate design from the process of making. In the context of design, sketching is rapid, freehand drawing that we do with no intention of its becoming a finished product. In fact, many times, sketching is only a foundation upon which we can overlay our actual design work. Thus, sketching is a tool that supports the process of making, not the actual design itself. Unfortunately, it’s all too easy to forget this fact in our quest to get to an end product. We sometimes hold onto our sketches like they are the be-all and end-all of design. Sketches should be

quick—Making them does not require long periods of time.

timely—You can create sketches on demand.

inexpensive—Creating them is cheap, using materials you have on hand.

disposable—You don’t care if sketches get thrown away.

plentiful—Sketches don’t exist in isolation of one another.

clear and use a common vocabulary—Sketches comprise simple symbols and lines.

fluid—They have a fluidity of line and flow that imply creativity.

minimally detailed—Sketches are conceptual and suggest structure.

appropriately refined—They communicate just enough so others can understand your intent.

suggestive and exploratory rather than confirming—When sketching, you haven’t yet made any concrete decisions.

ambiguous—You have yet to work out the details, then overlay your design on the foundation your sketches provide.

Wireframes

“A wireframe’s purpose is to communicate and explore the concepts that come out of sketching—that is, those concepts you actually want to pursue further during user interface design.”

A wireframe, in comparison, is a basic visual guide we use to suggest the structure of a Web site, as well as the relationships between its pages. Wireframes come long before we do any visual design. A wireframe’s purpose is to communicate and explore the concepts that come out of sketching—that is, those concepts you actually want to pursue further during user interface design. Wireframing lets us outline a Web site’s basic, overall structure and flow and helps us explore divergent ideas from our sketches. I like Will Evans’ definition of wireframes in a recent article called “Shades of Grey: Wireframes as a Thinking Device.” He says, “for me, wireframes act as a form of thinking device for the setting and exploration of a given problem space.”

You’ll see there isn’t much change from sketch to wireframe—merely a slight refinement and greater formalism. Our initial drafts of wireframes remain tools or artifacts that we use during the process of making to aid conversations as design moves forward. Wireframes should be

quick—Making them does not require long periods of time, but they do take longer than sketches.

inexpensive—Creating them is cheap, using materials and tools you have on hand.

viable—Wireframes are not as plentiful as sketches, so you should have narrowed your concepts down to viable options.

clear and use a common vocabulary—Wireframes comprise simple symbols, lines, and indicators of interactivity.

minimally detailed—They are conceptual and suggest structure.

appropriately refined—They communicate a sense of structure and layout.

confirmatory—Wireframes present concepts that need validation. When creating wireframes, you still haven’t made any concrete decisions.

ambiguous—You have yet to work out the finer points of interaction and content.

Prototypes

“Our designs are still not final, but we have defined a set of ideas we know can actually be pursued, and we begin to refine and exemplify them.”

As we iterate our wireframes and get clarity on requirements and constraints, some of our ideas naturally fall away. It is at this stage I would say a real prototype exists. Our designs are still not final, but we have defined a set of ideas we know can actually be pursued, and we begin to refine and exemplify them. We may invest some light coding in them to achieve a degree of interactivity, but a prototype is still a communication tool and artifact. Prototypes should be

quick—They should require only minimal development effort.

inexpensive—The development they require does not require a major investment.

clear and use a common vocabulary—Prototypes comprise simple symbols, lines, interactive components, and content.

detailed—Prototypes include content and interactivity.

appropriately refined—They represent an almost real application—though with a faked user experience.

validated—In prototypes, a design is no longer ambiguous or suggestive. A prototype is an actual instantiation of an idea. However, it may still require fine tuning.

Understanding the Continuum

“There is no clear boundary line separating these design artifacts….”

Now comes the tricky part: deciding when a sketch stops being a sketch and becomes a wireframe, then a prototype. There is no clear boundary line separating these design artifacts, which is probably what makes our conversations about them so contentious and hard to articulate. In Bill Buxton’s book, Sketching User Experiences, he provides some descriptors of sketches and prototypes that ring true with me (see Table 1). They elicit the feelings the ends of the continuum should embody.

Table 1—The Sketch to Prototype Continuum, from Sketching User Experiences

Sketch Prototype

Evocative

Didactic

Suggest

Describe

Explore

Refine

Question

Answer

Propose

Test

Provoke

Resolve

Tentative

Specific

Noncommittal

Depiction

In Figure 1, I’ve attempted to articulate a Sketch to Design Continuum visually. This illustration depicts the relationships between a design’s level of commitment and fidelity and what you are trying to communicate. These are the factors that matter when deciding where you are in this continuum. While the lines demarcating sketches, wireframes, and prototypes aren’t clear, the phases of ideation, concept validation, and refinement and usability are—and that’s where we should focus our attention.

Figure 1—The Sketch to Design Continuum

Sketches or wireframes support ideation and concept validation, while wireframes or prototypes are important for refinement and usability testing. When we are exploring and validating our divergent design ideas, a lack of commitment is important and beneficial. This allows us to be more flexible in our iterations and, therefore, more creative. As we start to whittle down our design options and refine those that merit further exploration, we need to start articulating them in a more realistic manner, so everyone on a product team can participate in the design conversation with the same understanding. This is why it’s more important in later phases to create wireframes or prototypes.

There are also clear differences in the communication that happens during each phase that help distinguish which artifact is the best vehicle. And lastly, you can see that the amount of iteration that occurs gets smaller and farther apart as we move toward the ultimate design. This is a natural progression as divergent ideas converge in an actual solution.

Why the Differences Don’t Matter If You Get the User Experience Right

“The reality is that wireframes are a design artifact—that is, a tool that facilitates the process of making that leads to design.”

We often consider our wireframes as deliverables, or final products, but this just isn’t the reality. This can be a tough lesson to learn. I know I’ve already spent a lot of time deciphering the semantics, but we couldn’t have gotten to this point without having first cleared some of that up. The reality is that wireframes are a design artifact—that is, a tool that facilitates the process of making that leads to design. Buxton says the lesson The Wizard of Oz teaches us is that, if we can do an effective job of following the example of the Wizard, we, too, can conjure up systems that let the people who use our products have real and valid user experiences, before any system exists in any real sense of the word. Keep the following in mind:

It is the fidelity of the user experience, not the fidelity of the sketch, wireframe, or prototype that is important from the perspective of ideation.

We can use anything we want to conjure up such user experiences.

The earlier we create such design artifacts during the product development lifecycle, the more valuable they generally are.

It is much easier, cheaper, faster, and more reliable to find a little old man who can create the illusion of wizardry with a microphone and some loud speakers than it is to find a real wizard. Fake it before you actually build it.

Think about this: Developers never actually implement a wireframe as it is—or, at least, I hope they don’t! That doesn’t diminish the importance of wireframes by any means. Creating these artifacts is critically important to a successful design process that leads to a successful product. Let’s just remember the purpose of these artifacts. As Will Evans says, “I use my sketches and wireframes as [a] means to make explorative moves and assess the consequences of those moves. As I explore the problem space, I could relatively easily keep the design models in my head, but I would fail in my primary objective to create a framework for a conversation among the stakeholders, the intended audience, and me.”

The Rehearsal to Production Continuum

“If we treat our sketches, wireframes, and prototypes as what they are—artifacts of the design process—we can see the whole process as nothing more than an iterative rehearsal process.”

If you’ve read any of my other columns, you are probably wondering where the theater is—besides the example of The Wizard of Oz that is. This time, I felt the need to clear up some preliminary points before getting to any theatrical analogy, but here it is: if we treat our sketches, wireframes, and prototypes as what they are—artifacts of the design process—we can see the whole process as nothing more than an iterative rehearsal process, as shown in Figure 2.

I keep coming back to an idea that I first discussed in my column “The UX Designer’s Place in the Ensemble” and again, in more detail, in “Putting Together a Production: A Rehearsal Strategy for Design.” As I said in that second column, design is not a linear process. Rather, like rehearsal, design is a process that has

an iterative cycle

distributed, independent, simultaneous invention

unifying action

a director who facilitates

a forum for conversation

a way of establishing structure—in design, the design artifact

Figure 2—The Rehearsal to Production Continuum

Looking Beyond a Single Production

“Rehearsal is just one example of how theatrical productions know how to articulate and separate the process from the product.”

Rehearsal is just one example of how theatrical productions know how to articulate and separate the process from the product. Looking at a bigger picture than any actual, individual theatrical production, there are other parallels to the concepts of sketching, wireframing, and final design in some types of theatrical productions as well.

For example, a sketch is like a staged reading. A staged reading is very much what it sounds like. The actors get up on stage, with almost no rehearsal and no memorization, and run through a show with script in hand. There is no production and minimal, if any, blocking or prep time. A staged reading is a creative experiment in a realistic setting, with an audience that provides feedback. It never turns into anything more, and a theatrical group usually performs it only once. Similar to a quick sketch that you can dispose of later, a staged reading is a tool that lets you talk about a story and its concept with an audience.

A show in a black-box theatre, which seats less than 150 people, is not much more than a prototype or proof of concept. It is a performance that occurs in a small space and has minimal production or technology. The people producing it have narrowed down their ideas, and the content and interactions are there, but they have undertaken no major development. We expect a performance that feels real, and such a show is much like a fully produced show, but its run is short lived, lasting only a few weeks at most.

A Broadway show, on the other hand, is a fully developed product. Lots of work, technology, marketing, and money have gone into it. Shortly before opening night, you can do only minor testing to tweak what is essentially a finished product—similar to doing usability testing at the end of a product development cycle—because big changes would be both difficult to do and expensive. This is the kind of production that runs years—or maybe even decades for a show like Cats.

Become Your Own Oz

“Whatever we call them, all three of these design artifacts are relevant when we use them in the right phase, for the right purpose.”

Ultimately, I do feel the conversation at our UX Book Club meeting was a good one. It’s nice to get a handle on the perceptions and semantics that are out there and understand what the issues really and truly are. Whatever we call them, all three of these design artifacts are relevant when we use them in the right phase, for the right purpose. But, to make the right decisions for your own projects, you need to become your own Oz. Create design artifacts that adequately define a user experience to help you get good answers to your design questions. When we use these tools as communication vehicles during the design process and understand that they are not themselves the end product, they can help us to design successful products.

Sketch	Prototype
Evocative	Didactic
Suggest	Describe
Explore	Refine
Question	Answer
Propose	Test
Provoke	Resolve
Tentative	Specific
Noncommittal	Depiction

via uxmatters.com

This article was originally posted over at UXmatters by Traci Lepore. The title already tells, Tracy is comparing three tools: sketches, wireframes and prototypes.

Permalink | Leave a comment »

Visualising the User Experience

Wed, 18 Jan 2012 11:02:00 -0800

via slideshare.net

Great slidedeck by Grant Robinson, Senior Designer at Xero, from his talk at Web Directions South in Sydney Oct 2009.

Permalink | Leave a comment »

A simpler and faster alternative to wireframes | SachaGreif.com

Wed, 11 Jan 2012 08:22:00 -0800

Photo credit: Josh DiMauro via Flickr

I recently explained why wireframes can hurt your project. My point was that in a lot of cases, you can save time by designing in Photoshop straight away or using a HTML prototype to flesh out your app. But some people rightly pointed out that wireframes were a better tool for sharing information in a way that’s approachable to people without design or coding skills.

Although that’s a good point, in my opinion there’s a better, faster, and easier way to accomplish that goal: prioritized lists.

Wireframes: an evil force of destruction and despair?

Goals and elements

It’s an extremely simple technique, and you don’t need any special kind of software to do it. You can do it inside a plain old email, and here’s how it works. For each page, make a list of all of that page’s goals and elements.

A goal is the reason that page exists in the first place. For a homepage, it could be something like “make people sign up”. For a support page, it could be “make it easy for people to contact us”, or maybe “route people through the right support channels so they don’t need to contact us”. You goal list should generally have between 1 and 3 items. Any more than that and it means your page lacks purpose and will not be effective.

And an element is simply anything that appears on the page: buttons, navigations, taglines, forms, etc. Your element list should include between 5 and 10 items, depending on how thorough you want to be. For example, it’s usually not very useful to list every single navigation element as separate items, and you can also omit basic elements that already have a fixed location like the logo or footer.

A call-to-action button on Zendesk.com

Once you have your two lists, sort everything in three buckets: Most Important, Important, and Secondary. Your “Most Important” bucket should not have more than 1 to 3 items, otherwise it’s a symptom of an unfocused page. Your “Important” bucket will usually have about 4-5 items, and the “Secondary” bucket simply contains all the other stuff.

Focusing on content

The advantages of this technique over traditional wireframes are two-fold: first, it’s quicker and simpler to do. But the other big advantage is that it encourages people to think in terms of goals and content rather than layout. Removing the layout from the equation completely means that all design decisions will belong to the designer when it comes time to create a Photoshop mock-up or a HTML prototype, and those decisions will be much more meaningful at that stage.

An example: Zendesk.com

Since the easiest way to learn is by studying a concrete example, let’s pick a site (for example, the great Zendesk.com by the fine folks at the Cuban Council) and apply this technique retroactively.

The Zendesk.com homepage

Goals

Get people to try the service

Elements

Most Important

“Try it free” button

Tagline

Important

Main navigation (home, pricing, customers, your)

“What is Zendesk” paragraph

Companies using Zendesk

Secondary

Secondary navigation (contact us, resources, login)

“Close your customer loop”

“Register for live webinar”

“Your guide to selecting help desk software”

That’s it! Of course, coming up with that list in the first place takes some time and effort, but it’s still a fairly quick process compared to whipping up a wireframe.

You’ll notice I left out some elements. For example I didn’t mention the homepage screenshots illustration at all. That’s because this kind of graphics is there to support your message, but it’s usually not the message itself. At this stage of the process, you probably won’t know what will work best yet, and that kind of decision is best left to your designer.

I hope you’ll get a chance to try this technique for your next project, and be sure to let me know how it worked for you.

via sachagreif.com

Sasha Greif just recently published this follow up on his article "Why wireframes can hurt your project". With "A simpler and faster alternative to wireframes" he introduces a technique that prioritizes content and focuses on goals and elements before a Photoshop design or HTML prototype comes into play.

Permalink | Leave a comment »

Repeat after me: wireframes are not visual design - thinkUX

Wed, 21 Dec 2011 09:28:00 -0800

Over the years I have perfected a special skill. It goes like this:

I send out wireframes for review and feedback. These may be low fidelity sketches or high fidelity interface mock-ups. Whatever they are I send them out for comment because I believe in a collaborative process.

I compose the email, explain what wireframes are and how they are not indicative of actual design etc. and press send. Then I wait...
And here is where my special skill comes in because I sense what is coming next. It's inevitable. At some point - typically within the first 15 minutes - a colleague and/or client is going to come back and write the following:
"These are good but it would be great if you could add more colour."

Figure 1: Spot the difference, one is a low fidelity wireframe the other is a visual design

Obviously at this point I smile/sigh to myself in despair. It doesn't matter how many times I iterate the purpose of wireframes and how they are differentiated from visual design by their very nature and concept, people still misinterpret their purpose.

In some ways I understand this. It's human behaviour. People think visually and so they are cognitively pre-conditioned to think that a wireframe is intended to convey design. They see the broad outline of an interface and rather than focus on perhaps the interactive elements and the mode of navigation, they think about copy and imagery and of course, colour. But here is the crux of my argument.

There is design and there is visual design - in this context the two are very different. The visual graphical layer should come much later in a product's development - it's the skin that brings a product to life but it is not the element that will define:

What elements rest on each page

How the navigation and link metaphor works

How you can cross-sell content/products to users

These attributes are some of the types of things that the wireframes define. They are as equal in importance to the look and feel but theyare a completely separate element altogether.

There is often a lot of debate in the IA professional network - some think wireframes are not a part of design at all, and others fervently disagree. It's a messy area. My take has already been explained. If you search the definition of design you can plainly see that wireframes fall into the idea of "specifiying an object intended to accomplish goals in a particular environment". A technical definition that can be roughly translated as a roadmap of how something is going to interact with your users.

That's what wireframes do. By implication then they won't tell you what colour palette to use. How to brand your product visually. Nor will they tell you what colour to make the links and what treatment you will need to apply to images. That's not an information architect's job. That's a VISUAL designer's.

I am sure you, reader, know what I am on about. If you work as an information architect I am sure you have some stories of your own to share on this matter. Either way, I think this rant has cleared things up and I feel good about getting it all out in the open.

I will step down from my soapbox now.

via blogs.msdn.com

Amir Karim, User Experience Architect at Microsoft elaborates wireframes.

Permalink | Leave a comment »

The Right Way to Wireframe

Wed, 14 Dec 2011 09:24:00 -0800

via youtube.com

The right way to wireframe by Russ Unger. #rwtw

Permalink | Leave a comment »

Design/Content Workflow

Wed, 07 Dec 2011 06:35:00 -0800

via media.smashingmagazine.com

Image credit: Chris Depa, Straight North

Permalink | Leave a comment »

Why Sketching And Wireframing Ideas Strengthens Designs | SpyreStudios

Wed, 23 Nov 2011 09:57:00 -0800

Additionally, sketching helps us change our ideas to make them more reasonable where they can become a reality, and gives us a general outline when we bring our design ideas to say, Photoshop.
Great design ideas should always be sketched out to be better formulated and somewhat finalized before brought to the digital world. Great design ideas should always be sketched out to be better formulated and somewhat finalized before brought to the digital world. This helps us develop on our design idea, which actually helps us provide a better end result or product, than that of whom did not sketch the idea.
Therefore, eliminating sketching as a process of gaining experience is not a valid point as you are eliminating a crucial process in design that can sometimes make or break a project. To better prove the point on how sketching can strengthen your design ideas, we discuss several benefits to sketching out our designs before making them a reality.

Eliminates Time Wasted

One obvious factor or benefit of sketching your design ideas is that it eliminates time you could have wasted.

You may be wondering how sketching can eliminate wasted time while you could simply start right into Photoshop or Fireworks. You have a valid point; however, even the greatest ideas need refining. Sketching enables you to plan before actually starting to design. You can solve a lot of UX and design problems by sketching ideas on paper prior to firing up your preferred design software.

What this means is, spending the time to sketch your idea on paper will actually help you visualize your idea better than you would when you imagine it.

It allows you to get a better overlook on how it will turn out, and if you do not like how the design idea is turning out on paper, or the idea may not be reachable or feasible, you have not spent the time actually bringing it to life in Photoshop, but rather just a half hour throwing it on paper.

Therefore, a not so great idea will not waste hours out of your day just to realize that it will be heading straight to your trash bin.

Helps Expand on Our Ideas

Whenever we imagine ideas, they are usually the skeleton of what the end result can be.

However, when you take an idea directly to Photoshop, you do not quite have the brainstorming you would if you brought it to paper to expand on it, and thus great ideas are often suppressed and lost, making your great idea turn into an exceptional idea or design.

However, by bringing your designs from mind directly to paper, it gives you a completely new and different level of how you visualized it, allowing you to expand on your ideas for the design often bringing it from exceptional, to a mesmerizing drool-worthy design.

Therefore, it is definitely worth the time and effort to sketch your ideas out before making them a reality.

Helps with Group Feedback

Let’s face it, when we spend hours and days and weeks bringing an idea to life in Photoshop, we are generally not open to major feedback that will attempt to overhaul all the work, effort, and time we have put into it to bring it to life already.

We would just reject credible and excellent feedback if it means we need to change a huge chunk of our design such as a structural change, or we would be forced to perform these major changes by a design firm, which causes delays in the completion of the design project.

However, when you sketch your ideas on paper or on a whiteboard, your group can provide feedback allowing you to bring changes to the sketch in seconds helping make your design an excellent piece of work in the end.

In fact, many new great ideas whether design or not are structured by brainstorming on paper first with their group before going forth and bringing some sort of prototype to life.

Increases Creativity

By bringing your design directly to Photoshop you are limiting your creativity as you are trying to follow the idea you imagined to get some sort of prototype completed before actually changing a few things around.

A sketch on paper acts like your design prototype for your idea or ideas. This allows you to quickly expand on it by using your creativity before actually bringing it into Photoshop or to the browser for a graphical preview.

This also happens to save you time from manipulating your prototype in a graphic editing program rather than on paper which tends to only take several seconds rather than several hours.

Design Evolution

One great thing about sketching out your design ideas is that later on you can look back and see how your design has evolved, from sketch, to prototype, to the final product.

This not only is just for personal satisfactory, but it actually helps you improve on your final product months down the line.

When we design websites, we tend to design them specifically for the content we need for that website at that current point in time, however, our sketches often contain different content containers before we scratched them out.

By going back and looking at our sketches when we are looking for ideas or how our design or designs evolved, it will actually help us bring the containers we eliminated into our current design if we decided we needed such containers or elements later on.

via spyrestudios.com

GrindSmart Magazine on idea strengthening with the help of sketch notes and wireframes.

Permalink | Leave a comment »

The Importance of Wireframes | Urban Insight Blog

Wed, 16 Nov 2011 10:31:00 -0800

Documentation, of course, is critical to defining and confirming your client’s needs, and it’s critical for providing direction to your design and development teams. As part of your documentation, wireframes provide visual conceptualization that cannot be captured in a text-only document.

At Urban Insight, when we kick off a new web development project the first document we produce is the formal Project Requirements Document. This starts as a working document and, in its final form provides the client-approved outline of project purpose, feature requirements, technical requirements and creative brief.

On the heels of the Project Requirements Document we begin development of the wireframes. Wireframes also begin as a working document, have two phases and serve two critical purposes.

To initially communicate basic content layout requirements to designers as input to the creative process

To subsequently provide specific detailed functional requirements to developers

Between these two phases of development, the wireframes will grow and evolve.

Input to the design process

As a major source of input to creative development, wireframes walk a fine line. They must illustrate content priority and content layout as it will best support the website’s business objectives, but beyond that they must not provide a specific sense of design.

It's important your designer feels that within the creative process he or she has the freedom to rearrange content items while maintaining their relative importance within the presentation. It's important that your client remains open to the various creative options that your designer presents.

At the end of the first round of wireframe development, your client
should be happy that the site will effectively communicate what it needs
to communicate, and that it will lead the each website audience into
and through the site as required.

As a wireframe developer, if you have creative sensibilities, this may be a difficult impulse to control. The first round of wireframes, however, should be a technical illustration. Save your thoughts on design for your review you’ll have with your creative team on content layout and creative requirements.

Home page wireframe as input to design process

Home page mockup from wireframe input and creative brief

Input to the development process

Creative development, of course, is its own phase. Once design is signed-off, the wireframe document will subsequently expand to illustrate the requirements for content pages and any further design requirements for those pages, and they will become the document for detailed page-by-page functional specifications and direction to the developers.

In the end, the newly launched website may not look a lot like the very first round of wireframes, but what’s important is that they trace the site’s evolution from content requirements to functional requirements and help to produce a website that is user-friendly, compelling and effective for the client.

Content page wireframe with functional specifications

Content page final implementation

via blog.urbaninsight.com

Kurt Rademaekers on the importance if wireframes.

Permalink | Leave a comment »

Back to the Future of Wireframes — Rainypixels

Thu, 10 Nov 2011 08:21:00 -0800

A year ago, I proposed the future of wireframes.

My proposal centered around relaxing the stranglehold wireframes have on layout decisions. Traditionally, the exact positioning of the different "boxes" of information has been in the information architect's domain. In other words, when a wireframe shows a featured article rotator above a sidebar of resource links, it is expected that the final site will have the featured article rotator above that sidebar of resource links. In fact, it is expected that all such boxes of information show up relative to each other as depicted in the wireframe.

There are several problems with this approach, but let's focus on the fundamental ones.

I Got 99 Problems

Despite how things turned out, nature intended the layout and the visual design of a site to go hand-in-hand. You pay a notable price when you decouple these two aspects of the design process: a price that generally manifests in the form of a design that's not very exciting.

In addition to the decoupling problem, there is the problem of lost opportunity cost. When members of a design team have cross-disciplinary skills—that is, when they are experienced generalists—you endure the opportunity cost of not maximizing the team potential if you decouple IA from the rest of the design process.

But finally, there's the question of responsive design: how does IA adapt to include responsive design?

I suspect that those who specialize in IA will argue for more wireframes: wireframes for every form factor. It may be a great way to inflate the project budget, but remember Biggie's infinite wisdom? In all seriousness, creating wireframes for the full responsive matrix isn't sustainable. It's counterproductive, and as Trent points out, it's unnecessary. It also compounds the decoupling and opportunity cost problems I mentioned earlier.

So, where does that leave us?

It turns out that the key to solving our dilemmas lies in our ability to address the source of all these issues: the issue of control.

Control Freak

For the most part, today's approach to IA is similar to architecture in the physical world: create an exact blueprint for what is to be built, and then build it.

This approach worked well when IA was emerging as a discipline in a time where designing for the Web was unchartered territory. It was a practical way to solve problems up front, control scope, and manage stakeholders. But times have changed, and while it's still necessary to know what you want to build up front, it isn't necessary to have it fully locked down. It isn't necessary for the IA to exert full control over it.

In fact, it's better to ease up on the control.

Fluid Information Architecture

As I proposed in The Future of Wireframes, information architects (or, whoever owns the wireframes for the project) can often improve the quality of a design drastically by relaxing their control on layout decisions. I introduced the concept of functional wireframes to illustrate this.

My proposal this year—something I'm calling "fluid information architecture" in the spirit of our times—is for wireframes to have less control over other aspects of information architecture, like responsive architecture for a site and functional copy decisions.

There are two major benefits to this approach. First, it allows responsive content choreography to happen downstream in a much better way. Secondly, due to the nature of the beast, it introduces a level of delightful unpredictability for our users. Remember, these are exactly the kinds of results we were hoping to gain.

However, the fluid IA approach brings an elephant into the room with it: if the information architect doesn't control the blueprint of the site, then why have the role?

This is worthwhile question, and I've found that the answer varies from project to project depending on scope and makeup of the design team. Sometimes, the answer is for the information architect to focus on other aspects of the process: identifying page-level information, determining relative priority of information (Allison House provides an excellent example), capturing page states, and so on.

But a perfectly reasonable answer is for the role of the IA to be combined with surrounding roles, like creative director, or front-end developer, as we did in the 10K project.

The 10K Apart Case Study

For those of you who haven't heard of the contest, the 10K challenges contestants to build the best application they can with no more than 10K (yes, kilobytes) of code. You can read about this year's contest here.

Among other things, I served as the information architect for 10K Apart. As you'll see, I drastically reduced the scope and influence of the IA role precisely due to the scope of the project, and who was on the design team.

I was fortunate enough to have the Paravel trio come on board to help design the site. This isn't a gratuitous plug. Paravel is on the top of their game in several areas of the design process—among other things, they create wonderfully laid out websites, and have cracked the responsive nut better than most. This helped me adapt the information architecture approach for the project, particularly in three areas:

Layout (zero control): I knew I could relax the control I exerted on layout in the wireframes. This is one of Paravel's major strengths, so I put layout in their able hands.

Copy (relaxed control): Copy, much like layout, can function as a focal point for the site aesthetic. I encouraged the Paravel team to experiment with copy in the context of the visual design.

Responsiveness (zero control): Paravel is pioneering responsive web experiences. It felt natural to leave the responsive architecture of the site up to them.

To fully illustrate my point, I'm making the functional wireframe deck for the project available for your perusal.

Download 10K Apart Wireframes → 1.4MB .PDF

As you can see, I mandated only one thing: page-level information. The rest was at Paravel's discretion.

Some things they chose to keep (like the entry form and the gallery layouts), while others they completely changed (the hero banner and layout of home page elements). The process was seamlessly fluid as becomes apparent in Reagan, Trent, and Dave's posts.

The resulting design—and I may be biased here—turned out to be functional and unpredictably delightful: http://10k.aneventapart.com.

Finally

It's widely accepted that the information architecture phase of a project can make or break the final experience. And this is true. But this belief rests on the assumption that control creates predictability. While this checks out in theory, we've seen how it quickly falls apart in practice.

Ironically, in practice it seems that creating predictably delightful designs isn't about exerting control. It's about judiciously giving it up. It's about identifying the right fluidity for the process and establishing the optimal flow.

via rainypixels.com

Nishant Kothary wrote a follow up on his last years article "The Future Of Wireframes". This time he looks back to what he proposed last year and takes it even a step further.

Permalink | Leave a comment »

A Practical Wireframe Primer - DesignM.ag

Wed, 02 Nov 2011 10:44:00 -0700

In the current design atmosphere , I hear the term wireframe being thrown around a lot more than it used to be. Over the last few years, wireframing is a process that has endured a lot of misunderstanding and has been become much more widely known as a software and web design methodology. I’ve begun to notice that the concept is warping and not for the better. This twisting of the terms is making it difficult for newer designers and students to understand the real application of the process.

Wait, whats the problem?

Recently, I gave a talk at a design school and I had a few students ask me about wire-framing and their mental model of it was pretty far off base. Their concept of wireframes included design, finalized layout, and a number of aesthetic decisions to name a few of the inappropriate things they considered part of wireframes. The worst part : they didn’t even want to do it. These students just knew it was a step they were supposed to do but didn’t understand why it was so useful. They just accepted it as step in the process and breezed through it to get to the fun look and feel parts. This was troubling to me. At first, I thought it may have been an isolated incident, but more and more I have been noticing that the workplace application of the process is suffering due to a bit of incorrect and popular saturation among clients, new designers, producers, product designers, etc. Wireframing is an essential step in the web design process and it would be a shame if up-and-coming designers did not learn to love it.

Wireframes are blueprints

It interesting that designers will understand that complex structures such as buildings or cars require careful planning and architecture but then take a similar ideas for the web industry and barrel into them with little or no planning. Granted, a website is not a car, it is still a substantially complex undertaking and leaving out careful planning and structure is the recipe for a lot of wasted time, work and money. I promise I’ll get to the practical implementations but first, part of the initial battle is making sure everyone understands what a wire-frame is and what it is for.

Use the metaphor

The blueprint is my favorite metaphor for wire-frames because no person thinks of a blueprint as a rendering of what the building will look like or uses it to make design or aesthetic decisions. It is purely a map of function, priority and information. Perhaps more importantly, no sane person thinks you can a create a building or car without a blueprint. That’s a healthy attitude.

Wireframing is not…

Before you begin to start using wire-frames in practical situations you have to know and be able to explain to clients, employers and colleagues what wire-frames are NOT for:

Wireframes are NOT designs
In fact, wireframes should be completely devoid of font choices, color, pictures, logos, etc. Most people think visually and it is extremely common to think that a wire-frame is a intended to convey design. It is extremely easy for a non-designer to think or act like wireframes reflect final designs or placements. Don’t confuse the function by putting visual distractions on your wireframes. Remind them: there is little visual fidelity, wire-frames are about working through functional issues and organizing information.

Wireframes are NOT final layouts
Another common belief about wire-frames is that the designer is just going to come in and lay a skin over the top of the frame and BAM! the site is finished. It is clear by the difference in many designers that it is nearly impossible to separate the final effective layout from the aesthetic design. But, that is a different stage and it can be stifling and disastrous to try and cling to a wireframe layout.

Wireframes are NOT prototypes
There is actually quite a bit of confusion between wireframes and prototypes. Its surprising since they are pretty radically different tools in the process. Simply, wireframes are for organizing information and prototypes are for evaluating interaction. While wireframes and prototypes can have similar levels of visual fidelity to the final product they are really completely separate steps with fundamentally different objectives.

Take the time to establish the basic goals and purpose for building wire-frames with your clients and teams. It will always get you off on the right foot.

Using Wireframes

As I mentioned, I have heard from a shocking amount of novice designers and students that they do not want to wire-frame, but they know they should. A few have even told me that they don’t see how it helps them. Absolutely, there is no reason to work within a step of the process if it doesn’t serve any purpose. Fear not, wireframing is one of the most purpose driven and useful pieces of the design process.

Let’s get practical…
In an effort to fulfill my previous promise and give a springboard for production application of wireframing beyond the conceptual : I am going to detail a few main aspects and purposes of wire-frames and give practical uses and action items that I have used in successful client situations.

Pure Usability

Wire-frames are one of the most effective methods to work through usability testing and ideas. Keep in mind, we are taking about usability NOT user experience. A common mistake is to think that Usabilty = UX. It does not. But, that’s really whole other discussion for another time. However, it is important to take away that usability is simply the measure of how easy it is to use a product. Which is a measure of function not design or experience. In a final production situation, sometimes it is difficult to separate the easy of use from the other elements that are at play in the overall experience. When you chose to attack usability while its out in the open you will not be distracted by other elements.

Practical Usability Tips:

Walk-through a conversion path : Map out every path that a user can take. Map how many steps and how if it is difficult for the user to get to where you want them to go.

Test system language : Does every member of the team from developer to client understand what the terminology means without explanation?

Map out user tasks : Using the wire-frame, go through each step that a user needs to take to complete a task via the information only. This can expose fatal site architecture issues early.

Check for error cases : Wire-frames are a great way of helping designers and developers prepare all potential error cases and be ready with custom, informative and helpful error messages. When you know exactly where each error came from, you can create a check-list to help return the user to a usable recovery in each case.

Detail Site Features

More often than not, clients, managers and product developers have an extremely macro approach to the design. In short, they don’t really have a specific list of features. They are more interested in the big picture and that is really a problem for designers and especially developers. Wire-frames are an effective method of matching every problem with an actionable solution. Many times , there are simple communication issues that arise between the verbiage being thrown around about what a feature actually does. By visually exploring and explaining the features it maps out the scope of work and gets everyone on the same page. You will be surprised at all the details that might have been overlooked or simply not considered.

Practical Site Feature Tips:

Do a deep dive on each feature: Don’t just use a box to communicate a feature like a photo gallery or map. Dive deep and list out each element that makes that feature work and where it needs to connect to the site map. Write notes on the specific connection and exactly how and where it gets its data from. The more specific you are, the more effective the list will be.

List out relative content limitations: Many designers overlook relative content limitations like text strings, amount of items, overall screen real estate , etc. No one expects exact measurements, but spending the time on wire-frames to determine the reason range and limitation of content allows you to plan for scalability. Discuss with the team and write down roughly how long a title will need to be, how many images will you have, will the content need to scale, and how much will it need to scale. You’ll thank yourself when you don’t have to go back to the drawing board in mid production. It seems superfluous, but you will be glad you have it.

You’ll thank yourself when you don’t have to go back to the drawing board in mid production.

Visualize Architecture

It can be overwhelming and mind-boggling for some members of a team to look at a site architecture when they are well…not site architects. Especially when projects become enterprise level or simply filled with content that site map and information structure will get increasingly complex and abstracted. The architecture is the underlying structure and in and of itself is heavily conceptual. Wire-framing is the first step and beginning to connect the concept of the information to a tangible product.

Practical Architecture Tips:

Illustrate Navigation: A tangible place to start when visualizing architecture is to visualize the relationships between the navigation pieces as well as the tiers of navigation. Wire-frame out the top level, secondary and local navigation systems and make sure to detail how they connect to each other. Explore what methods of listing or illustration are ideal for the information detailed in the site map.

Visualize Steps and Exits: Many times the screen design can feel disconnected from the overall site map. To make sure that no structural paths can lead to dead-ends or trap the user : An incredibly useful exercise is to use the wire-frames to compare to the architecture map and record on each screen, how the user can exit, proceed or move backwards. I recommend using Mind-mapping software such as Freemind.

Conclusion

This is only small primer on how wire-frames are an essential , powerful and time saving part of the design process. The practical action tips in this article are a springboard to build a useful wire-frame step in your development process. Many designers have the tendency to dive right into designing look and feel, cool features, and graphics. Take a step back and remember that websites and software are complex ( even the simple ones). Proper planning is not just a formality but the most important step you can take. Getting friendly with wire-framing will build awesome team communication and facilitate solid, professional and well-planned projects.

via designm.ag

Shawn Borskys article on the definition of wireframes. This is the article Brett Lutchman was responding to in a previous entry.

Permalink | Leave a comment »

The Role of Design in Website Prototyping

Thu, 27 Oct 2011 09:15:00 -0700

How to Think About Website Prototypes (for Designers)

In the past, I often would describe a website prototype as a plan for how a website works, not how it looks. While, in a sense, I still think that's true, I've come to realize that it's actually pretty confusing, don't you think? Especially since we go on and on about how sitemaps and wireframes are inadequate website planning techniques because they can't be experienced interactively, like a website. But a very big part of the web experience is visual! Every aspect of a website's structure and functionality is represented in some visual way by its prototype. With that in mind, it's much easier to see how the distinction between prototyping and design is fuzzier than I'd thought.

So, to better describe what exactly a website prototype is, I'd like to start by drawing a pretty simple analogy: Just as architectural plans use a consistent visual language to describe buildings, prototypes use a consistent visual language to describe websites. In both cases, there are many good reasons for the consistency part. Architects are trained to read plans and discern critical specifications from them that are later translated into three-dimensional structures. Likewise, website developers are trained to interpret prototypes and translate their specifications into functional code. You could say that the use of conventions make the plans look very similar, but that doesn't stop the results from being quite distinct.

Here's an example (FYI, it's going to involve a bit of scrolling):

See what I mean?

For designers, rather than seeing the prototype as a document that imposes limitations, I think it makes more sense to see it as one that enables creative freedom. Believe me, I'm not trying to spin this. To milk my architecture analogy just a bit more, imagine if blueprints didn't exist. Without them, it would be amazing if buildings were built at all, but it would be even more incredible if the ones that did remained standing! In the same way, prototypes provide a structure that ensures a website is even possible. No matter how great a design might be, if it's not possible, it's useless.

Essentially, what I'm saying is that a good prototype wants to support good design, not step on its toes. But I realize I'm going to have to get a bit more into the details of how prototypes communicate in order to build my case, so bear with me...

The Language of Prototypes

The first priority of a prototype is to accurately represent the information a website will contain. That includes structural information—like the hierarchy of pages and sub-pages that make up a website—as well as content, which includes everything from the words and images displayed on pages to the logic behind content relationships and other functionality. In other words, a prototype has a big, big job: communicating a ton of technical information that will be understandable to everyone involved in the project—the technical and the non-technical—without using technical language (or for that matter, even working at all). Let me explain...

At the time of this writing, sunrise is expected about 15 hours from now. Maybe if I'm still up then (working on this article, of course), I'll stop for a break and watch the sun come up. Buuuut, probably not. The reason I bring up sunrise is that it's a perfect example of phenomenological language, which is exactly the kind of language a prototype uses. If you speak prototype—which I hope you will by the end of this article—you speak phenomenologically, which is to say, you speak in a way that describes experiences. We know that the sun doesn't actually rise, but from our subjective vantage point way down here on Earth, it looks like it does. The Earth would have to be much, much smaller in order for us to experience its day-long spin. So, despite our modern enlightenment, we still say "sunrise" because it's a whole lot clearer (and less pedantic) than saying "the time in the morning when we've spun around enough to see the Sun again."

Prototypes describe what it will be like to use a website—that's the phenomenological part—in a way that satisfactorily engages and prepares the client, without confusing anyone with overly technical jargon. But that leaves one question: if the prototype doesn't use technical language, how does a developer know what to build?

The first thing you probably noticed is that the prototype is mostly gray. We do this intentionally just to make sure that nobody gets sidetracked by any aesthetic hang-ups—at this point, we're not interested in whether the prototype is pretty, just whether it works. The second thing you may have noticed is that the prototype looks like a website...well, sort of. The page is certainly layed out like a website would be (and, were this an actual prototype, you could navigate from one page to another), but some things are specific while others are generic. For instance, the main navigation has what look like specific page names in it, but other parts of the page have generic titles like "Blog Post Title."

These are the brass tacks of the language of prototypes. In general, some aspects of the site will be very specific, and the way the prototype describes them will reflect that. So, from the example, the main pages (and their sub-pages) are named, and though that doesn't necessarily mean those names cannot be changed once the website is built, they're probably not likely to do so very often. On the other hand, the blog post that is featured on the homepage is likely to change very often. By using generic language, as opposed to prototyping a specific blog post title, the prototype is communicating to the developer that the site should be built in such a way that the end user can add new blog posts and name them whatever they wish. Just like "lorem ipsum" dummy text generally means "text will be here," generic titles stand in for types of content that are meant to be editable.

The Structure of Prototype Pages

Here is where I think most of the fuzziness between prototyping and design comes in to play. Because the prototype must communicate the website experience (that phenomenological language again), it has to work like a website—which means you need to be able to click from page to page. But in order to work like a website, it has to look like one, too. That's why sitemaps—they don't look or work like a website—and wireframes—they look (in a Flatland kind of way) like websites but don't work like them—fail to communicate anything useful about, well, using websites. Where I'm heading with this is that since prototypes need to look like websites, they can't look just any way. The honest truth is that building a prototype does involve a kind of design.

The kind of design I'm talking about has to do with communicating the priority of information on a page—or, for short, information design. The prototyping process involves returning to two core principles over and over again with every information design decision that the team makes:

What is the purpose of the website, and

For whom?

The answers to those questions should lead to very focused pages with a clear sense of priority. This is often manifested in visual decisions, such as the relative sizes and positions of elements on a page or typographical details if the volume of information on a page warrants it.

Let me unpack this with another example:

I created these simple mock designs for my example prototype in order to make a simple point: Though the prototyped homepage has a very deliberate layout in which the information on the page has been clearly and intentionally ordered, the spectrum of possibilities for what the final website can look like is still wide open.

Both examples take many liberties with elements of the page, but neither remove essential information nor disrupt the order of the information in a way that fundamentally changes the focus of the page. The interactive slideshow element, which occupies about 3/4 of the horizontal space at the top of the page, is still the most prominent visual element in both designs, even though Option 1 has changed its size. The sign-up form is not fundamentally affected by being relocated, nor has the choice to limit the number of blog posts on Option 2 significantly altered the overall priority of blog content on the page. Aside from these specific layout choices, Option 1 and Option 2 represent very different creative directions even though they share the same prototype.

There's so much more to say about the interplay between design and prototyping—much more than this post can handle, I'm afraid. I adapted this from a longer article I published a few months ago called Prototyping for Designers, which has many more examples of information architecture decisions and how they manifest in later designs, so if this has struck your fancy I recommend checking it out.

>EXTRA: For web design tips, pick up Patrick McNeil's book the Web Designer’s Idea Book, which provides inspirational examples of winning layout, color, and style directions.

via imprint.printmag.com

Christopher Butlers interesting article on the role of design in website prototyping.

Permalink | Leave a comment »

Why you should do your homepage wireframe last | Content Here

Wed, 19 Oct 2011 07:55:00 -0700

When building websites, I always recommend developing the home page last because the purpose of the homepage is to highlight content within the site. You need build out the site so you have something to highlight before you build the homepage. Over the past year, I have started to realize that the same advice holds true for design. In fact, I now feel even stronger about that rule for design. Here are four reasons why.

A homepage wireframe doesn’t tell a whole lot.
Wireframes are helpful to express content structure and site functionality. When I look at a wireframe, I see a content model (what elements make up a particular type of content) and features (how the visitor interacts with the content — commenting, voting, sharing, related links, etc.). The home page is more of a summary. You don’t see that level of detail. The things that matter to a homepage (branding elements like font, imagery and palette) are not even captured in a wireframe. Talk about those things near the end of the project because you can make sweeping visual changes by editing a few lines of a style sheet.

The biggest functionality decisions are in the inner pages of the site.
Although you may think you have scoped the project during your requirements phase, the devil is in the details. How the functionality works will have huge implications on project cost. The sooner you have those conversations, the sooner you will be able to adjust budget and scope so you can spend resources cost-effectively. Leave those decisions to the end and everyone gets surprised … in a bad way.

Internal audiences care more about the home page than external audiences do
Let’s face it, if your site is like most sites, most of your traffic is coming from search engines and link sharing (Twitter, Facebook, etc.). If you have something worthy of your audience’s attention, Google is going to know about it and take your visitors directly there. The homepage doesn’t do much more than give a visitor something to look at when he doesn’t know where to go. The homepage is more about corporate vanity than serving audiences.

It is easy to get bogged down in political issues that have nothing to do with the functionality of the site.
While there is very little functional substance on the homepage, that doesn’t mean people can’t argue about it. If the homepage is treated as a symbol for what is important to an organization (which it often is), a design session will quickly degrade into a turf battle. Your designer will try to mediate, but there is no way he will be able to settle such a fundamental argument. Don’t waste time arguing in the beginning of the project when there is so much productive work to be done.

Unfortunately, I regularly meet resistance from designers who habitually begin with the homepage. I understand the temptation. On the surface, a homepage wireframe seems easy and uncontroversial. It is just a bunch of blocks on the page that stakeholders can privately fill with their imagination; there are no assertions on how major site features behave. But, from a technical design perspective, we don’t learn anything from the homepage wireframe. We can’t start thinking about content structure and end-user functionality that will have major implications in scope and planning. The longer we delay that work, the greater project risk.

via contenthere.net

Interesting input from Seth Gottlieb on why you should start with other pages first and wireframe your homepage last.

Permalink | Leave a comment »

Three ways to make your wireframes more useful | cxpartners

Wed, 28 Sep 2011 09:25:00 -0700

via cxpartners.co.uk

Steve Cables talk from UX Bristol on how to make wireframes more useful.

Permalink | Leave a comment »

Wireframes are indeed Design | IA|UX Designer

Wed, 21 Sep 2011 09:14:00 -0700

Shawn Borsky for DesignM.ag wrote an article entitled A Practical Wireframe Primer.

Although Shawn hits the nail on the head with most of his writing, one area of serious error is the fact that Shawn states that wireframes are not design.

I wrote a response in the comments section yesterday at about 11AM and my comment was not approved. Websites like DesignM.ag will usually do this sort of thing when a comment contradicts what the writer is saying; but more importantly when it makes the writer appear to be wrong. This is not my intention- I like agree with 85% of the article, just not this statement. If I had wrote “Hey nice article Shawn”, it would have been approved within 20 minutes. This being said, I don’t even think Shawn is the one responsible for moderating the article.

Anyways, here is my response to Shawn’s post that was not published in the comments section.

Here we are again.
If I had a penny every time IA and/or wireframes were defined online, I’d be rich.

My only real issue with this article is point #1 under the subtitle “Wireframes are not” which states:
Wireframes are NOT designs
In fact, wireframes should be completely devoid of font choices, color, pictures, logos, etc. Most people think visually and it is extremely common to think that a wire-frame is a intended to convey design. It is extremely easy for a non-designer to think or act like wireframes reflect final designs or placements. Don’t confuse the function by putting visual distractions on your wireframes. Remind them: there is little visual fidelity, wire-frames are about working through functional issues and organizing information.

This is simply not true.
Wireframes are by their very definition design in the truest sense of the word. I think the author here is confusing the concept of art with design (or graphics with design.)

Websters dictionary defines design as seen here: http://www.merriam-webster.com/dictionary/design

Wireframes are design. (If they weren’t, what are we doing here?)
Wireframes are not just a bunch of boxes and arrows that are used to justify a graphical elements after the fact (like most ad agencies would have you think).
When we wireframe we are designing an intended- proposed direction on which we will be building our foundation on.

Design is:
“Conceiving, planning & constructing a proposed, intended element for a specific purpose.”

Examples:
1. A chair was “designed” to withhold a medium body weight that allows the user to sit down.
2. The car was “designed” to transport us from point A to point B over extended distances.
3. The pencil was “designed” in such a way that it allows us to ergonomically place our hands around in order to write something down.

It doesn’t matter what the chair, car or pencil looks like in terms of esthetics. That comes later when we want to add a graphical element to the finished product.

Dictionary.com has 13 definitions for the word “design” and only 3 of them (points 8, 10 and 11) refer to design in artistic expression: http://dictionary.reference.com/browse/design

Make no mistake, when we as design professionals craft our wireframes together, we are indeed designing. This is very important to understand and appreciate as many of our fellow co-workers view wireframing as sketches and just a simple step to overcome so we can move on with the project. Even more of the general viewing public do not know or appreciate the craftsmanship, intelligence and thought that goes in to designing wireframes.

Design is not artsy-fartsy feel good graphics. I believe this is where the disconnect is with many inexperienced work professionals as they do not have a proper understanding of the creative design process.

Two of the best and most popular examples of design is the story of the Wright brothers:http://en.wikipedia.org/wiki/Wright_brothers who designed an aircraft of sorts to fly.
All the while displaying key components of the design process: Creativity, thought leadership, sketching, planning, constructing, etc.,… all the while designing a proposed object with an intended purpose for a certain outcome.

This design process can also be witnessed with the inception of my second example, the automobile: http://en.wikipedia.org/wiki/Automobile#History
Ferdinand Verbiest, Karl Benz, Henry Ford and a few others all followed and practically reiterated the design process as well.
Again, the automobile was designed with an intended purpose for a certain task in mind. The steering wheel was designed to provide direction, the seats designed to allow drivers and passengers to sit, etc.,

In all of this, esthetics came later, and we all know that the graphical layer is simply the eye-catching icing on the cake to appeal to the buyer’s emotions in order to make the sale.

Not to harp on the author here, I luv other components of this article which are spot-on, but IA types had better wise up to their craft and what it is that they’re producing. If we as designers don’t appreciate or understand fully what it is that we’re doing, nobody else will.

We are not simple wire monkeys placing boxes and arrows together in the early stages of a project.

IA types should be cutting-edge, business oriented thought-leaders who craft and design proposed intelligent schematics for a certain demographic to accomplish a certain task for a certain purpose for a certain outcome.

Design is creation.

via iauxdesigner.com

Brett Lutchman published a great article on his blog IAUXdesigner.com, elaborating why wireframes are indeed design.

Permalink | Leave a comment »

7 Reasons Why Wireframing Is Important In Web Design | Orbit Media Studios

Wed, 31 Aug 2011 07:28:00 -0700

Recently, I have been in a few meetings where we are working on developing a web site. In these meetings, it has been suggested that we skip the wireframe stage and roll right into what the site is going to look like, the design. This kind of thinking stemmed from the notion that the client would not understand what wireframes are and that jumping into design would get us one step closer to launch. This suggestion is a bad one.

First, let’s back up and talk about what a wireframe is. For those looking to build a web site of any size or shape, wireframes are the foundation on which to begin building. Wireframing usually comes after the site architecture has been determined by a site map or flow chart of the web-site’s pages and before the creative design phase.

There are 3 easy ways to describe a wireframe:

Wireframes are simple black and white layouts that outline the specific size and placement of page elements, site features, conversion areas and navigation for your web site.

They are devoid of color, font choices, logos or any real design elements that take away from purely focusing on a site’s structure.

We often say that they are much like a blue print to a home, where you can easily see the structural placement of your plumbing, electrical and other structural elements without any interior design treatments.

Here is an examples of what a wireframe looks like:

Simply overlooking this step in order to get to the look and feel is a huge mistake that would prove disastrous for any web site or any contractor building a home. To reinforce the importance of this phase in a web process, I have outlined seven extremely important reasons on why you need to wireframe.

1. Displays site architecture visually

A site map can be a bit abstract, especially ones that are very large. Taking the site map to wireframe starts the first real concrete visual process for a project. Wireframes turn the abstract nature of a flow chart into something real and tangible without distractions. This step ensures that all parties are on the same page.

2. Allows for clarification of web site features

In many instances, clients may not understand what you mean when you say “dynamic slide show,” “news feeds,” “google map integration,” “product filtering,” “light boxes” and hundreds of other types of features. Wire framing specific project features on a web site provides a clear communication to a client how these features will function, where they will live on the specific page and how useful they might actually be.

Sometimes you may decide to take out a feature once it is wireframed due to the fact that it just does’t work with what your site’s goals are. Seeing the features without any creative influence really allows a client to focus on other equally important aspects of the project and clarifies any expectations about how features will be executed.

3. Pushes usability to the forefront

This is the one of the most important points of the entire wire framing process. Creating wireframes pushes usability to the forefront in showcasing page layouts at their core. It forces everyone to look objectively at a web site’s ease of use, conversion paths, naming of links, navigation placement and feature placement. Wireframes can point out flaws in your site architecture or how a specific feature may work. And this is a great thing.

4. Identifies ease of updates

For clients who purchase a content managed web site this point is especially important. A wireframe will immediately identify how well your site will handle content growth. For example, if you only have ten products offered right now, but in six months you may have 100, you will want your web site to accommodate this growth without impact to the website design, site architecture or usability. Wireframes will identify these important areas of content growth.

5. Helps make the design process iterative.

Instead of trying to combine the functionality/layout and creative/branding aspects of the website in one step, wireframes ensure that these elements are taken in one at a time. This allows clients (and other team members) to provide feedback earlier in the process. Skipping wireframes delays this feedback and increases the costs of making changes because full design mock-ups must be reworked, not just simplified wireframes.

6. Saves time on the entire project

Wireframing saves time in a multitude of ways. Your designs are more calculated. Your development team understands what they are building. Content creation becomes much clearer. You avoid hacks later on in the process. Everyone from the web team, the agency and client are all on the same page about what the web site is supposed to do and how it is supposed to function.

7. Experience shows it works

Building a web site is a process. Wireframing is one of those parts of the web process that should not be skipped, just as you wouldn’t build a house without a blueprint, or live in it without decoration. Each step has an important place in a larger process.

via orbitmedia.com

This week it's Nick Haas with 7 reasons why you should consider wireframing before designing/coding a website.

Permalink | Leave a comment »

Wireframe or Interactive Prototype? | SoftwarePrototyping.net

Wed, 17 Aug 2011 07:49:00 -0700

We often talk about wireframe prototyping and rich, interactive prototyping, which are both powerful techniques for getting conceptual designs into a form that can be explored and expanded.

Where to actually use either approach, though, is something that would benefit from covering off here; a recent email from a reader reminded me that I’d promised to give some tips a while back and so, without further ado, here we go…

Wireframes

Leaving sketches and paper-prototypes to one side, Wireframe prototypes are the quickest way to explore a visual concept.

Wireframes are a little bit like the plans for a house; they represent the outlines without getting hung up on the actual implementation. It’s about deciding on the layout of a floor, if you will, without getting concerned with the colour of the carpet.

By limiting ourselves to essentially static designs, we have to gloss over a lot of the implementation detail. We won’t attempt to model how a dynamic panel works, or the validation on an order form. We will, however, be able to quickly create visual representations of designs for forms and pages with a minimum of fuss. We’ll be able to do it quickly, and because our tools don’t attempt to let us do anything particularly complicated (such as navigating between wireframe ‘pages’), we won’t get distracted as much and can focus on our designs.

Wireframes, then, are ideal for the earlier stages of requirements prototyping, when there are layouts and ‘broad-stroke’ design choices to be explored.

Wireframes are suitable for:

Deciding on what things should be included in a page;

Investigating where things should be placed on a page;

Creating low-fidelity mock-ups to help build the ‘skeleton’ of an application without investing too much time;

Comparing and contrasting different layouts;

…and so forth.

What Wireframing doesn’t do so well is allow modelling of paths through a system, or interaction, or the finer detail of design.

Interactive (Rich) Prototyping

Rich prototypes are more commonly used once the basic decisions about a design have been made. In other words, by the time we switch to rich prototyping, we generally know how many pages, and roughly what will be on each page. We may not know how the various parts of a page will work, nor how individual pages will inter-relate with other pages, but the basic shape of a design is there.

The move to rich prototyping is borne of a need to explore the specific implementation of designs. In other words, modelling how functionality works, rather than simply glossing over such detail. A good example for a rich prototype would be building a tabbed dialog so that clicks on tabs change the content, showing the tab state change and effectively simulating a real tabbed dialog.

Rich prototyping takes a proportionately longer time to do than Wireframe prototype development, due to the need to provide additional detail, interaction with forms, navigation and even simulated data. Rich prototyping also varies in its complexity – it’s possible to create incredibly rich and accurate simulations of key pages, whilst building lower-fidelity versions of less important pages. This allows the designer to prioritise her efforts to ensure that maximum value is extracted from the creation of prototypes with regard to ironing out any design gremlins.

Rich prototypes are suitable for:

1) Exploring the finer design details once the basic shape is in place;

2) Providing a realistic ‘finished system’ experience to allow users to get a chance to try out the complexities of a design ahead of the development phase;

3) Really ‘getting inside’ a design of key pages to ensure that a design really does work.

The drawback of rich prototyping is generally in the time it takes to do, and the need to use (often expensive) software.

A combined approach

The purpose of this article was to give a few reasons why a designer might choose a wireframe or a rich prototype approach. However, the best approach is generally to mix and match as suits the needs of the project.

For instance, work with the business to mould the basic shape of a system using wireframing techniques, comparing alternative layouts or page compositions, without worrying too much about how it looks and the finer detail of how each page will work. Once the major layout and composition detail is stable, select parts of the design which might be either fundamentally important to the success of a design (e.g. a registration process) or involve a slightly unusual layout or functionality. These are the things that can then be modelled in a rich prototype, and examined in more detail – perhaps by using them as the basis for user feedback sessions.

Whichever method you use, be assured that just by adopting requirements prototyping techniques into your project, you are dramatically increasing your project’s chances of success!

via softwareprototyping.net

John Clark is explaining the differences between wireframing and prototyping and a very illustrative and comprehensive mannor.

Permalink | Leave a comment »