The following is a glimpse into the way I have worked inside of Imagesmith for the past three years. It's lighthearted but filled with insights and focused solutions for our client. This conversation was between myself, two other information architects Mike Barnes and Erik Perotti (the VP of Development for Imagesmith) and the project manager Susan Down. The notes and witty commentary were originally written by Heather Hopp, a project manager for Imagesmith. I had just presented to the group the Heurisitic Evaluation I had recently completed, along with flow documents showing the Web application's current strengths and weaknesses. We were brainstorming how to go about solutions for the client long-term. Of course not every comment was captured - which kind of makes it more interesting ... M - Set expectations: what info you'll need and why -- too much info is needed up front.

M -- Limit amount of info to get results

M -- There might be a moment to narrow down the types of plans people are interested in, then get more information at the end, so not bulk of requested information is at first

M -- Wording used is confusing ("you" -- who is you?) -- some words are linked to definitions, some are just underlined.

M --Needs to be more handholding because it's a complicated interface and flow.

S - Get them to provide the least amount of information at the appropriate times

M -- Rather than having you file a random tax form, define what kind of businesss you are, have filed xyz status, etc.-- rather than force the customer to read through that, prompt the user and deal with it behind the scenes. This is fine, but people need more handholding, pre-warning to expect this.

E -- Is this symptom causing other things: people don't have confidence, if you're asked nitty gritty questions before you know it's viable you won't finish it; there are dead-end streets; people should do the minimum possible to find out they're not eligible.

M -- Those are good symptoms, but the larger issue is that she could call a broker, why is she going to poke around this web site to do the same thing: incentive is that it's easy, fast and free. Needs to be a stronger incentive to get into it. There's a sexier way to tease people into giving this information. They need to see information that they came here to see. All this prep work is a falling off for the users. The main reason she feels this way is that there is so much language that's subject to change -- people may wonder why they're doing it if the information might change, might not be accurate or even valid to them

S -- Deb saw an easy advisor path -- could go the easy way or the hard way; the problem is that you're setting up expectations about what people could get before they find our if they're eligible for a plan or not.

M -- If it turns out they're not eligible, give them the next best match and explain that, so they're not bummed out that they don't get the feature they're after.

S - What about not choosing an overall plan, but choosing elements of a plan?

M -- In terms of details, eligibility, etc. it would get really complicated.

S -- Through a simple flow show the customer a bunch of offerings, then when they find a plan they want, we still have to tell them, "we still don't know if you're eligible for this plan or not because you haven't given us all the needed information yet." Mike's talking about bringing this information forward as soon as possible.

M -- Cursory information might inspire someone to do the more detailed work. If they lose 20% of people right off, does this pay off later? Is there a high retention after this? Where is it valuable where someone commits? Weigh the falling-off places in the site.

M -- It's all about expectations: if the customer understands that they're going to have to do some work to get to four valid policies, then they know what the carrot is. What it boils down to is expectations need to be improved.

E -- Problem with entry of information, another thing is you can invert this, and say these are the things that are important to be, and prioritize it: like chiropractic is more important than copay. So those are the decisions first, then get to things that are less and less predictable . If the system knew up front that you wanted chiropractic, then the system could deal with that first off.

M -- That's more of an advisor flow.

E -- Yeah.

M -- We're flaccid. Bring the menu of options up to the front, then bring the paradigm down.

S -- Fill out the stuff that people want to know about "yes, we have 3 policies that cover chiropractic, keep going to see if you're eligible for them,"

E - Or if you know chiropractic isn't available, you know right away instead of ten screens later.

C -- The sooner you show them what their options are, the longer they'll stick with it.

S -- Maybe we can't show them pricing yet, but if we can show them benefits then they'll fill out the information. Right now you have to have faith that you're going to get something of value at the end of a long process.

M -- I'd like to talk to a group of Kahlils [reference to our own HR manager] to see how they would use it.

S -- That's exactly what we need to do.

M -- Maybe all they want to see is the copay information.

M -- Within the context of this job, was our assignment to blow the box or to enhance usability of the existing system?

S -- Blow the box. We're here to give them the broadest possible options that we can muster. We're going to come up with a whole bunch of stuff, and we're not going to able to accomplish all of that within the existing time frame for phase 1.

E -- As you're making rec's for this phase, think about how to package it so one phase leads to the next. All phases should have necessary things that lead to more exciting and robust stuff.

SD -- If we kick ass on the SMB site, then we can do other work on their whole site.

M -- say: here's what we can do, here are the larger problems we can work towards

M -- It's a mosh pit.

E -- Phase one should be the simple stuff and the fun stuff.

M -- The hard part is the "prove it" moment -- prove that this is a good idea, that it's worth it to us. That's best done by bringing the customers into the conversation.

S -- I want more ideas -- we've talked about the problems -- how do we solve them?

E -- Maybe what just happened was a cry for information. Is that fair, Mike?

M -- That's fair. Context is everything -- maybe there are things in, like, Quicken that would work well here. These kinds of solutions are tricky without having approached the problem more clearly. It will be easier for me to bring in rec's after I do the audit, and have a chance to think about what's bothering me. We have to keep stuff up at a macro level. Expectations need to be set.

E -- The solutions we have so far are specific to things we have observed. There's some stuff outside of what we can see and respond to on the current site --

M -- This is triage.

E -- What's that?

SD - It's when you take care of the bloodiest person first.

M - Dude, didn't you ever see M*A*S*H?

SD -- So what's killing the site now? The time that people put in?

E -- I think these are incidences of similar problems that don't appear on the site. Right now we are on a 1-1 relationship: here's the problem and here's our solution. Maybe there's a single problem, with a spiral of solutions. We're missing other things, on a higher level. Is it a credibility problem?

Then Erik did one of his graphics. They're getting more legible all the time. They usually involve three lines and two circles, in varying relationships with varying amounts of text. This one was no different, except for the increased legibility. Then he said, as usual, "I'm not saying this is the right question. Maybe it's something else."

M -- Like we say "this is adding up to be an education problem", or "this is turning out to be a usability problem"

Then Mike jumped up and did an equation, which was surprising. His equation was in brown, which complimented Erik's orange graphic in a 70's restaurant kind of way. It started as a mathematical equation, xy and then z, but the legibility decreased quickly .

Erik seemed to understand his graphic, and expanded on it with a purple marker, then drew a lower case "f" with wings near it. In purple, again.

[SD appears to be understanding this.)]

SD -- It's a tour moment.

M -- It might be the double A! (Points to the illegible brown graphic.)

Then everyone agreed to what they talked about in the first five minutes of the meeting, in that they wanted to get rid of steps and tell users first off what they should expect.

E -- Let's look at what's deeper, and that would give light to some more obvious problems, and then get into something that's deeper.

M -- Given the course of our work, let's say "here are the problems and here are some ideas about how we can solve them" but speak to the bigger picture of more problems; that means more than an understanding that we can get in this project.

S -- (to E) -- How do you feel about what Mike's talking about -- that we can give them something now, but will speak to larger issues?

M -- It will be important to document to them that they need to pause and think about the bigger issues before they blindly adopt the new SBG to the various pathways.

SD -- This phase of the project, we're just looking at the SMB site.

M -- I think that now we can plant the seed [...]a lot of questions were asked that lead to larger issues that should be addressed in future phases of this site. The paradigm of getting the information up front may not be the person user paradigm. We need to subvert the dominant interface. We need to wage usability. They brought in The Wolf to hose down the car. But that's not what we see as the problem; what we're doing is limited -- it's a micro-macro issue.

© 1998–2007 Scott Robinson