19:
At InsureMyTrip we’re finishing a four-month project adding filters to our product search results (cool project, long overdue). I’m project owner, manager, and design lead. We’ve finished formal QA and are in pre-release acceptance testing. And we’re on schedule.
That’s good, but what’s great is the fun we had during the design cycle. I picked the team and got good people from Customer Care, Dev, QA, and User Experience. And the project team was the design team. And the design team rocked. Arena style.
Debra, Wayne, MikeD, Andy, Hristo, and I had lots to talk about, with our different backgrounds, and we all respected each other. Which meant we iterated designs quickly. Tested. Redesigned. Talked through problems. Made better designs.
In today’s launch plan meeting, I was a bit distracted, figuring out how I’m going to get these people on my next project.
creative commons-licensed photo by Flickr user aresauburn™
17:
At my current employer we’ve spent the last few months getting ready to replace our homegrown ticket system with something more able to handle the more complex organization we’ve become. The project has evolved like most projects: Talk to users, analyze needs, document requirements, find contenders, evaluate contenders with users, and select something within the budget. Or almost within budget, if you’ve got a good case.
One of the hardest things for the project team to talk about was our maintenance production process. Over the years, it has evolved. We’ve tried to keep it simple, but it’s complicated, given the range of problems being solved, all the different people who may work on any given ticket, and the overlapping cycles in a two-week schedule. One of the complexities was the different paths and routes a ticket could go and how those different paths fit on the regular schedule. To better understand the workflow and timeline and our users’ needs, I created a diagram:
Overlaying the non-linear workflow on a linear timeline was a challenge, but it helped us understand the complexity. We didn’t have to rethink it each time.
We ended up selecting Jira, by Atlassian for our ticket system. It has the right features and configurability, and it integrates well with the new intranet platform we’re standing up (Confluence, not coincidentally also by Atlassian). We like the products, but of course the problems you’re solving are different from ours. Your diagram will be different. But you knew that already, didn’t you?
04:
We needed a new coupling for our KitchenAid blender. I wanted to make sure I had the right part, so I went to the KitchenAid site. Here’s what I saw:
And then:
The word cycle on the right includes “mixing,” “whisking,” “loving,” “tasting,” and “bonding.” It’s cute, their mixer is an iconic design, and the word cycle delivers all the right warm fuzzies for their brand.
I grabbed 10 screenshots while I was waiting. I could have grabbed at least another 10 before I got to the site content, I think. I didn’t stick around to find out. A coupling is a cheap part so I could roll the dice.
What I remember about the site, well after the cuteness, is that it wasted my time. I don’t mind Flash in sites. And I’ll wait a long time for a Flash-based art or info visualization site to load. But if your site is about content that doesn’t need Flash, please don’t make me wait. Chances are I won’t.
11:
Here’s a devious twist on trained behavior. In the normal confirmation dialog, you click Cancel to back out of some action you don’t want to do:
Out of curiosity, I clicked a sales-pitch link from a Google search I normally wouldn’t. When I clicked my browser’s Back button, the following confirmation dialog appeared:
This is devious in several ways:
- I clicked my browser’s Back button. I didn’t click the Oh Please Show Me An Annoying Pop-up button. I just want to see the previous page, nothing else. Now I’m unhappy.
- Cancel/OK buttons are confusing enough on their own. To receive a discount I click Cancel? I thought clicking Cancel would stop what I didn’t want to happen. Will clicking OK infect my laptop with leeches?
- Cancel and OK are in most cases bad names for buttons. Use descriptive verbs, such as “Yes, leave this page” and “No, stay here” (of course, you’d have to fake a confirmation dialog to control the button labels).
- Don’t make the selection I most likely don’t want the default action. And don’t give the buttons equal visual weight.
Okay, they’ve designed it to confuse me and keep me on the page and they must catch some people. So it’s effective design. But it’s not at all good.
02:
My wife Mehera bought a candle and when I opened the tube to smell the candle, I smiled. In the tube on top of the candle was a matchbook, with the candle maker’s logo, of course. In our house, we don’t light things often, so finding matches isn’t always easy. Big Dipper Wax Works made it easy.
Big Dipper Beehive Candle
Last spring, I attended a workshop by Dan Buchner from Design Continuum in which he discussed and had us design the out-of-the-box experience for a media player. One of the points I took away is that experience design, like most other design, works best when you don’t notice it. You’re too busy smiling.
07:
A few years ago, I redesigned several calendar interfaces for the Boston University community of more than 40,000 people. It was a good challenge, given the large audience and the range of user profiles. The main objective was to improve the user experience, something there wasn’t time for in the first release. My project roles included user interface designer and project manager.
Some improvements I designed included
- fewer fields on event displays and submission forms
- more logical field groupings and group headings
- client-side dynamic elements, showing what’s needed only when it’s needed
- simpler and more scannable search results
Click any of the thumbnails below to view them full size, or you can peruse (“peruse”!) the Calendar 1.1 project site on the BU Web.
28:
Okay, right: I didn’t really solve that problem. But I did lead a project a few years ago at Dynamic Diagrams, defining the information architecture for a new website for the Forum for Global Health Protection (now Emerging Health Threats).
The analysis phase included user interviews with doctors, researchers, and other stakeholders. One thing most interviews had in common was how they thought about the knowledge: by named threat, by health field, or by global region. We made sure to incorporate a tagging system in the CMS and highlighted those facets in search, including combined searches.
To explain the site’s architecture, we created a diagram. The big yellow-orange cube in the diagram represents the knowledge facets and how users can access knowledge by single or combined facets, in 3D: by layers, rows, or single cubes.
BIG NOTE OF CREDIT: Kim Looney of Dynamic Diagrams did the stunning visual design. My role was to define the requirements, define the architecture, and manage the project. Second note: It’s a large PNG file and may take a few seconds to load.
Click to see the detailed view. It may take a few seconds to load.
The purpose of the site is to share information about emerging health threats from pathogens, chemicals, and the environments (natural and human). That’s what the site’s architecture is doing.
rss feed
