It’s vital for UI elements to be consistent across different parts of an application, so as to improve learning curves, encourage familiarity, ease of use and recall of how to use. However, if a particular part of the application requires a different visual treatment or UI element or behavior due to the nature of the context (a form layout vs. a table or tree), then by all means just do what makes sense for that context–do the right thing! Forcing consistency for the sake of consistency isn’t the best prescription if it conflicts with the needs of a certain context/situation.
Author: Uday Gajendar
I am a UI designer in Silicon Valley, having worked within large corporate user experience teams and design consultancies, for over a decade.
The box exercise
Not to be confused with the “box model” of CSS layouts, but somewhat indirectly connected later on in the UI process, the box exercise is foremost a collaborative method of organizing information into potential layouts that can serve as a baseline for photoshop-level comps/explorations. The method connects two traditional but typically separate activities that seemingly have nothing in common: card sorting and magazine layouts. To make this method work, you gotta have a) key members of the team participating (marketing, engineering, design, etc.) b) tons of post-it notes and c) a huge whiteboard to stick and re-stick those post-its.
Basically the process goes like this (block out a few hours, too):
1. Unpack all the contents of the UI to be designed and write them down on post-it notes (one concept per note). For example, if re-vamping a navigation bar, write down all the menu items, tabs, search fields, etc. that constitute that navigation area. Having the product team domain experts (from mkting, engin, QA, etc.) is crucial for this to work well.
2. Gather those notes into groupings that seem to make sense in a semantic way (caution: semantic is a hugely loaded word so please use this term lightly in this case; ie, i’m not referring to XML semantic validity, etc.)
3. Iterate successively on those groupings, constantly questioning why the clumps are what they are, why can’t this item go over there, etc. Move towards smaller, meaningful groups of notes. This is why you want folks from dev and PM–starts to force questions about assumptions, functions, relationships, etc. and lots of “why do we have this anyway?” kind of thinking…
4. While grouping, assign a simple, meaningful label for each group that captures the gist of what that group is about. Naturally there will be changes and debates but pick something and move on. Avoid marketing terms, just get to the heart of what it’s about functionally or semantically. Use the domain jargon if appropriate for the user audience.
5. List out the groups on the side, giving an approximate percentage of importance for each group. For example, File Exchange functions might be 75% of the navigation bar because it’s for a data transfer application, while User Prefs would be only 5% since it’s done once and typically not re-visited after that. These percentages will be useful for the next step.
— So that is basically the card sorting portion of the exercise. Usability purists will note that a true card sort activity can last for days, usually involving hours spent with one domain expert at a time, not multiple folks simultaneously. And of course a detailed report suggesting recommendations emerges from the activity. The goal here is expediency and getting to action/decisions to move the process forward in a real-world product development situation. Remember, real artists ship! —-
5. Now we get into the magazine layout part of the process. Mindful of the group labels and their respective percentages, draw on the whiteboard some boxes for the groups–they’re just layouts. NOT UI controls or widgets! That’s later on… You want to do this fairly quickly, no more than 2 minutes per layout drawing, generating 3-4 per person (yes, force those PM’s and developers to draw!). Helpful to use different colored markers for each person.
6. Now step back and discuss each layout, the rationale and issues (but not getting into UI widget stuff or style ideas yet) and vote successively on a) which one approximates the ultimate ideal b) which layout is most like today’s and c) which layout is a good transition from today to the ideal.
7. Based upon these drawings and groupings, the team is ready to proceed to the next phase: visual mockups and explorations, including UI controls and styles…
To summarize, the benefits of the box exercise include:
– Cross-disciplinary collaboration in a) understanding the functions and b) generating improved alternatives
– Connecting a common usability activity with designing, “making something” that moves the overall UI design forward
– Involves non-design members to contribute ideas
– Leverages a simple drawing scheme: boxes! anybody can draw a box.
– Encourages critical thinking about the content and functionality, before entering the UI widget/style stage
What is a pixel anyway?
An abbreviation of “picture element” but so much more! Basically it’s a mathematical abstraction, not simply a “dot on the screen”, as one may mistakenly presume. Nor does it have a physically determinate size, since it’s size is dependent upon many factors, including screen resolution of the display device. This can become very metaphysical very quickly, but essentially as an abstraction that is processed electrically via “computer parts” (extreme layman’s terms) and represented on the display via RGB color values, pixels are in effect not “real” but simulations/representations of mathematically defined logical structures/units. Sounds like the matrix, doesn’t it???
More to it than this…trying to find papers/books that refer to this deeper view of pixels and will update shortly.
Only real artists ship
Another one of those colorful epigrammatic statements from Steve Jobs, meant to inspire and motivate a development team to fully complete an ambitious project, especially once the “train has left the station”: designs are largely decided, prototypes rapidly being built and approved, and back-end programming has begun, signalling that “This is for real, folks!”, no longer some design concept or skunkwork exercise. The implication: decisions gotta be called and owned up to, tradeoffs made, and just drive towards making this real for the customers.
A little googling about this reveals the broader context for this particular slogan– shipping the first release of the Macintosh computer, which at the time was way over-schedule, etc. etc.
Below is a quotation from Steven Levy’s chronicle of the first Mac, titled Insanely Great, explaining the slogan:
Jobs’s speeches were punctuated by slogans. Perhaps the most telling epigram of all was a three-word koan that Jobs scrawled on an easel in January 1983, when the project [the release of the first Mac] was months overdue. REAL ARTISTS SHIP. It was an awesome encapsulation of the ground rules in the age of technological expression. The term “starving artist†was now an oxymoron. One’s creation, quite simply, did not exist as art if it was not out there, available for consumption, doing well. Was [Douglas] Engelbart an artist? A prima donna—he didn’t ship. What were the wizards of PARC? Haughty aristocrats—they didn’t ship. The final step of an artist—the single validating act—was geting his or her work into boxes, at which point the marketing guys take over. Once you get the computers into people’s homes, you have penetrated their minds. At that point all the clever design decisions you made, all the tists and turns of the interface, the subtle dance of mode and modeless, the menu bars and trash cans and mouse buttons and everything else inside and outside your creation, becomes part of people’s lives, transforms their working habits, permeates their approach to their labor, and ultimately, their lives.
But to do that, to make a difference in the world and a dent in the universe, you had to ship. You had to ship. You had to ship.
Real artists ship.
Invisible gridlines
Grids are of course a common and valuable device for visual designers; much has been written about “the grid” from the standpoint of design criticism, theory, and history. However, it’s also important to develop a sensitivity to see the “invisible gridlines” lying behind the composition of UI controls in a dialog box, for instance…and minimize the number of intersecting lines. That’s actually how one can achieve a cleaner layout and design, with greater alignment of objects at the most tedious level of detail: x-heights, widths, outside borders, etc. It’s focus on that level of detail that can help distinguish one’s design as truly perfected, rather than merely sufficient.