WIREFRAME WEDNESDAY

The Future of UX: Killing the Wireframe Machine | Elisabeth Hubert

Eilsabeth’s talk presented at the Future of Web Design NYC which explains that UX is not equivalent to UI and why we need to stop saying it is. Credits: Elisabth Hubert 

Getting Started with Wireframing | manyangl.es

Have you ever wondered how is it that most Web Designers have such an organized way of thinking? Mainly how their website layout, content, hierarchy and scenarios are displayed? This is due to several things, but planning may be the most important of all and in Web Design, Wireframing is the perfect planning tool to help get creativity kick started.

Website Wireframes are the core and skeletal representation of what a website could look like and can be used for a wide variety of purposes, but of course you need to follow certain rules and the end result can be used to manage and plan important aspects of a website. According to a book by Jesse James Garrett titled: The Elements of User Experience: User-Centered Design for the Web and Beyond “The skeleton plan of a website can be divided into three components: information, navigation and interface design”.

A Wireframe

A wireframe can help you in several ways to save money, time and properly organize space and elements. There is no doubt that by having everything properly set up before rushing into adding graphic and final aesthetic elements can help you save time by allowing the user to create a demo or draft thus getting a Beta view of what the website will or could look like at the end and minimizing the time that the website needs to be worked on.

A basic Wireframe can contain a large amount of elements but categorizing them and setting labels for them can add order, hierarchy and proper sequence to your site. There may not be rigorous rules to follow on how you do your wireframing, but there are some simple steps and wireframing basics that you need to know. Here are some guidelines that you can follow.

What to Show

Wireframing should show groups of content and should explain what these groups or blocks will contain and where on a page they will be placed. The visual arrangement of the content is explained by saying how the information will be structured, at this point we should have an idea on what information we are going to present to the user and where this information is going to be displayed. One last part of the of the wireframing elements is explaining how the user and interface will interact, this way completing the full process of presenting all possible elements of a web design through a simple but important set of steps.

Visual Elements

By the use of simple shapes and the addition of abstraction through images we can speed up the process of wireframing and still meet user needs of understanding what elements of the website people will be interacting with.

Abstraction & Wireframing

By not placing final elements and/or mock-ups in a Wireframe or a client website proposal we add abstraction and somewhat force the user or whoever is in presence of the website wireframe to imagine and place visual elements where there may be none so far (at least not final visual elements like images or actual content), this may present as a problem to whoever is not accustomed to work in a aesthetic and design oriented environment, but if presented properly, one can achieve a great value of satisfaction and representation through well used elements.

“Getting Started with Wireframing” is an article by Joe Jimenez addressed to people new to the topic of wireframing. Read the full article over at manyangl.es 

Create wireframes that work for you | .net

Once all the planning for a site is done and the initial thoughts have been hashed out, we must start putting together concrete ideas for design and structure. Eventually, we’ll reach the point at which we’re working in Photoshop (or the browser, if that suits you) and delicately crafting pixel-perfect designs, but first we need to establish what we’re designing.

In this article, we’ll discuss thumbnails, wireframes, and grayboxes. We’ll see how they fit into our workflow and what purpose they serve. The article should serve as an introduction to the wireframing process, and an overview of the key decisions it involves.

Why not go straight to Photoshop?

Honestly, it depends on how you prefer to work. No single process works for everyone, and you may trust your instincts enough to just go for it and hammer out your designs in one sitting. More power to you, if that’s the case, but I’d doubt it. Most of us require a little structure to sort out our ideas before we can work with them.

I know a number of designers who essentially skip over the predesign phase of the process and go straight to the likes of Photoshop CS6 for their mockups. They push around pixels until they find a design they’re happy with and serve it up to the client. Sometimes it works and the design is accepted, marked up and shipped out. Sometimes it doesn’t.

More often than not, the designers that can make a great design without sketching or wireframing have a fast internal decision-making process. The designer either goes with the first idea, or they have the ability to quickly and decisively accept or reject ideas on the fly.

Really, they are going through the same process that I’m outlining, they just do it internally. Either way, a process still takes place when they attack that blank Photoshop canvas. Be warned: usually, the ability to solve these problems internally takes a great deal of experience. I believe that the structure provided by a definite process can help ensure that you give every aspect of the design the attention that it needs.

In this excerpt from The Web Designer’s Roadmap, Giovanni DiFeterici points out the role wireframing plays in design, and how to create wireframes that suits your own needs. Read the full article over at .net magazine. 

Wireframes: From Bar Napkins To Prototypes | Usabilia

Some of my best ideas were conceived and communicated using a sharpie and a bar napkin. Unfortunately, some of my best ideas were obliterated by a sweaty beer glass.

I’ve also walked into conceptual reviews with exquisitely detailed, working prototypes only to have the review go something like this:

Me: …and then the user would click Submit–something like that–and the back end system will process the new registration. Is this the kind of user experience we are looking for?

Client 1: Could we move the Submit button about five pixels further to the right? It looks crowded.

Me: Sure, this is just the conceptual mock-up, we’ll do a formal layout design as soon as we agree on the features and general work flow. Did this feel like the right flow to you?

Client 2: When you move the button, could you change the font on it as well? I like Verdana.

Me: Uh, yeah, we’ll get into all that when we do a formal layout. Did we capture the information the back end is going to need in order to process the user’s registration? And did the order feel logical?

Client 1: Does Verdana really represent who we are? I’d like to think we’re a little edgier than that.

A couple of points I would like to extract from the two previous examples:

• Wireframes (or mock-ups, prototypes, etc.) are tools both for thinking about the user experience and for communicating solutions.
• Wireframes come in different levels of sophistication or fidelity–each with its relative advantages as well its inappropriate circumstances.

In this article I will examine the different types of wireframes and discuss their benefits and limitations and where in the design and development life cycle they best fit.

The Fidelity Spectrum

It is useful to categorize wireframes along the dimension of fidelity, that is, how accurately or realistically do they convey the user experience? At the low end of the spectrum are crude, hand-drawn sketches–like my medium of inspiration, the bar napkin. On the high end are realistic looking functional prototypes that allow realistic interactions that let the designer fully explore and test the user experience.

When describing the fidelity of a wireframe, three attributes describe how realistic or true-to-life the wireframe is:

Appearance – At the low end, a wireframe looks hand drawn. At the upper end, it looks exactly the way a final user interface would look. In between you might find things like screen blueprints done in Visio, or screen mockups in Powerpoint.

Medium – How realistically a wireframe can convey the user experience will depend a lot on the medium. Wireframes done on paper are less faithful to the user experience than wireframes done and demonstrated on computer.

Interactivity – The true ability of a wireframe to explore and communicate a user’s experience will often depend on its ability to simulate the ways the user and program interact with each other. Low end wireframes are static; high end wireframes cannot be distinguished from a functioning product.

Mike Hughes on the fidelity of wireframes. Read the full article over at Usabilla. 

Why It’s Important to Sketch Before You Wireframe | UX Movement

Have you ever had an idea for a website or application? It’s easy to come up with the idea, but the hard part is understanding how that idea will take shape in user interface form. This is where sketching is useful. Sketching happens in many professions that involve creativity and construction. Even Leonardo Da Vinci had to sketch out his inventions before he started to build them. No matter how smart you are, It’s impossible to go from a simple idea in your head to immediately building it out without hashing out the details in between. Sketching out your idea before you build is necessary for every designer to do.

This article underlines why sketching is so important especially when translating an idea into a user interface. Read the full article over at UX Movement. 

Sketching a UX project: An Introduction | Wireframes Magazine

Our friend Jakub Linowski, UX designer and editor of Wireframes Magazine introduces us to his way of sketching a user experience project with the help of Illustrator. You can deep dive into Jakubs work over at his incredible blog Wireframes Magazine. 

10 simple ways to make wireframes more useful. | .net

I get to work with a lot of wireframes – not just the ones I’ve designed myself but ones that other UXers designed, as well as product managers and business analysts. This is great because it exposes me to a lot of fantastic work. The work is always good, but the elements I’m going to discuss in this article are often missing from a lot of wireframes, stopping them from becoming as useful as they could be. Here’s a typical example of the kind of wireframe we often get given to user test with.

It shows which elements need to be placed on the page and where they need to go, but there are several things that are not being communicated to the designers, developers and indeed the users that we test with. The following rules will help your wireframes communicate with more insight.

Steve Cable, senior user experience consultant for cxpartners, comes up with 10 rules that will help you create better wireframes for your projects. Steve recommends showing visual priority with shading and offers tips to enhance your wireframing skills. Read the full article over at .Net magazine. 

Stop it with the wireframes. Please. | Ryan Brussow

Over the past several years I’ve either been working in, or working directly with larger UX teams in a corporate setting. I’ve noticed that wireframes appear to be the primary product being produced these days. On a certain level, it makes some sense. It’s a document (large organizations love documentation). It’s something business stakeholders (at least claim) to understand. It’s something that dev teams (usually in non-agile settings) often request. It’s a paper trail (which fits in with the CYA school of business).

 But wireframes don’t work. They don’t work because of all the things a wireframe is not. It’s not a technical requirements document. It’s not a user research document. It’s not an interaction design document. It’s not a content specification. It’s not a testing document. It’s not a visual design specification. It’s not a component library.

 In other words, it’s NOT the product that the user experience is being crafted for.

[…]

Focus on the product. Not the wireframes. After all, our users will never be using the wireframes.

Ryan Brussow’s view on wireframes and that we need to look at them as an internal communication vehicle rather than a secret sauce to everyhting UX related. Read the full article over at Ryans blog.