Pushing Pixels and Carving Bits

by Jon on July 28th, 2011 - Comments (0)

At Involution, our software design methodology approximates that of the industrial design process: Designers take an overall, system wide view of the product, and are responsible for specifying, as much as possible, the final form and function. This means that, just as an industrial designer understands her materials, be they metal or silicon, so too must the software designer understand his, be they pixels or code. Ours is a rigorous and broad perspective, which requires that the designer be fluent with everything from concept sketching to pixel pushing to prototype coding. In the end, asking a user interface designer to understand all of these parts of the process gives them a powerful set of tools for creating effective and beautiful software, which is always our goal. And while taking this path to creation can be challenging, we find it yields positive results.

Two weeks ago, I discussed concept sketching and the reasons we do it as part of our process. This week we’ll take a look at creating pixel perfect mock-ups of the user interface and a few of the considerations that come into play when approaching that step in the design.

It’s All Relative
Interaction, aesthetics, usability, and information design are software design siblings, and each one effects the other. A modification made to the visual design of a UI for instance, may necessitate a change in the interaction, which may impact the usability of a given workflow. With each iteration of a UI mockup, each element informs and improves the others, evolving the design and bringing us closer to the real thing.

On a separate note, this is precisely why we avoid wireframes, because they require a lot of work and more often than not, don’t move the design forward. Once we have some initial concepts sketched, we proceed directly to pixel-perfect comps.

Aesthetics is Not a Dirty Word
The word aesthetics, surprisingly, can be a loaded term when it comes to UI design, sometimes used in a derisive manner to reduce the process to a simplistic mandate of “making it look pretty”.

Appropriately beautiful software of course, encourages users to spend time with the application and learn it. Well designed visual cues provide user affordances that make interfaces “intuitive”. Color, used sparingly, can enhance the user’s ability to immediately see points that need to be acted on, when quickly scanning an interface. Well set type can enhance legibility. Balance, alignment, and artful use of space can direct the user’s eye to appropriate tasks. The list in defense of “making it pretty” goes on and on.

Mock-ups Should Contain Real Data
Whether it’s user names, project titles, times, dates, chemical compounds or survey responses, the data contained in your comps should be as real as possible. Using Lorem Ipsum placeholder text is not a good idea, as it can blow up production. Besides causing embarrassment, if you were to mistakenly leave in placeholder text in a production release, Lorem Ipsum can backfire in other ways. The length of people’s names, for instance, are highly variable, and no placeholder text, especially not fake Latin, can really indicate the right spacing for that data. If you design a layout to contain user name data and fail to allow for the proper amount of pixel space, you’ll regret it later when the real names flow in. Fake data, like Lorem Ipsum text, creates fake design.

High Fidelity Comps Yield High Fidelity Decisions
Ultimately, high fidelity, pixel-perfect comps gives stakeholders a more complete understanding of how the product will look, feel, and even act. And as a result, it allows them to make grounded decisions on everything from visual design to information architecture to interaction. Additionally, pixel perfect mock-ups can provide the solid foundations of a design spec for the engineering team, if you’re not going to build the product yourself. Of course the pixel perfect mock-up is not nearly as good for vetting the behavior and true usage of a product as the prototype, which is why that is the next step in our process … and the topic of another post sometime soon.

Tagged

What do you think?