112: UX is not an assassin cleaner

UX satisfaction testing’s annual project cost of $1,200 can save development teams 10 times or much more if used properly. It is the speed and accessibility that is most important.

Cheap/hacker results are better (even preferred) to what teams are presently being dished up –slow to no results. Meaningless philosophical drivel arrives too late to do any good. The team has secretly already moved on.

There is a resistance to using UX satisfaction testing in team development because programmer’s attitude is it slows down the process. (Oh no! Not UX again! Rain on my parade.) In reality, user satisfaction testing doubles the real-world efficiency. Agile cannot be productive without rapid feedback. That is proven –but no one is doing anything because they don’t know how to solve the problem.

I suspect one reason Agile fails to use UX is because they don’t have a decent tool yet. When they do, they will finally operate closed-loop. It’s a convenience issue. It has to be painless. What is presently available just doesn’t fit their workflow. It hurts to use it. It’s like starting a fire by friction –not near as much fun as a match and gas.

My goal/mission is to break down the resistance to good UX “inline”. Right now it’s done “offline”. UX “afterwards” for damage control, repair, and cleanup. UX is brought in like an assassin “cleaner” after a project’s gone wrong. Strategic UX is about avoiding failure in the first place.

Agile UX (rapid prototyping) must be more strategic than in the past –embedded into the actual development process like lean manufacturing checkpoints and quality control. It builds quality into the product as it’s built –not in final inspection. It has to be part of the team process and expectation. The cry of “We can’t live without it” is insistence value in marketing. I want insistence value.

Agile teams pay lip service to UX but are not doing it because it is “hard and frustrating” when applied. It requires too much thinking and then the results are fuzzy. They’d rather be coding. We can be just as fuzzy –but FASTER.

We are eliminating obstruction, fluff, and friction for concurrent UX testing.

They don’t really want a volume of data. They want quick judgments to guide the next iteration (2 weeks). It’s all about efficiency. That is something programmers can relate to –that is the need.

Return to Top ▲Return to Top ▲