Friday, November 16, 2012

Design Critique

I had the pleasure of participating in a design critique panel this week for a class at the University of Minnesota's School of Design. Seven groups of students presented their screen wireframes for a scheduling application for Emergency Medical Technician students.

There was a wide disparity in preparation and design artifacts presented. Some of the student groups had clearly thought through many possibilities, while some seemed to be gaining clarity on the scope of their effort. There were digital prototypes and pencil sketches, with varying degrees of fidelity.

What I learned from them:
  • There are some really creative, thoughtful designers coming up in the industry. It was fun to see the different approaches for the same problem.
  • Presentation preparation can really make the difference in acceptance of ideas. There were some great ideas that were not presented well, either visually or verbally, and the lack of preparation was a real drawback.
  • Some of the groups seemed collaborative, but several seemed to be struggling with consensus within the team about the best design approach. This is a real drawback in presentation, as well.
  • While I am a proponent of rough sketches (especially in the Agile world where I work), the people who had high-fidelity wireframes were often easier to understand and follow. It's always a trick to find the right level for the timing of the conversation. It may be that they were farther along in their thought process, as well, and therefore better able to convey the concept.
  • If you are designing for a specific platform, you need to understand design conventions of the platform.
  • The students were good at defending their choices. It's important to have a reason based on research, even if you change your design later because it doesn't test well.
  • A defense based on their own conversations with users would have been more compelling, but no one mentioned what they observed, or knowledge of the data, as being a reason for any design choice. Effective designs aren't based on heuristics alone; you need to understand the domain, users, and usage scenarios as deeply as you can.
  • If you don't take notes during a critique, it appears you don't value the input of the critic.
  • I would like to do design critique for a living. Wouldn't that be fun?



Monday, October 29, 2012

Initial Thoughts on Windows 8

I haven't been a Microsoft early adopter for a few years, so I hadn't seen Windows 8 until yesterday. The jury is out, but here are some initial thoughts:

Dislike:
  1. Things are a little too hidden. It's not always clear how to find familiar functions; for example, I still can't figure out how to change display settings. For a tinkerer like me, this is hard to get used to.
  2. Oh, wait--there it is. "Your PC can't project to another screen". Oh, well.
  3. The contextual search isn't second nature for me yet. I like the idea, but I haven't embraced it mentally yet. It requires two gestures to access (move mouse to upper corner, click the magnifying glass), which may be my barrier.

Like:
  1. I do like the simplified interface (even though things are hidden). The home screen can be customized.
  2. Easy upgrade process: My old apps can still be accessed in a Windows-7-like "desktop" user interface. At first I was disappointed that it appeared to be a shell on the old OS, but now I'm pleased with the compatibility.
  3. App store model: The app store model has become like the Apple or Android app stores, and it's really usable and easy to install applications that are compatible with the operating system.
  4. Messages I've seen so far are in plain language. I think my grandmother could've figured this out. (Yes, I know--Apple probably did it first, but MS is doing it well.)

Love:
I installed Windows 8 on a 7-year-old tablet laptop ("No!" you exclaim. "Yes!" I reply.).  Though I'm sure it's missing some wicked-cool new features that I will discover soon (oh, yeah, can't use dual monitors--yet), it's running, frankly, pretty great.

Saturday, October 20, 2012

Tuesday, October 16, 2012

Designing for Simplicity


Good article on designing for simplicity, by Rob Tannen, on Designing for Humans:

Some points I found interesting:

“Research by Accenture…found that only five percent of returned products actually have a malfunction – in many cases, the buyer has simply found them too complex to set up. Another study…found that the average U.S. consumer spends only 20 minutes trying to make a device work before giving up and returning it.”

He makes a great point about automatic improvements, using the example of automobile transmission: the example shows how complexity of the gear-shifting task was moved from the user (manual transmission) to the system (automatic transmission). Technically, though, automatic transmission is much more complex a system in its design. (In other words, design of simple interfaces isn’t simple.)

“In other words, what the end-user wants isn’t simplicity per se, but a simple way to access complexity.”

When we are challenged to do things like other companies known for their simple interfaces (such as Apple), we need to remind ourselves that it’s a lot harder to do that well.

Thursday, September 27, 2012

It's rarely just a simple checkbox

My client said today, "We want to add a simple checkbox to ask the user [another question]."

Okay...let's see how simple it is!

Q: Do the users understand the wording of the question?
A: Not sure, but they should

Q: Where does that answer get stored in our destination system?
A: Nowhere, today

Q: Does the system storing the question have the same development cycle as the front end?
A: Nope

Q: What do you do with that information?
A: We would like to send it downstream to another group to save them time, but otherwise, it's not part of our core process

Q: How do the users provide that information today?
A: Using a different system that is part of the downstream process

Q: How does it differ from the [similar question you already ask]?
A: Not sure, because we don't know why we ask [similar question]

Aha. So, our simple checkbox needs:
  • Design specification
  • User testing
  • Development
  • QA Verification
  • Integration analysis
  • Release planning across systems
  • Destination system revisions (design, development and QA verification)
  • Downstream system revisions (design, development and QA verification)
  • Education and coordination with other groups
  • Process changes for the users
...and may not even need to be asked to begin with.

Simple!

Monday, September 17, 2012

All your system problem may belong to us.

In reply to an e-mail I sent explaining I could not order from a web site:

So, in other words, we aren't saying the system does or does not have problems. But we're fixing them.

Wednesday, June 13, 2012

Innovation vs. User Research: SMACKDOWN

So, it seems I’m inspired to do most of my writing around--or as a result of--some dumb user experience or annoyance I experience at work or in the real world. And….so….well, here is another.

On the heels of a pretty-darned successful, highly visible project in which user research activities were very prominently integrated and featured (and just when I think we are getting past the point of having to explain what we do), I am blind-sided by yet another opportunity to educate people whom you’d think would know better. So, here we go.

There seem to be some misconceptions about user research:
It is at odds with innovation
It does not impact the decision about a solution
It hinders iterative design and development
It’s not needed for iPad apps, because they’re innately brilliant

Two common ideas keep fueling these misconceptions, generally from managers who read books that managers read. “Steve Jobs didn’t talk to users,” and “Henry Ford said that if you ask people what they want, they’ll ask for a faster horse.” These are well-known examples from peerless visionaries who drove innovation in their companies. And they are--indisputably--excellent, inspirational quotes to foster innovation thinking.

Here’s the rub: The realization of the products they envisioned, and all the ways people use them, did not happen solely due to one person envisioning it. I know—that sounds obvious, but here’s what I mean: Steve Jobs may not have talked to users, but Apple has some of the best, most well-respected user research groups in the world. So do many respected design leaders, including Sony, Microsoft, HP, Google, and my all-time favorite example of excellent user experience work, TurboTax. TurboTax is not great solely because some brilliant guy sat in an office and designed it, and neither is the iPad. It is great because of its design, yes, but also because of how application designers have understood the domain and usage scenarios of the users of the devices. Without that understanding, the device would be a beautiful, useless object. User research and innovation are not at odds; they go hand in hand. A product will not be successful with only one of those in place. They are partners.

I agree that, in general, users should not drive the vision for the products we design and build. But if we are not providing an opportunity for our users, or solving a problem they have, it will not fly. We don’t talk to users to ask them for permission or ask if something might be useful. We talk to users to understand their world, to walk in their shoes. We talk to users so we can ensure our design effectively either addresses an unmet need, or opens the door to an unimagined opportunity, in a way that supports or improves what they do. That does not prevent us from being innovative and creative, but it helps us to get inside their heads to support and validate our innovative vision.

Innovation and user research work in concert to create some of the most innovative and user-friendly devices known to man. A single person, even the most brilliant mind, cannot possibly anticipate every use case for a product. (And we’ve all seen very poorly-designed apps on the Apple Store and Android Market, now haven't we?)

User research does not hinder iterative design and development (or any design and development, for that matter). In fact, it’s quite the opposite. As a colleague of mine says, “You pay now, or you pay later!” Well-timed and appropriate user research can make design and development more effective, and reduce cost of user acceptance testing, future enhancements, deployment, training and support costs. You know the old adage, “Measure twice; cut once”? Too often we don't even measure once.

When we draw a conclusion without knowing what problem we are solving, we risk traveling down a “path of very expensive return”. 15 years ago, everyone said, “We need a web site!” but I rarely heard anything about who we were serving, what problem or opportunity was being met, or why. Now, the chorus is, “We need an iPad app!” But the same questions still apply. Why do we insist on providing a solution without a problem? An answer without a question? We need to understand what we are trying to accomplish before we build.

One of the reasons I like iterative design and development is that you can bite off chunks of the problem and validate the solution with less investment (potentially down the drain, if you find you’re on the wrong path). You can also course-correct more effectively. Big reveal: User research enables the same thing! You can find out early on if your vision is on track or just blowing smoke.

Let's read beyond the sound bytes in our management books. There's no one prescription for designing and developing a solution will be successful, but using proven practices is a great place to start.

Friday, March 30, 2012

Perception

Another cool human experiment. Can you figure out the key to what these represent?



Small visual cues can be very powerful, which explains why caricatures are effective.

(I couldn't find the original source of image to give credit; will do so when I track it down.)

Thursday, March 22, 2012

Superfluous Signage

Seen on a revolving door. Not sure what it means. I assumed it meant I needed to push the door. It doesn't.

Elevator

I'm at the Hyatt Regency New Orleans for the IA Summit. The most common topic of conversation seems to be the elevators in the building. They're interesting, because they are controlled by programmable soft keypads which can be changed by the hotel for whatever is going on. You scan your room key, and the pad tells you which elevator will take you to your room. No buttons to push on the elevator.

It's cool, because:

  • It's flexible and programmable
  • There are no buttons to push
  • It increases guest security
  • It seems to improve the flow of traffic


It's awkward, because:

  • Certain banks sometimes go to certain floors, and they change.  You find out whether you won the jackpot after you scan your key.
  • There's no signage. 
  • There's no signage telling you to scan your key, so people mill about, trying to understand what to do
  • People who don't understand sometimes get on an open elevator which has no buttons, and end up on a floor where they don't belong.

My conference is about information design, so it's not surprising (but still amusing) that there are several hundred people available to critique the user experience. Including me.

Monday, March 12, 2012

Mobile web design

Good post from designm.ag regarding mobile web design:


http://designm.ag/tutorials/tips-for-designing-a-compact-website-layout/


I have one beef: he mentions how to disallow user being able to pinch to zoom using an attribute in a viewport meta tag: user-scalable=no

I must say: this is my main frustration with "mobile-optimized" sites--when the designer doesn't allow zoom. I don't understand why you'd ever want to do this, because often users zoom because you made the font too small. It's an accessibility option granted by the default software that you are overriding to preserve your design.

"That's your opinion," says the designer.
"Yes, it is, and I'm your user," says me. "If I can't read your site, then your design is moot."