Pixel perfect wireframes?

12 Jun 2010 - 2:17pm
4 years ago
12 replies
3403 reads
Kai En Ong
2008

What do you think about creating pixel perfect wireframes? Good or evil? (Or it depends ;-)

The websites our team work on have a standard width, grid, interactive elements and some general guidelines for typography. Therefore any designer working on a wireframe could create it to the pixel (we have a fixed layout). 

However, when I started out as a visual designer, I felt limited by the wireframes I was given in the brief if they were too perfect. They could limit the design, especially if they have been signed off by clients, who were now expecting the UI to look like a coloured in version of a wireframe. As I'm now responsible for interaction design, I'm careful not to over-spec,  so there's more freedom in the interaction design/visual design collaboration. Problems can occur when developers or testers are working from an annotated wireframe that is visually different from the designs, sometimes triggering the wireframe-update-death-spiral.

What's your approach to this?

Comments

12 Jun 2010 - 6:05pm
tessa
2008

pixel perfect wireframes accelerate the process - sometimes detrimentally because the team hits "perfection" without the necessary drill on the structure, controls, flows, etc. IF you an balance that and keep business partners focused on the interaction before the beauty - go for it. A word of caution as well - make sure the reqs are good and strong and not skipped or you will go back to square one. ;~)
we use InDesign with layers for the wireframe objects with a hi-fidelity layer for some reviews, etc. They are driven by the drag/drop panel libraries thus giving us flexibility for factors that may come into play during the project (i.e., executives who want to see the sexy stuff, developers who want to see the structure, etc.). And then we use the integrated workflow for copy using InCopy. It is all a balance and one that is facilitated through our styleguide, software and templates.
hope this helps. 

On Sat, Jun 12, 2010 at 12:48 PM, Kai En Ong <kai.en.ong@gmail.com> wrote:

What do you think about creating pixel perfect wireframes? Good or evil? (Or it depends ;-)

The websites our team work on have a standard width, grid, interactive elements and some general guidelines for typography. Therefore any designer working on a wireframe could create it to the pixel (we have a fixed layout). 

However, when I started out as a visual designer, I felt limited by the wireframes I was given in the brief if they were too perfect. They could limit the design, especially if they have been signed off by clients, who were now expecting the UI to look like a coloured in version of a wireframe. As I'm now responsible for interaction design, I'm careful not to over-spec,  so there's more freedom in the interaction design/visual design collaboration. Problems can occur when developers or testers are working from an annotated wireframe that is visually different from the designs, sometimes triggering the wireframe-update-death-spiral.

What's your approach to this?

(((
14 Jun 2010 - 8:13am
shellyc
2010

As designer turned UX designer, I struggled with this for a while but in our studio it turned out that near pixel perfect wireframes are actually helpful. We scamp/sketch out initial concepts using black and grey marker pen, before moving to more detailed wireframes.  I always wireframe to a grid and try to get font sizes approximatly what they should be, and my wireframes are generally in colour *gasp*. Wireframing to a grid, ensures that we can tell from the start before visual design that a layout works and what we can approximatly fit in a given space, and the client gets minimal suprises. I use colour to highlight some important visual heirachy and functionality, as well as messaging, its usually not the final colours but it helps visually explain a wireframe without always needing to read my annotations (also very helpful for unstanding when it comes to presenting and explaining concepts to clients). While these things help make the design process easier, it also helps to push the designers beyond the temptation to just colour in the boxes, and makes them work harder to make sure their designs knock the socks of my pretty wireframes.

14 Jun 2010 - 10:05am
elvenmuse
2010

What's the difference between wireframes and a grid? I have to say, that the grid is and will always be "king" in Design environments... and if wireframes are basically grids, then yes they should be as accurate as possible.

> As designer turned UX designer, I struggled with this for a while but in > our > studio it turned out that near pixel perfect wireframes are actually > helpful. > We scamp/sketch out initial concepts using black and grey marker pen, > before > moving to more detailed wireframes.  I always wireframe to a grid and try > to > get font sizes approximatly what they should be, and my wireframes are > generally in colour gasp. Wireframing to a grid, ensures that we can > tell > from the start before visual design that a layout works and what we can > approximatly fit in a given space, and the client gets minimal suprises. I > use colour to highlight some important visual heirachy and functionality, > as > well as messaging, its usually not the final colours but it helps visually > explain a wireframe without always needing to read my annotations (also > very > helpful for unstanding when it comes to presenting and explaining concepts > to > clients). While these things help make the design process easier, it also > helps to push the designers beyond the temptation to just colour in the > boxes, and makes them work harder to make sure their designs knock the > socks > of my pretty wireframes. > > ((

15 Jun 2010 - 11:34am
philipbrook
2008

"wireframes are basically grids"

The term wireframe comes from sculpture, where an artist would literally create a 'wire frame' and the build the sculpture progrssively onto it. The term was adopted in the digital 3D modelling environment.  The amount of detail in the wireframe is dependent on what is required to support the progression into the finished sculpture.

Wireframes (in interactive) normally delineate what content and functionality goes where. The amount of fideility is normally dependent on where you cut over , collaborate or hand over with creative pals such as writers, designers, media bods.

A grid (taking from its roots in painting, print and architecture) is simply and invisible strcuture onto which elements are arranged, or out of which elements are developed. So your wireframe can be arranged on a grid, but initself, it's a wireframe.

If you happen to be in a postion where you are  using colour to describe hierarchy so the client has no surprises and designer quicly understand hierarchy etc (without reading copious notes), good for you and your company: you are creating a functional specification in a way the team understands and which is de-risking the project.

The designs ought to articulate the values of the client's brand and sell his/her products and services. If the clients' brand values or proposition happens to include 'pretty', well done again, but that ought not be the primary aim of anything you or the creatives do. If the creatives are colouring in wireframes they are simply noty doing their job well, because they're not putting brand values and selling product/services at the heart of what they're doing. But that's another discussion I fear..!

16 Jun 2010 - 5:06pm
tessa
2008

wireframes handed over? what if you had a doc where the editor began writing BEFORE the wireframes were detailed out to the "final approval" degree? What if you had layers that kept input separate and a technology that allowed simultaneity and shared visual assets that auto-update? Degrees of fidelity are handled by the software and by turning on/off layers. This use case is about turning on/off layers to review/preview to the degree the audience requires (combined wire frames, copy and visual assets) and true collaboration (no waterfall!) for a stronger project outcome. In other words - one versatile doc, varying degrees of fidelity (frames to pixel perfect).
If you wait to "cut over" (waterfall) you create an exclusive atmosphere that the editor and visual designer must always play catch-up on and therefore can't do their best work because they are only getting a wireframe doc passed down to them after the decisions (that could affect their expertise) are made.... this use case is less about the question of fidelity and more about control being more important than collaboration - and at least 3 separate docs....
So take off the limit and your options and versatility increase. :)
On Tue, Jun 15, 2010 at 11:14 AM, philipbrook <p_brook@yahoo.co.uk> wrote:

"wireframes are basically grids"

The term wireframe comes from sculpture, where an artist would literally create a 'wire frame' and the build the sculpture progrssively onto it. The term was adopted in the digital 3D modelling environment.  The amount of detail in the wireframe is dependent on what is required to support the progression into the finished sculpture.

Wireframes (in interactive) normally delineate what content and functionality goes where. The amount of fideility is normally dependent on where you cut over , collaborate or hand over with creative pals such as writers, designers, media bods.

A grid (taking from its roots in painting, print and architecture) is simply and invisible strcuture onto which elements are arranged, or out of which elements are developed. So your wireframe can be arranged on a grid, but initself, it's a wireframe.

If you happen to be in a postion where you are  using colour to describe hierarchy so the client has no surprises and designer quicly understand hierarchy etc (without reading copious notes), good for you and your company: you are creating a functional specification in a way the team understands and which is de-risking the project.

The designs ought to articulate the values of the client's brand and sell his/her products and services. If the clients' brand values or proposition happens to include 'pretty', well done again, but that ought not be the primary aim of anything you or the creatives do. If the creatives are colouring in wireframes they are simply noty doing their job well, because they're not putting brand values and selling product/services at the heart of what they're doing. But that's another discussion I fear..!

(((
15 Jun 2010 - 4:06am
neha
2009

With my wireframes, I also start with black and white, then move to greyscale, and finally begin to add a bit of color.

This process might be partially due to the fact that I often sketch, wireframe, design, refine, and produce on the same canvas.

Mike

On 6/14/10 11:59 PM, neha wrote: > I agree with you. We do that too. Coloured wireframes with close to > actual font size helps in visualising the page and its much easier to > get client approvals :) > > > -----Original Message-----From: ixdaor@host.ixda.org [1] > [mailto:ixdaor@host.ixda.org [2]] On Behalf Of shellyc > Sent: Monday, June 14, 2010 07:07 PMTo: neham@techved.com [3]Subject: > Re: [IxDA] Pixel perfect wireframes? > > > > As designer turned UX designer, I struggled with this for a while but > in our > > studio it turned out that near pixel perfect wireframes are actually > helpful. > > We scamp/sketch out initial concepts using black and grey marker pen, > before > > moving to more detailed wireframes. I always wireframe to a grid and > try to > > get font sizes approximatly what they should be, and my wireframes are > > generally in colour gasp. Wireframing to a grid, ensures that we can > tell > > from the start before visual design that a layout works and what we can > > approximatly fit in a given space, and the client gets minimal > suprises. I > > use colour to highlight some important visual heirachy and > functionality, as > > well as messaging, its usually not the final colours but it helps > visually > > explain a wireframe without always needing to read my annotations > (also very > > helpful for unstanding when it comes to presenting and explaining > concepts to > > clients). While these things help make the design process easier, it also > > helps to push the designers beyond the temptation to just colour in the > > boxes, and makes them work harder to make sure their designs knock the > socks > > of my pretty wireframes. > > > >

14 Jun 2010 - 8:14am
mattinteractive
2010

To me, wireframes should be very well thought out from a UI perspective. But as far as design/layout they should be very rough blue print.  Wireframes should serve as a rapid prototype so that there's more budget for actual design and creative work.

14 Jun 2010 - 11:05am
Benjamin Bykowski
2010

I've gotten resistance from some of our graphic designers when presenting them with wireframes created using 960 grid system (we used Axure RP Pro). But others have been quite receptive and the end product more in-line with what the client has collaboratively helped create. I also use color and even imagery when appropriate. Some clients need this, while for others, it can complicate the conversation. So you need to know when to use what. 
While you may get resistance from designers who think pixel perfect layout limits them, in my experience, the truly gifted graphic designers take a pixel perfect concept and transform it creatively into a compelling design without sacrificing the essential UI components and they are grateful that they are given the freedom to focus on the look and feel without being stymied by the minutia of navigation, content and interaction pieces. Also, if they find that something doesn't work, they challenge the concept and provide an alternative solution, which ultimately results in a higher quality design.

On Mon, Jun 14, 2010 at 9:33 AM, digitalmatt <matt@digitalmatt.net> wrote:

To me, wireframes should be very well thought out from a UI perspective. But as far as design/layout they should be very rough blue print.  Wireframes should serve as a rapid prototype so that there's more budget for actual design and creative work.

((
14 Jun 2010 - 1:13pm
mattinteractive
2010

I agree with you 100%, but I guess we must first establish what Kai meant as "pixel perfect" wireframes. Should every box drawn in the wireframes appear at the exact pixel coordinates in the design comps?

Wireframes should establish the general layout (if strategic. for example, call to actions) and should also establish annotated interactions (input, output, feedback, engagement, etc).

But as far as padding, margins, alignment, colors, weight, gestalt, overall design, typography, etc...those decisions should be made by a designer.

14 Jun 2010 - 9:34am
Dasbender
2009

The "degree of fidelity" debate is a constant struggle for me.  I usually want to keep things loose and high-level when I'm wireframing so my clients can stay at high-level conceptual state, without getting caught up (and sold) on the details, but I often find it takes having pixel-perfect details to truly communicate with them and get them to picture in their heads what the solution will be like.  So few people are able to visualize in their heads without seeing the exact product in front of their eyes.

The biggest danger of pixel-perfect wireframes I've run into isn't cemented client expectations (I can mitigate that as I'm presenting altered designs at a later date) but rather that they think the design work is all finished at the wireframe stage.  I've had many projects tell me they didn't need any more design and they just had their developers produce and deploy the wireframe Surprised

14 Jun 2010 - 9:38am
SemanticWill
2007

To quote a good friend and former professor at SCAD "Wireframes should be crafted to serve their purpose perfectly." So perhaps, first establish what purpose they are to serve, and then decide what level of detail is appropriate given that purpose. I tend to see them as a process, as I wrote in the article "Wireframes as Thinking Device," for UX Magazine. So if your purpose is to explore design decisions and the problem space, each iteration which be different depending on the goals of that iteration. If your purpose is to sell a concept, that would inform the level of detail required; and finally, if the purpose of the wireframes is to document precisely all interactions and flows for a third party development team to implement, then a completely different rigour might be required of those wireframes.

Just random thoughts on this Monday morning.

Cheers,

@semanticwill

15 Jun 2010 - 4:06am
Stew Dean
2007

Pixel perfect wireframes, in my view, make wireframes pointless.  What you're producing are prototype designs, not wireframes.  Wireframes are there to act as, or part of, the functional spec.   My prefered way of working is to do some initial wireframes as part of a concept stage and then work with designers to get some initial pixel perfect layouts. These are then folded back into the wireframes but are roughly accurate, not down to exact size. When you start worrying about leading, the exactly right pixel size etc then you are no longer doing user expeirence design but graphic design. 

  Wireframes / functional specs are a vital part of the development process but they are not great for client communication. Clients prefer designs with all the colours etc left in and prefer any site maps / user flows to be simplified and often translated into conceptual diagrams. They need the overall concepts not the detail the wireframes often have to go into.

  I agree that the designer needs to have freedom to interpreate the functional requirements and good graphic designers are also good interaction designers as well, I find my roll as a UX architect naturally overlaps with that roll. For me to worry about pixel perfect stuff would add to a long list of other considerations such as business requirements, user journies, process flows etc I already have to work about. 

  Having said all this there are always exceptions and the environment you find yourself in often alters the methods and deliverables you find work best.   Stew Dean  

  On 12 June 2010 22:23, Kai En Ong <kai.en.ong@gmail.com> wrote:

What do you think about creating pixel perfect wireframes? Good or evil? (Or it depends ;-)

The websites our team work on have a standard width, grid, interactive elements and some general guidelines for typography. Therefore any designer working on a wireframe could create it to the pixel (we have a fixed layout). 

However, when I started out as a visual designer, I felt limited by the wireframes I was given in the brief if they were too perfect. They could limit the design, especially if they have been signed off by clients, who were now expecting the UI to look like a coloured in version of a wireframe. As I'm now responsible for interaction design, I'm careful not to over-spec,  so there's more freedom in the interaction design/visual design collaboration. Problems can occur when developers or testers are working from an annotated wireframe that is visually different from the designs, sometimes triggering the wireframe-update-death-spiral.

What's your approach to this?

(((Please leav
Syndicate content Get the feed