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.
26:
At my current employer, I’m learning a lot discussing both business strategy and project management with my manager, a VP on the senior management team. We’re contributing to the conversation from opposite directions.
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.
22:
Just got home from a Providence Geeks meeting where the folks from Treanor Brothers Animation, a 3-D animation studio in Providence, talked about how they got started and how they work. On the way home I kept thinking about their footage of actors in black with marker dots all over the body enacting scenes for video game sequences. The phrase “faking it” popped into my head, not in the negative sense. I was thinking more about how faking it can be an art.
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.
19:
At my current employer, we’re undergoing a massive re-work of our main site. Mostly backend changes, but I was given the opportunity to refresh the UI as I brought the HTML and CSS more inline with web standards. On the major customer form page, we have an email address field. While interviewing our Customer Care department, I found out that the largest number of calls they receive are for people who never received their confirmations because they mistyped their email addresses.
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.
07:
To do:
- 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.
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.
rss feed
