« "Sufficient" color contrast | Main | Why it's so difficult to provide examples of good usability »

August 14, 2007


Feed You can follow this conversation by subscribing to the comment feed for this post.

I completely agree with you on the reality of the situation - in real life, raising problems without solutions is not a good career move. And I also agree with you (from your previous linked post) that everyone should see themselves as problem solvers.

But I don't think that things SHOULD be that way, because they are different skill sets. When the marketing guy says "We need to go after the mid-market customers" the response isn't "Yeah? Then go code up how we should do it." A real example of this from my own experience is that we want our test teams to feel empowered to open "usability" defects if they think there's a design problem. But we do NOT want them to design the solution to the problem (yikes). But if they don't suggest a design alternative in the defect, it gets returned because it is "working as designed". It's a tough problem.

Hey Joshua,

Good points! From my perspective it is all about context. The context determines what you deliver, even for the same services/products.

Here's some example contexts I'd been in. Each project included usability testing but had a completely different deliverabes:

- Large government organisation doing the work just prior to project completion for compliance reasons - They want a detailed report with metrics.

- An agency has limited resources and needs help with a short-term media project. The team is savvy and wants to get the project done - They want screen shots with call outs and don't care about metrics or why people made the mistakes they did.

- Large banking project with multiple agencies, IT vendors and internal stakeholders - You provide the objectivity and must justify your findings and recommendations so that they IT team and work out whether or not the changes to the Out of The Box system are worht the time and money.

- A new tech start up has a new application they are building and know they need to get it in front of users before they start building. They have a good dev team but not UX skills. Also, they have no money - After the usability testing they want a workshop to discuss the findings and sort out solutions straight away.


Thanks for the comments folks!

Terry, I feel your conflict. It goes back to a key problem with design: everyone thinks they can do it. Usability folks know better, but they still may be called on to mess with the design.

James, those are good examples that show how deliverables can differ in context, thanks.

After reading these, I was thinking the ideal solution probably is for the usability practitioner to be working closely with the designer. The team would collaborate on solutions and, when reviewing usability results with stakeholders, present good remedies along with the issues that were uncovered.

The comments to this entry are closed.