nickd, interaction designer

3026 Palmer Square, Apt 2S
Chicago, IL 60647
+1 2-CHAT-NICKD
email:
twitter: @nickdpi

• I received an MSIS in Human-Computer Interaction at The University of North Carolina at Chapel Hill in 2006. My master's paper discussed usability on the Web in terms of cognitive interruptions, finding that people form their expectations about technology based on what's best. If someone returns to using an older product that's slower, their opinion of it is worse than had they not used the better product.

  Since then, I've tried to improve our interactions with technology in any capacity – be it through hardware, software, or on the Web. The best products, which add the most enrichment to our lives, are easy to use. By virtue of their simplicity, they get out of the way, allowing us to expend less mental effort on them.

  “Elegance” has lost its meaning in many fields: often, it's just a synonym for “quality.” But the original definition of the word is a major component of my goals: to make something simple and clean, yet attentive to detail and compassionate towards the user. I work towards the ideal of elegance in everything that I do.

• The term “pattern language” may not be familiar. It was coined by an architect named Christopher Alexander in the 1970s as a means of designing cities and buildings to be more humane and natural. Since then, software development and interface design have both adopted the term to describe modular and conceptual solutions to common problems. (The first Wiki was a software pattern library.)

  Patterns help us break down problems into manageable chunks. They resolve a morass of information into definable issues. They provide firmer consensus among team members. They comfort us, knowing that research can back up design decisions. If you have a good pattern library, many basic issues can be solved.

  Ryan Singer of Chicagoan firm 37signals made a great case for patterns that's very much worth checking out. I often design this way: by listing interface elements, conceptually organizing them, and then sketching a first draft.

• I always begin design by sketching. It helps me brainstorm on the fly, and opens my mind up to new ideas. I'll create many sketches of the same concept to figure out how different solutions relate to one another.

  While innate drawing talent is certainly a plus, sketching well-proportioned interfaces is possible even for the artistically disinclined. Various tools – a ruler, compass, and graph paper – help tremendously. Modular scales used in typography and architecture, like the Modulor and the Fibonacci sequence, are great ways to make sure you're doing it right.

  These are some scans of sketches for projects that I've worked on. None of them will end up on a wall in the Louvre anytime soon, but they gave me and my teammates a greater understanding of our initial problems, and they helped kickstart the brainstorming process when we appeared to be at a roadblock:

  WNUR (#1, #2, #3, #4); Joseph Mohan; I see what you did there (front, interior); FastRoot's home page; personal sites both ultra-minimal and maximal, written in Blueprint; a redesign of the native Firefox app Mozilla Amazon Browser; a Google Maps mashup for parking laws; the original sketch of this page; and a sample iPhone Twitter client.

• When I'm in a time crunch, or when I have to play both interaction designer and graphic designer, I'll move straight from sketching into coding HTML (or whatever program the product necessitates – Interface Builder, Photoshop, etc.), to get as close to a demonstrable, criticizable product as possible. But I prefer wireframing as an intermediate step, because it provides a good functional reference – especially if I'm working with information architects or content strategists.

  All interaction designers have a favorite wireframing tool. Mine is OmniGraffle, which is very similar to Visio but 1) for the Mac, and 2) more naturally responsive to my workflow: for instance, establishing – and then snapping elements to – a proportional grid. I like using Axure, but haven't had many opportunities to play with it. (I'm excited that they're porting it to OS X!) Here are some wireframes that I've made in the past:

  Studies of a betting site, a Google Maps mashup for parking laws, and Wikipedia; WNUR; Bank of America mobile apps (navigation, flow model, entity-relationship diagram); FastRoot's operations management system (front, services, infrastructure, account), and the navigation for my master's paper research site.

• When you start using a product, you automatically begin forming expectations of its future behavior. When those expectations are proven incorrect, it's because inconsistencies forced you to return to the process of learning how to use it. Consistent interfaces are easier to understand. Inconsistencies make us less productive and more frustrated.

  Information architecture should be as structured as possible, with consistency and learnability as its goal.

• Layout is the way that elements – buttons, copy, pull-downs, etc – are organized on one's screen. The proportion, scale, and margins of everything on a page color a user's experience of it. Various proportions are restive; others cause tension; others are calming and familiar. You choose to impart these feelings based on these decisions.

  I love coming up with uncommon yet learnable solutions to layout. This portfolio is one example, but there are others:

  Joseph Mohan, Drudge Report (study), FastRoot (front page), Northwestern Alumni Challenge (Front, 50 Reasons), and AIGA Chicago (Front, Events, Jobs, and Student Chapters), FastRoot's Operations Management System.

• So much content is poorly written: inconsistent, unnavigable, or even absent. Ignoring your content means you're building a very pretty frame to house a ton of crap. But information architecture is dictated by content. What you want to tell someone can imply the organization and features of your product. The best firms now have dedicated content strategists to figure out that implication. They inventory and audit all content so it can be clean, consistent, readable, and discoverable.

  Very few people are asking any big questions about how to organize and define content – both in software and on the Web. Fortunately, some articles are attracting attention. Only eight years ago, nobody knew what it meant to be an "information architect." Now it has its own page on Wikipedia.

  Thoughtful content substantially improved the end product in these projects:

  Austin B. Harvey, Eco Expo, Thoma Cressey Bravo (Front, News, The Team), Northwestern Reunions (Front, Calendar, Registration), and Emmis Interactive.

• Just as your content dictates a good user experience, a good site map can get users to the content they want as fast as possible. This matters even in small projects, and the techniques scale to larger ones as well.

  Some site maps establish a faceted classification scheme for the data that you want to display, and ask where any future data fits in. Other site maps create a series of topic headers, and build out content underneath them that makes sense. Some elegant ones involve flat listings, especially on small projects. Sites that I've organized in this way include:

  Commission on Professionalism of the Illinois Supreme Court (Front, Interior, Calendar), Northwestern Law Review, and Washington University in St. Louis University College (Front, Programs, Undergraduate, High School Front, High School Interior).

• Clarity – when every element has unambiguous meaning to users of intermediate technological fluency – is essential in interaction design. It gives form and purpose to controls and functions. It establishes paths that the user can follow follow to accomplish tasks. It makes data display into an implicit narrative.

  Products are most usable when their rules and methods are displayed with clarity and behave in expected ways. Taking advantage of best practices and established customs is only the first step towards this. Clarity and usability ultimately come from people who cultivate good judgment on design decisions, pay attention to small details, and recognize the tradeoffs that come from all changes.

• Although interaction design is still a nascent field, enough research has come out in the past couple of decades that one can use it to back up design decisions. Usability sites like Jakob Nielsen's put a wealth of useful, free information online. Periodicals like Boxes & Arrows and A List Apart are also helpful. ACM's Interactions Magazine is a valuable print resource. I've also been influenced by many inspirational and fascinating books.

  Below are some projects where research was strongly involved in their creation:

  MEASURE Evaluation, Rubloff Blog, M3 Capital Partners (History, Services, Transactions), and FastRoot (Main Interior, Colocation Front, Colocation Interior, Managed Hosting Front).

• Imagine loading a web site as a blind person, and the whole site is a Flash applet. Or the site's 8-pixel-tall text, with no obvious way to change its size, doesn't account for any vision impairment. These are only two of the sadly many ways that interfaces can make disabled people feel marginalized and helpless.

  It's much easier to avoid these pitfalls, and show compassion and understanding, if universal access is considered as early as possible in the development process, and returned to at every step. Fortunately, standards like Section 508 exist as helpful guides to navigate accessibility problems that may not seem readily apparent. Some projects that I've helped develop with accessibility in mind include:

  Harris Theater, Associated Colleges of Illinois, and WNUR Streetbeat.

• I've witnessed projects where a site was redesigned in a home-rolled content management system. Once launched, its PageRank dropped three points. It's easy to make elegant-looking web pages with code that's difficult for the fancy robots behind Google to understand. There are many established firms that exist solely to optimize your web page for climbing higher in search ranks, but about 80% of their work is just to clean up and organize your code. Most of it is common sense.

  In the past, I've solved basic problems of searchability and findability on the Web. Good information architecture affects this significantly. If your code isn't trustworthy and your site map is incoherent, search engines will believe that you have very little to offer, and deploying your own search will become that much more difficult. Some projects that have benefitted from sensible organization and clean code include:

  FastRoot's Collaborate and Build blog, Silvertrain, SGDP (Front, News, Portfolio, Inquiries, Approach), and Chilmark (Front, Case Studies, The Team).

3026 Palmer Square, Apt 2S
Chicago, IL 60647
+1 2-CHAT-NICKD
email:
twitter: @nickdpi