Collecting user impressions
Submitted by Karen N. Johnson on Sun, 15/04/2007 - 00:18.
Travelling out to WOPR8 this week, I took a limo ride to the airport. Some months ago, I had written about my experience using the same limo service. I used this trip as a chance to check out how the in-car credit card processing system is shaping up.
I’ve now polled 5 drivers from the limo company because it’s helpful to talk to multiple users in order to gather a range of opinions. And even though this isn’t an application I’m testing, I’m curious to watch how the system and the changes are progressing from an outside perspective.
As the driver talked, it became clear to me that the new system was not designed for someone actually driving while attempting to process credit cards.
Here’s the process. The driver has to get the credit card as soon as possible. He explained to me that there are often issues connecting to the credit card processing server. The more tries he has to get the connection to work, the more likely he is to have my card authorized before the ride ends. After swiping my card, he follow the messages and menus that display. Once he’s done processing my order, he’s expected to watch the phone again – this time to get the details of his next pickup. And he’s expected to reply through the phone by texting.
The process sounds reasonable until you recall that he’s supposed to be driving while all of this takes place. As a passenger it made me a little unnerved how much he was reading the cell phone screen. It seems that his primary task of driving has become the background task.
Don’t get me wrong, I like texting as much as the next geek but I prefer texting with someone who isn't driving me to airport at the same time.
Did the designer consider the user for would be driving?
Do we get so caught up with technology and our ever-growing attachment to cell phones that basic design is a dropped call?
We shouldn't lose touch with our users. If it takes crawling into a car and hanging with drivers, we should hang with drivers. Each of the five drivers I've talked with tells me I'm the only person that has asked them personally what they think of the new system. Aargh.
One of the principles of context-driven testing is: the product is a solution, if the problem isn’t solved the product doesn’t work. I’ll add to this principal the obvious fact that if the solution introduces a new problem, the solution doesn’t work either.
I’ve now polled 5 drivers from the limo company because it’s helpful to talk to multiple users in order to gather a range of opinions. And even though this isn’t an application I’m testing, I’m curious to watch how the system and the changes are progressing from an outside perspective.
As the driver talked, it became clear to me that the new system was not designed for someone actually driving while attempting to process credit cards.
Here’s the process. The driver has to get the credit card as soon as possible. He explained to me that there are often issues connecting to the credit card processing server. The more tries he has to get the connection to work, the more likely he is to have my card authorized before the ride ends. After swiping my card, he follow the messages and menus that display. Once he’s done processing my order, he’s expected to watch the phone again – this time to get the details of his next pickup. And he’s expected to reply through the phone by texting.
The process sounds reasonable until you recall that he’s supposed to be driving while all of this takes place. As a passenger it made me a little unnerved how much he was reading the cell phone screen. It seems that his primary task of driving has become the background task.
Don’t get me wrong, I like texting as much as the next geek but I prefer texting with someone who isn't driving me to airport at the same time.
Did the designer consider the user for would be driving?
Do we get so caught up with technology and our ever-growing attachment to cell phones that basic design is a dropped call?
We shouldn't lose touch with our users. If it takes crawling into a car and hanging with drivers, we should hang with drivers. Each of the five drivers I've talked with tells me I'm the only person that has asked them personally what they think of the new system. Aargh.
One of the principles of context-driven testing is: the product is a solution, if the problem isn’t solved the product doesn’t work. I’ll add to this principal the obvious fact that if the solution introduces a new problem, the solution doesn’t work either.