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™

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?

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.

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.

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.

A recent discussion led me to create the following diagram:

• The mission
• defines ↓
• business objectives
• which inform ↓
• programs
• that define ↓
• products
• updated in ↓
• releases
• that are built in ↓
• iterations
• composed of ↓
• features
• divided into ↓
• tasks
• assigned by ↓
• tickets.

Big caveat: This diagram represents an ideal state. We don’t develop products using Agile (yet). Some of the levels are not so smoothly connected. And we don’t even all agree on the language used in the diagram.

The “task to ticket” step might be not be necessary, but in our environment we have people who are focused on the ticket system as the thing needing changing. So we’re doing as the Romans.

All the same, this diagram can help us be more efficient:

The most interesting concept in the diagram is traceability. The traceability is both ways; there should be a second set of arrows pointing up. Because there are established relationships, tasks must meet objectives. If you can’t connect a task to a requirement to a feature to an objective, don’t do it. Less waste, better productivity.

I’m the product owner for a six-week project that we’re having to pull off without much availability from Development, because they’re tied up tight in a massive redo-our-entire-backend-system project. The scope for our six-week project isn’t that large, but one of my direct reports, Hristo, and I are having to take on some development tasks. And we’re most definitely faking it.

While he’s a talented graphic designer, Hristo is in over his head with some of the JavaScript programming (but he’s swimming just fine). The two of us have had to architect some logic that we would normally get from Dev. On top of that, because we’re taking some new approaches with managing the project and I insisted we take on more than the original scope (so we could make a better user experience), we have the eyes from above upon us. It’s a little bit of pressure. Like putting on a skintight, polka-dotted suit and pretending to be a superhero with 50 cameras rolling. It’s also a little bit of fun.

My immediate thought was to add a secondary email address field. It’s what you see in most cases. Our development group complained and rightly so that it’s never fun entering the same information twice and that at least some number of users just copy and paste the address anyway.

After thinking some more, I came up with what I hope is a more elegant solution. After the user enters his or her email address, a message appears in red repeating the user’s email address:

The solution depends on JavaScript, using the onblur event. For our site’s users, less than 5% have JavaScript disabled. One thing I like, though it’s subtle, is that the message explains why the user should review what they entered; they won’t receive their confirmation if it’s wrong.

• Add resume in HTML, Word, PDF, and txt.
• Add portfolio page: As individual posts? Can you make a page of just one set of posts? Or do I need to use an image gallery plugin? I’d like to use employers as a sub-category to portfolio, so someone can see the work I’ve done for each employer. Then I could tag regular posts as work for an employer. Add categories for sample types (e.g., requirements, ui design, usability testing). Can I sort the portfolio page by employer, date, or type? A sortable table with filtering. That would be cool, I think; have to test it.
• Add a Contact page with email form (Does WordPress support form submission via email? I’m guessing Yes.)
• Post a few more things.
• Test in different browsers and on Windows.
• “User” test with Mehera (at least).
• Migrate blog to root.
• Add social network icons.
• Add a dashing photo of dashing Chris Jackson.
• Implement Lightbox jQuery for thumbs.

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.