3 Notes

How we wireframe projects | Chris Winn

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

1 Notes

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.

4 Notes

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

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

13 Notes

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

2 Notes

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

1 Notes

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


Wireframes tend to lie more often than Photoshop does.
Luke Wroblewski


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. 


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.