Robert Hoekman, Jr. says better solutions come from designing in groups. I absolutely agree.
Design is a group activity. The small team beats the lone genius every
time. No one individual will have all the best answers. The best answers come from groups. The best ideas are the result of collaboration.
All of my designs have been improved after reviewing and collaborating with developers, business stakeholders, testers, etc. Software is complex and requires insight from all sides - business, technical, design, users.
Although, collaboration almost sounds too nice of a word, as if we're all holding hands and singing while marking up a wireframe. Maybe negotiation is more accurate? The best solutions I've been a part of have always come out of heated discussions, wrestling against multiple constraints.
Nick Finck posted slides from his Puget Sound SIGCHI lecture on The Lifecycle of a Wireframe. Some slides are repeated and it's not clear why without hearing the presentation but it contains a great summary of key concepts and questions an IA should always be aware of.
My overall strategy for IA is 3 step process; understanding the problem (note: not merely identifying the problem but really understanding it), find a solution (there may be more than one solution, but there is often only one right solution), and present the solution (a large part of your job as a IA is presenting your work so the client can understand the results).
In our research, we've found that teams that build out a re-use strategy see tangible benefits: They are more likely to get a completed design sooner, with all the little nuances and details that make for a great experience. Their designs are more likely to meet users
expectations by behaving consistently across the entire functionality. Plus, the teams iterate faster (always a good thing), giving them a chance to play with the design while it's still malleable.
Patterns: the design response to specific behaviors such as always using a calendar picker for selecting dates rather than drop-downs for month, day and year.
Components: the detailed implementation of the pattern; the code and styles to be used for the calendar picker.
Frameworks: groups of patterns and components. The date picker could be part of a larger framework for a personal profile.
Even though each craft was different, the behavior of hunkering was the same:
They lay out whatever physical pieces they have -- raw materials, sketches, and images they'd collected.
They work to put things close to where they'd be in their final form, relative to the other pieces.
Then they step back and ponder it for a while.
In some cases, they walk around to view it from a different angle, to see what it looked like from another perspective.
Then they start back up to work.
Hunkering doesn't seem to be the appropriate term here as that implies leaning in and getting to work. The process described above is the opposite motion of stopping work, stepping back and assessing the design.
I used this process frequently as I'm sketching designs and creating wireframes and prototypes. The process is also used within our team by conducting design reviews with the product manager, developer, QA and system architect leads. In a recent project, conducting these reviews allowed us to catch many issues early on that would have been very costly to fix in code.
Interaction design, visual design, and industrial design are distinct disciplines for good reason: Each excels in different ways. Interaction designers must be good at imagining structure and flow, which requires strong analytical skills and a high degree of rigor, especially for complex systems. Visual designers and industrial designers are masters of visual and physical usability but are also masters of emotion: They know how to evoke caution, attract attention, and instill desire for a product at first glance. Users have just one experience of a product, though. All three aspects of the design must work in concert, or the product will fail to satisfy. Integration of the three disciplines is a central theme of Kim’s new book, Designing for the Digital Age.
Freeform and Linear Task Flows to support both experts and newbies
Limited use of Modal Dialog boxes
Lightboxes
Inline User Assistance
Contextual, Cheap, and Quick Usability Testing Methods
The lightbox benefit is obvious: it's impossible for users to overlook the only bright part of the screen. This is in stark contrast to many traditional designs, where users often remain blissfully ignorant of notifications that are camouflaged within busy pages.
Lightboxes do have downsides, however, and they shouldn't be used everywhere.
A lightbox is a blunt instrument that hits users over the head and causes them to stop everything they're doing. Don't use them for low-priority items or background information.
Talk about modal dialog boxes. A lightbox takes that concept to the extreme. (Even though it's theoretically possible to enable interaction with the dimmed parts of the screen, in practice this just isn't done because something that's dimmed should be
inactive.)
Users often have to refer to information on the background
display to resolve the situation in the foreground dialog box. If the
background is dimmed too much, such information can be hard to read.
An interesting property of great design is that it is taken for granted. It works so well that we forget that creative effort was involved to bring it about. Sometimes, like with the lowly spoon, the object is so simplistic that it seems obvious, and we disregard that at one point in history it wasn’t. Other times, like with the automobile, the object is so sophisticated yet easy-to-use that we’re blinded to the fact that millions and millions of human-hours went into getting it to this point. That’s a shame…every great design has a rich history. And every design has behind it a designer or designers who tried to make the world a better place by solving some problem or another.
Bad design is obvious because it hurts to use. It is awkward, difficult, and complex. In a great irony of the world, bad design is much easier to see than good design. It raps us on the head like a bully. Because of its success, great design is often invisible.
We design to change, guide, support, elicit, constrict, and control behavior. The products and screens we create are about getting others to do something, using or buying or donating or otherwise taking some
real-world action. Good design elicits the right behavior, poor design does not.
An interesting discussion occurs in the comments about the words "elicit" and "behavior". There is a large focus on the moral implications of changing a person's behavior but that was not the point of saying behavior is our medium. It's also about changing the behavior of a system to match the user's goals, needs, wants, etc. to create successful interactions.
Surprisingly, Robert’s assertion was not as obvious to all those in attendance as he had hoped. He got pushback on the idea that designers traffic in behavior. In a follow-up post he writes:
“There is universal acceptance of a holistic approach to
human centered design within this community – generally referred to as
‘experience design’ (not my preferred term). This approach considers
all of the contexts surrounding use and then tries to build a unified
interaction model to support user needs over time, across these
contexts. It focuses not just on expressed needs but on those that are
unexpressed: the emotions, motivations, and desires that shape user
engagement over time. In fact, more and more of our clients are looking
for our help in identifying these latent, unmet needs. So, it is
interesting to find designers who are very comfortable, in fact
insistent, on this holistic approach and yet spooked by the idea that
we are in the ‘behavior business’.”
While I largely agree that I work with behavior, I don't feel this fully "demystifies" what I do as you could say the same about many professions - marketing and advertising come to mind immediately. But I do like using the word behavior in terms of what I'm shaping, more so than pixels, because it gets more to the heart of what an interaction designer does. And this is why I don't use the term "interface designer" as it puts too much emphasis on the screen and the visual and that's the easiest aspect to describe what I do.
Choosing an appropriate format for annotations can make them less daunting. No doubt most people use good old-fashioned prose, but we've found that adding some structure to the annotations can make them more readable. For example, for any given interactive element on a page, we will break the annotation into different scripting-like behaviors like onHover or onClick. Developers tend to like that we're trying to speak
their language, and it provides some clear structure to the annotation.
We've started adorning our annotations with icons to clarify their purpose. Annotations might describe business logic, editorial guidelines, or display conditions, among others. Each of these functions has a unique icon to help differentiate them on the page.
Design patterns are a useful and important tool, but just as useful are anti-patterns - “commonly re-invented bad solutions to problems” (Wikipedia).
Probably the most widely used and known anti-pattern is the use of "click here" for links. Another example is the Novel Notion - "creating a new interface for a common idiom that is more confusing than the original."
The above example uses a new way to scroll that is less usable than the usual scrollbar:
No visual cue (scrollbar size) to indicate how many news items
No way to tell where you are in the list - beginning, middle, end?
Scrolls on hover rather than click, which is unexpected
No way to jump down like you can by clicking in between the arrows in a scrollbar
