WIREFRAME WEDNESDAY

Difference in People not Documents

uxsprout:

I’ve been asked and have not yet given a satisfactory answer to the question, “what is the difference between wireframes and visuals?”

To answer the question we first do an internal review of the artifacts of each. Wireframes are usually pictorial representations of information, features and user scenarios (not an exhaustive list). Usually they appear sparse, black, white, gray, and have a lot of accompanying annotations. It’s the first step in explaining an ” experience”. You will of course see some “design” in them as they are visual and they are solutions, but they don’t capture everything and shouldn’t capture everything. Visuals use wireframes as a supplement, as a sort of requirements doc. But the visuals take the experience and start to make it real. Through them the experience gets fleshed out, things are put in their more proper place, considerations for surrounding elements are thought out, things change because…

Why do they change? This is the question we very often get from the client. And here is where the fundamental problem lies. Things change even though they had previously been approved. How does that make sense?

It makes perfect sense if you set expectations correctly. But that’s a different story. We are talking about what happens more often than not, wireframes are delivered, approved lets color those wireframes in and get this bitch developed!

Lets focus not on the deliverables, but on who or whom is creating them. Imagine a scale, on the far left is the visually driven thought process and on the far right is the data driven process. No one good designer falls on the end of either. But the scale does shift and it shifts based on what we are creating. For wireframes the scale shifts more towards the data driven process. We ask a lot of questions about requirements, users, personas, research in order to create a framework for the software we are building. We start thinking about a lot of things that you can’t actually see, but that are analyzed by how we use things. We start to build a conversation, sometimes a very boring one, between user and software. A part of that conversation involves presentation, but if we don’t know what we are presenting what’s the point?

From these thoughts and processes we return wireframes, ideas, checkpoints to make sure we have captured requirements, packaged the requirements into an experience and readied the team to move forward.

Now we must shift. And when the shift happens things change because we are now aware of more than just blank placeholders and gray boxes, we’ve got color, real images, buttons and even more considerations specific to the device we are building to. A shift in thought and process has occurred, responsibility has shifted and changes WILL occur. But that’s ok, because if we have done well as a team we will be designing with a shared vision in mind. Decisions and changes are made for a better experience and as time progresses, focus changes and new challenges come up. A designer or design team that doesn’t shift will not be able to create a whole product, a full experience. If change is not allowed the product suffers because the shift was not allowed and the product remains at a stage not fully developed, not fully explored and ultimately not realized. Experiences live on a large spectrum that shifting designers explore. It is the mindset during creation and iteration that leads us to the differences between wireframes and visuals, not the deliverables.

The fine art of wireframing | Cristian Bosch

Wireframing is the first step in the web design process. It is also the least known and talked about. Along with a sitemap, wireframes lay the groundwork for building a solid website. So, to give wireframes some much needed respect, in this post I’ll share my own process for designing wireframes and illustrate some examples. I’ll also talk a bit about the current trends and wireframing best practices. And finally I’ll mention some of the tools I use to produce rockin’ wireframes.

What’s the importance of using wireframes? For one it is an essential tool of Information Architecture because it establishes the hierarchy and relationship of informational elements displayed on a web page. Secondly, not only do wireframes crystallize the design and information behind a website, they are also a huge time saver in the development process. Just like the blueprints for a building, wireframes act as the structural blueprints for a website. Each web page wireframe can be likened to a floor blueprint in a building. If you think about it, it’s not much different than that, conceptually speaking of course.

Because few people outside the web design industry know about wireframes, wireframing is both an art and a science. And even among web professionals it’s almost an esoteric subject. When I was in design school I only touched wireframes lightly, yet it’s one of the most important pieces of the web design puzzle. And until recently, this part of the process was usually not well documented in web design books. It was either that or the literature was too technical for web designers and geared towards software engineers. This is because wireframes got their start in the software industry. So as a web designer, I had to fend for myself and pick up this knowledge as I gained experience designing bigger and bigger websites. When I started my web design career I did some projects without wireframes, and to be honest, a five page website can survive without wireframe support. But if the project is a bit more complex it’s crucial to spend a good deal on this aspect.

So how does one go about making wireframes? There are many ways to do this, and every web designer and information architect has his own process and style. In the next few paragraphs I’ll cover the simple process I developed over the years. And one that has served me very well in my web design career.

—————————-

Cristian Bosch with an introduction to wireframing. Read the full article over at Maquina. 

Wireframes: A good communication tool, a poor design tool

Wireframes have been a crucial part of just about every project I’ve worked on. I’ve spent countless hours explaining to clients the central importance of wireframes as a tool for good design.

I’ve come to realize that I was wrong. 

Not about the value of wireframes. But about exactly what it is that wireframes do. What exactly wireframes are.

Let’s talk for a moment about what they’re not.

Wireframes are not a design tool

Where does design happen? Before a wireframe can be created, a group of people needs to get together and talk things out. Later on, a wireframe might be created, usually by a single person working in isolation, sometimes long after the initial conversation has occurred. The sketches have been sketched, the ideas have been brainstormed. A wireframe is there to formalize and make concrete what’s been decided as a group. The design work was done verbally, in notepads, and on whiteboards. The wireframe is the document that captures that design work.

A wireframe is good for gathering and consolidating the design thinking—the conversations and sketches—that has already occurred. Wireframes are good at opening up avenues of communication and spurring useful feedback. They can help you obtain someone’s approval, or move a project on to its next phase. Emails, contracts, and specifications also provide this kind of value. I like to call it “paperwork.”

A bridge between idea and prototype

Sketches and conversations can be difficult if not impossible to convey to the people who weren’t around for them. Mock-ups and prototypes can be too time consuming and costly to throw away if they’re not good enough. Wireframes serve as a bridge between raw ideas and costly prototypes. The space between idea and prototype can, in fact, be an uncrossable chasm without a wireframe.

But watch out. It’s important to consider other reasons why there might be such a chasm between your ideas and the commitment needed for a prototypes. You might be dealing with a lack of trust, a deficit of courage among leaders, decision makers who won’t talk to you, resources that are too limited to allow for mistakes, and so on. These issues won’t disappear on their own, no matter how good your wireframe is. They need to be identified for what they are and tackled on their own terms, with tools that are specific to each problem. 

Wireframes are not a panacea.

So what are they?

—————————-

Dan Ritzenthaler on the pro and cons of wireframing. Find out what wireframes are in Dans article published on Medium. 

Top 10 reasons you do wireframes the wrong way | Christian Pascu

Christian Pascu, fellow wireframe tool developer and the pain-points he identified when it comes to wireframing. Find out about the top 5 hurdles on Christian’s Blog. 

UI vs UX: what’s the difference? | Webdesigner Depot

UI is the saddle, the stirrups, and the reigns. UX is the feeling you get being able to ride the horse, and rope your cattle.

At least that’s what they used to say in the olden days. Rather, that is what I wished they’d say. Despite how simple that may have sounded, there are many complications and misconceptions when it comes to the differences between UI and UX design, and they cause the design community to go into quite a stir whenever they are brought up.

An interesting note to that is that I’ve found the people who work at jobs with titles such as Interaction Designer to get paid more simply because they know and act on the differences between those two fields (typically harnessing a little of both). And in fact, I think there are more differences in the people behind these roles than the ideas behind UI and UX design.

Let’s jump right into a standardized definition that we will try to metaphorically elaborate on. Defined very simply a User Interface design is the part of the product that faces the user when he looks at the site, and the User Experience is how they feel when they look at the site, aka the broad scope.

More pointedly, good user experience is the art of a drill going through wood, or a surfboard gliding through water effortlessly. The feelings those give you is unparalleled because they just work, simple as that. Though, in contrast, the shape of that board that helps it make those turns on the wave is good UI, and the surfwax on the top so you don’t slip off is also good UI. In short, the ENTIRE package is what makes it good UX, whereas good UI is always a very important inner-element of that.

Before continuing, I’d like to just say that this article is based on my opinion alone and in no way is trying to make large grandiose statements on the way anything should be. I will be trying to educate readers about various elements of each field, based on my own past experiences but I am, again, in no way trying to impede on your personal views should they differ from those stated in this article. All the metaphors are things that I think relate, and if you think they don’t feel free to let me know in the comments but be sure to give your own as well. It always helps the reader if they have multiple sources giving input about a topic.

Dain Miller on the old chicken vs. egg dilemma. A very good read on clearifying these two very heavily and sometimes mistakenly used terms. Plus I don’t abut you but I love Dains images he plants in my head :) Read full article over at Webdesigner Depot. 

UX and UI, Chicken and Egg

Thought I might share this hillarious video on the difference between UX and UI. Enjoy!

PS: No chickens were harmed in the making of this video.
You’ll also find a good read on this topic here.

Strategy & Wireframing. Plan or Die. | Brad Haynes

Brad’s talk presented at the Future of Web Design on the importance of wireframes in the strategy/planning phase of web projects. Credits: Brad Haynes.