I have never seen a better thought-out job posting than this one. The person who can answer these questions will also be able to give .NET guy the "something different" he seeks in blogging, and will also be able to give Scoble the "killer app" he seeks for longhorn. Here's to asking the right questions. Unfortunately recognizing their importance does not in and of itself qualify me for the position. Darn.

By the way, what's a K-log?

comment []7:52:41 AM  trackback []   

It's very important to know whether your device is primarily multi-user or single-user. This is perhaps the primary design decision, with all other decisions branching out from that. The old 512k Macintoshes (otherwise known as "computers," since ibm boxes had yet to merit the title and were suffering under the weight of FoxPro and WordStar) presumed multi-user from the beginning. This mac did not come with a hard drive, so you carried all your files on a floppy. On shutdown, the computer automatically ejected the floppy. This is to make it available for the new user, who will undoubtedly have their own data or programs to run. Problem is, many of these macs were actually single user machines, contrary to design assumptions, making this flexibility an irritation. So: right design decision, wrong assumptions. Consider the opposite problem with CD players. Their assumption is single-user. The CD is not automatically ejected, and when restarting (your car, for example) the CD picks up where it left off. CD players are wrong about this with the same frequency: it seems there are tons of CD players in a multi-user setting. Windows XP assumes multi-user. An alarm clock assumes single-user. You get the idea.

As designers, what do you do if you just don't know about multi or single usage for your product. Or, if you do know, maybe you're not comfortable having the 60% majority win out and make the experience for the remaining 40% suck. With gobs of money and time, you can build your box and put it in the field, testing key parameters and logging the info. For the Mac, it could test what % of the time on booting was the same floppy inserted as last time. For a CD player, it could test what % the existing CD was ejected on startup. For XP, it could test what % was logged back in as the same user. For the alarm clock, it could test what % was the time set to a different time. This would tell you how to change your design to be more friendly to the realworld setting. But it still doesn't make things pretty if you're usage is tied, or 60/40.

The solution is to make your device be adaptive. Note: adaptive is not a mode switch. Nobody should ever include a single user / multi user switch on the device. No, what I mean by adaptive is testing for the pattern, then not ejecting the disk by default after the pattern is established. Or, ejecting it after the opposite pattern is established. Adaptive in XP is to log the new user in as Elizabeth Grigg automatically, then have a "Not Elizabeth Grigg?" item in the menu to switch. Adaptive in the alarm clock would be to have a magic "other time" button that sets the alarm to the most frequently used alternate setting other than current.

Pretend you have a toddler who wants to hear a CD. He has the CD in his hand, and wants to put it in the player. But you have to eject the old one first. He has no comprehension, thinks he isn't going to get to hear his CD. Destruction of property ensues, followed by a time-out. Why? No adaptability in the device. 

comment []7:36:08 AM  trackback []