« July 2009 | Main | September 2009 »
Hitchcock is a storyboarding application for iPhone and iPod touch. From photographs in your iPhoto library or on-the-go location shots taken with your phone's built-in camera, you can quickly built a multi-frame storyboard, animate it with voice over and pan-and-scan effects, then output the resulting frames to an annotated PDF for client review.
Continue reading "Spotted on the Web: Hitchcock for iPhone" »
What's the use of use cases? Oh, I can think of a few.
Say that you're creating a website for a client that sells pony dolls made from corn plastic. On the site, there are games for kids to play, and if the kids log in, they'll be able to save their high scores, post messages regarding their favorite dolls, create a public user profile, and other features that have yet to be dreamed up by your team. You've been tasked with designing the screens required for registering users for accounts on the site.
Sounds pretty simple, right? This is where designers usually can't restrain themselves from diving right into sketching and ideation and Photoshop and luxurious comps. Next thing you know, the client approves the designs, the project moves into development—and lo and behold, there are a few corner cases you hadn't acknowledged. A few whiteboard sessions later, a long discussion or two with the client, and those corner cases are starting to loom large over the entire design that is now been un-approved and is in the midst of rapid redo.
Even worse, the client is on the hook for making some major changes to their company's business process because those details weren't thought through in the design phase and implemented in a usable fashion.
Oops. Looks like you should have run some use cases, and right from the start.
Critical information always lies buried within the details of use cases. If that information isn't triaged and surfaced properly to the client and your developer, you can totally bollix a big project.
Good design is the enemy of great design.
This isn't to say that good design gets in the way of great design, since the latter is only possible when surrounded by the former. But our hardest struggles as designers emerge when we confront what could be great, rather than what is thoroughly good.
Roads lead to alleys. Alleys lead to dead ends. And you can't see them all before you've entered into a client engagement—no matter how much of a "design expert" you say you are.
"I've done a ton of logos, so this project is a cinch for me. In the client meeting, I'll share with them some design themes I've been exploring when drawing up my estimate. Just some riffing, really... nothing too serious that I can't back out of when the paperwork is finalized... It'll just help me land the gig."
What a bad habit. Sure, we get excited about the possibility of a new project and start sharing initial impressions that come to mind. But sharing your opinion like that—off the cuff—can be very damaging for the project you're looking to start, your long-term relationship, and the design profession in general. It belies an assumption that you are more important than the gazillions of people out there that form the basis of your client's design problem.
Let me provide a few examples.
Ideas conform to the shape they are provided. Thoughts in our headspace can be amorphous as a cloud, slow as a flock of geese in flight, or as potent as a lightning strike. When writing and drawing in our notebooks, sketches and words coexist in a rectangular prison, often creating friction due to relative proximity. But Post-It Notes are a peculiar beast, as they enforce the minimum detail for us to express the maximum idea. Add in a chisel-edged Sharpie and you can only fit five to eight words total, with maybe a little doodle.
So, why should you work with a pile of Post-It Notes instead of a notebook or whiteboard when trying to come up with a bunch of ideas? Here's a few reasons why...
Many designers invariably fall into a pattern when confronted with higher-order design problems and a very brief timeframe—say, thirty minutes or less. One designer talks, then the others listen. Then, another designer responds or shares their own new idea, the other designers listen, and so on and so forth.
Meanwhile, the clock is still loudly ticking towards a deadline—and the most important actions happening are consensus management. This is not the fastest way to generate the largest number of ideas possible. Working for speed, as opposed to inclusion of multiple points of view in a roundtable-style discussion, requires throwing ordinary meeting etiquette out the window. Decorum can stop creative thinking in its tracks.
So if you're going to work really, really fast to get great ideas out into the open quickly, consider working in parallel as a team. Here's nine guidelines for how it can be done effectively.
This weekend, I found myself—through the execution of what seemed like an easy challenge for my book—thrust into redesigning a Wikipedia page. In the process, I was dumbfounded by how many usability and visual consistency issues there are in the Wikipedia interface.
We spend a ton of time querying the Internet for details about everything from where President Obama was born to who directed the third episode of the fourth season of Buffy the Vampire Slayer. And more often than not, we're interested in the facts we're uncovering, not how the facts are presented to us. This is a shame, because there are major improvements that can be made by designers to how we present factual content that's meant to be consumed through the Internet.
Other sites, such as Usability Post, have done a thorough job of documenting a number of the major issues with the old interface, so I spent an hour correcting some of them in a visually pleasing fashion to show how, with a minimum of effort, a coalition of designers could rethink some of the key interactions on Wikipedia.
Recent Comments