The Ultimate Unit Test Failure

When I start seeing actual numbers from an Interactive Designer, such as what % of users can solve their test cases. Then we’ll become great friends!

See that? Right there. The whole "It must have a number target that we can obsess-compulse about!"
That’s the 50 foot marshmallow man talking.
Trying to put numbers on human competence is hard. Does mildly annoying count as half a virtually unusable, or a third?
Not to mention that the whole point of interactive design is to make sure that the user doesn’t have to “solve” anything.

You make it sound like low-level, internal testing is an activity mutually exclusive of high-level, external interaction design.

They both are important and one shouldn’t be done to the exclusion of the other.

Would you buy a home that had a beautiful design, great layout and flow, tasteful treatments and decorating, but the internal framing, plumbing and wiring was shoddy and broken?

I’m with the folks that think this is a pretty poor post. It looks like Jeff may have submitted a first draft with the ideas sketched out but not fully thought through.

Perhaps we should ensure that we begin writing the user help material whilst the interaction design is still in progress, and bring the document authors more fully into the design process?

Whilst I realize the sad reality that the documentation will rarely be read, it can be an easy way to spot an awkward design when a specific section of a user guide becomes overly complex.

What? Posts on “focus”, “password reveal”, and now this?

It’s nice weather in the Bay Area, go for a walk, ride the merry-go-round at Tilden!

Ooops, merry go round is closed for renovation. :frowning:

http://www.ebparks.org/news/12272007

Actually, Jeff’s point is further proven by many of the comments bitching about the quality of the post, whether it’s accurate, or what the effing semantics are.

Come now.

The point is that most developers miss the forest for the trees. We focus most of our thoughts and discussions on the intricate things we (rightly) do to ensure technical quality, and very few on the core issue of quality user experiences.

He’s not saying don’t unit test, pinwads. He’s saying do that, but all of us probably should be more focused on improving how we build software that users love than we should on writing code that all greens.

We’re collective decent or at least interested in one and (trust me) we don’t even have a clue about the other.

Jeff is right on the ball here, and I’m disappointed (but not surprised) that so many people are not merely disagreeing but attacking him for presenting the point.

You can create a meticulously tested, 100% correct application that is nonetheless a piece of junk that nobody would want to use. It happens all the time. More insidiously, you can create a highly-tested and reliable application which solves an important need and is heavily used but does it in a way that makes it frustrating and painful to use. It does not cut it as a rebuttal to claim that “most programmers” only write the server portion of the code, or that the UI designers will magically make all the user interface code appear, no doubt with the help of the good UI fairies. It takes programmers to write it.

I’d like to recommend a book which does an even better job at getting the message across. When I was hunting through books on interaction design this past fall, the best one I found was a href="http://www.amazon.com/Sketching-User-Experiences-Interactive-Technologies/dp/0123740371/"iSketching User Experiences/i/a by Bill Buxton. Rather than simply preaching at you about how UI is important, it preaches and ithen/i shows you what the role of prototyping or “sketches” are in design, shows you why it’s not adequate to do just one sketch or prototype (virtually guaranteed to have everybody it’s shown to grunt reluctantly “yeah, I guess that would work”) and then gives you a bunch of techniques you can use to help work up UI design sketches, with or without programming. If you’re only going to buy one book on UI design, I’d recommend that one. If you’re only going to buy two, I’d recommend that plus a href="http://www.amazon.com/GUI-Bloopers-2-0-Interactive-Technologies/dp/0123706432/"iGUI Bloopers 2.0/i/a to remind you to stay clear of the “obvious” mistakes that virtually every programmer and every company make over and over. (If you’re going to buy 3, add iDon’t Make Me Think/i or a href="http://www.amazon.com/About-Face-Essentials-Interaction-Design/dp/0470084111/"iAbout Face 3/i/a.)

There are developers and developers, designers and designers.

I have bumped into interaction designers that created dark-gray with brow text UI that you could not read on Windows. Because they designed the UI on Photoshop for Mac. But a Mac is not a PC, and Photoshop has 5 smoothing options of text rendering, none of them matching the OS ones.
Or asking for fonts that don’t exist on a typical machine, and don’t support any foreign language.
As user, I have UI font preferences as a global OS setting. If one designer wants to force a certain font on me with owner-draw stuff, I hate it. And no quick keys (most designers are mouse types).

As developer I am ready to implement 100% of the design, as long as the guy is really UI designer, not just a poster-creator-moved-to-ui-design-because-this-is-where-the-money-is.

Aren’t you mixing here two absolutely different things: 1) the market potential of particular software, i.e. WHY something should be done; 2) code quality assurance of particular product, i.e. HOW something should be done?
IMHO, Test-driven development is a nice way how to (at least try to) ensure the 2), it has nothing to do with the 1).

java beats c++…

hahahahaaa…

We’re constantly asking for permission from the folks who shouldn’t be in a position to grant permission. We should be working with business folks and marshaling the technology to meet the solutions to business problems.

The simplest solution to the above is to start cutting code. And why shouldn’t developers be in the position to grant permission? The statement contradicts Alan’s earlier sentiment about interaction designer being a facilitator, not authority figure.

And why do developers need to communicate through intermediaries with their stakeholders? This will ensure developers drift toward irrelevancy - just look at Microsoft being taken over by sales all across units - it’s no longer a developer company.

And lastly - yes developers should learn about user interface design and pass the most important test (not unit test - apple and oranges) - user acceptance. Honestly - computers are much harder than all these soft skills; if one can master computers, one can master UI designs and can manage the communication (although it can be vexing).

The forest here is - pick up another skill besides working with computers.

Wow, that’s one big fat bald guy selling snake oil. Love the hand gestures.

Err … what? Oh yes. Code coverage – completely pointless, unless it’s done in an academic environment with some stupid language like Z. You want that to work? Try a functional language. (I don’t program in a functional language, partly because nobody asks, but mostly because it makes my head hurt.) Doesn’t work unless you can guarantee no side-effects.

Unit tests, yes, yummy. We used to do those, back in the days. Then we did integration tests. Then we did acceptance tests. Now we have Professional Testers. These people are Good. On the whole, they don’t have a clue how the system works, and they’re not very useful when it comes to explaining what went wrong. And they couldn’t rewrite the code if their lives depended upon it.

But that does save me, and countless other thousands of programmers out here, from having to write requirements, test specs, tests, and automated scripts built off scraping last night’s SVN update. For that, I thank these people.

I never wanted to be a know-it-all, anyway.

“unit testing is used for checking code quality.”

No, it’s not, Jan. Unit testing is (with luck, spit, and the wind behind you) designed to show that the code works. The quality is entirely besides the point. That’s let until later; or, hopefully (and rarely) earlier.

That’s why we call them Unit Tests.

Do you see my point, here?

If not, do you look good in stockings, high heels, and suspenders?

“We’re constantly asking for permission from the folks who shouldn’t be in a position to grant permission.”

Sorry, but that’s crap. An interface designer shouldn’t be able to add interface elements at random any more than a salesman should be able to sell products we don’t provide (which our salesmen do regularly.) It’s counter-productive at best when you have to go back and recode things for new interface changes, and then send out non-tested code? What, the user experience is somehow better when none of the features work?

Frankly, if the software has gotten that far and the interface is that broken the design was bad in the first place.

Agree with the spirit of the post, if not the actual practice. I take interaction designers more seriously if they have some practical knowledge of the underlying technology. I’m primarily a web developer, so when I ask an “Interaction Designer” if what they’re asking for is an HTML Select element, I expect more than a blank stare back at me.

Many of the comments (above) regarding Jeff’s thought’s make Alan’s point, perfectly.

Interaction design/UAT is nothing at all to do with unit testing. They are completely orthogonal practices.

Whether the users want to use your app is not any sort of unit test, let alone the ultimate one.

@Steve Campbell,

Yes, I’ve seen a user interaction person “in the wild.” We call them UX (for User eXperience.) I’m team lead on a new project and met with UX and documentation to introduce them to the project – on Monday or Tuesday I’ll get estimates from them and will go to my management to ensure that we have budget. Then someone from UX will be assigned to my team.

Other than some cheesy prototypes to prove a concept, no code has been written on this project yet.

The negative camp is complaining about how the point of view is presented.

When I read the byline, I thought this might be about something exciting. A shuttle disaster where we were presented with a cautionary tale about something related to Unit Tests? A coding horror perhaps!??!

Yet, Unit Testing has NOTHING to do with this post, aside from being used as an inflammatory statement used to draw people in while some proselytizing goes on and we’re all told to go hug the next UI designer we come across and say sorry. Shame on all the commenter’s who got sucked in to saying anything about UAT or Unit Testing.

  • Don’t think about how people use your software. It’s not in your job spec.
  • Design complicated things that people can’t use without formal training.
  • Make your software incredibly complex so you can brag about it.

If I was jaded and cynical, I would think that the posting style is meant to provoke people commenting just to increate site traffic.