WIREFRAME WEDNESDAY

The Ultimate Wireframe Archive

[mydigitallens]

[wireframewednesday]

Great design seems to come either from fits of absolute madness or perfectly clear thinking. When it comes to creating a web application, website, or mobile app for which I am being paid money, I generally prefer the latter. So I believe strongly one should never write a line of code or paint a single pixel without a solid game plan.

Refactoring code can be fun, but when it comes to a large development project, it’s nearly malpractice. Wireframing, therefore, is a crucial process that lets you make mistakes before those mistakes become expensive.

There are a wealth of tools out there for web designers. I happen to hate them all. The web-based tools, created before what I call the “maturity era” of client-side frameworks like EmberJS, feel awful in the browser. The native wireframing apps, on the other hand, can be just as clunky, expensive, or out-dated. And my creativity was quickly sapped by a sea of black and white boxes and Comic Sans headers.

Are you proud showing this to a client? Do you gain a sense and feel for the flow of the project? Does it inspire you to move to the next step? And when the answer to these questions is no, some decide to skip wireframing altogether — an even worse, if understandable, mistake.

So I decided to throw every tool out the window and upend my process. Here’s what I do instead and what you should do, too.

Chris Winn about his process of wireframing a project. Enjoy the full article over on Chris's blog chriswinn.com

[uxsprout]

Difference in People not Documents

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.

[wireframewednesday]

Awesome and free wireframing paper templates by Dotted Paper. Available here.

[wireframewednesday]

Content precedes design. Design in the absence of content is not design, it’s decoration.

Jeffrey Zeldman

[wireframewednesday]

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. 

[wireframewednesday]

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. 

[wireframewednesday]

Wireframes tend to lie more often than Photoshop does.

Luke Wroblewski

[wireframewednesday]

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

It’s hard to say that a wireframe is wrong. There’s no right way to do wireframes, so why should there be a wrong way?

However, there are ways in which wireframing can go (terribly) wrong. And I’m going to list the top 10 why reasons that happens. Bottom up! There will be two sets of reasons: too much of something, and not enough of something else.

10. Too much time spent on wireframes

Remember, as it’s often forgotten. Wireframes are not the final design. They will not go into production. Nothing will actually be used in real product development. And that’s a good thing for many reasons. But for one reason, you shouldn’t spend too much time on wireframes. How much time is too much? Well, that depends on you. If you have a day to put a bunch of screens together, then spend a day. If you have an hour, do it for one hour. But don’t push other things because you still have to work on the wireframes. It’s just not worth the extra effort.

9. Too many (similar) screen mockups

Again, this is not development we’re talking about here. If two screens have pretty much the same sort of features, then why prototyping them both? One is enough. If you have smart developers working with you, then they will get the idea. It’s better to detail one screen a little bit more, then to have two screens roughly sketched up.

8. Too many possible future features

Start simple. Really, really, dead simple. There is always the first brick. Then, only, comes the second one. And the third, and so forth. Deadlines will force you to throw things out before they actually get fully implemented. Sometimes even before that. Then you’ll have to mess up your designs because now parts of it are gone. And things start to fall apart.

It’s easier to put things in as you really, really need it, than to take things out when the remaining parts are not ready to fill in the empty spaces.

7. Too many details, too low, too deep

You don’t have time now to set in stone the exact layout, the exact sizes, the exact font sizes, colors, and every other tiny details. It just doesn’t matter how much data you want to collect for users on sign-up. Future is always uncertain. Things will always change.

Wireframe for change and for the future. The best designs are those that can adapt to change and not those that try to prevent it.

6. Too much talk

Wireframes are a great mean to improve and help communication. But there’s a limit. They help you get a better idea of how that UI might look like once implemented, but not how it will look like. Make the distinction. Save some conversation for later, when you and your team will be in front of a screen that’s closer to reality.

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. 

[wireframewednesday]

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. 

[wireframewednesday]

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.

[wireframewednesday]

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. 

[wireframewednesday]

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 

[wireframewednesday]

Blueprint Wireframe

If you are ever in the situation to explain wireframes to clients with the blueprint metaphor use Derek's example. Credits: Derek Clark 

[wireframewednesday]

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 

[wireframewednesday]

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. 

[wireframewednesday]

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. 

[wireframewednesday]

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.