flow|state

Need an inexpensive designer for your project? Consider hiring a college student!

This past weekend I had a lot of fun giving a talk at StartupDay 2010 on the topic of user experience design in the context of a startup company. After my talk, I volunteered my time at a table in the advisory area, where lawyers, VCs, and various experts on others topics of interest met with new and hopeful entrepreneurs. I ended up spending time with four entrepreneurs, and three of them asked the exact same question: Where can I find budget design talent?

I really wanted to help these people get their business started, so did my best to come up with a meaningful suggestion. They all liked my advice, so I want to share it with you too: Try finding a college student to do your design project.

Photo: Matt Hintsa

There are a bunch of good reasons to hire a college student:

1. There are incredibly talented undergraduate and graduate students studying every form of design that’s out there.
2. They are looking for a job that pays better than part-time work in the campus library or a local restaurant, and so are willing to work for less money than you might imagine. (That said: Be fair.)
3. They want to build a portfolio. The extent to which your design project is actually interesting increases the chance the result of the project will look good in their portfolio. This portfolio benefit can translate into more motivation (and possibly willingness to work for less).
4. They can have drive and energy to spare.
5. Instructors want their students to work on real-world problems! I’ve been approached in the past by professors looking for projects for their students. They are farming out cheap (or free) labor, but don’t always know who’s looking for design work, and may not have local small-company connections. These engagements can come with particular constraints: the project probably needs to start and end within a given semester, you may be obligated to submit an evaluation at the end of the project, etc.
6. If the relationship works well, you can use them for future projects, or potentially recruit them. You may discover someone great before anyone else does!
7. This is a way of doing some good in the world.

The obvious downsides to hiring a college student for a real business project are lack of experience: specifically in the particular design discipline you’re looking to hire, and generally as a professional with business responsibilities. They may not yet have worked on a project for which failure can entail consequences worse than a bad grade.

It can also be hard to find a good student—it takes time to separate the wheat from the chaff—but if you’re on a  budget, it may be worth the extra time. And if you’re on a really tight budget, you may have no better option.

Reaching out to local instructors can be a good place to start; even if they don’t have a specific work/study project coming up (or one that matches your parameters), they may know current or past students that might be good for your project. These instructors can be found not only at the local college or university, but also at trade schools and other adult learning institutions.

Dear phone OSes in 3rd place and beyond: Please accelerate your demise

Cozi is expanding its family software to the mobile domain. We have a Cozi iPhone application, and are obviously looking at Android as well. The problem is what to do about Blackberry, Palm webOS, and perhaps Windows Phone 7. As an entrepreneur with friends at two of those companies, I wish good luck to those OSes in third place and beyond. As a designer of family software, I have a goal to address the needs of my users, and support whatever phone they find meets their needs. And as an executive at a company that makes mobile phone applications, I wish those OSes in third place and beyond would please die—and soon, if they wouldn’t mind.

       
Dear Blackberry, Windows Phone 7, Palm webOS: Could you all go away? Please?

As an ISV working on top of a platform, I want exactly two platform providers. Not one, not three, or four, or ten. Two. If there’s only one platform provider, the provider inevitably becomes arrogant and insensitive to the needs of the ISVs that keep it alive. Not three, or four, or more—those platforms can never get enough market share to make it worth your while. All they will do is produce enough users to make your life miserable with endless requests for when you’ll get around to supporting the OS they prefer, with its 3% market share. The only good case with the smaller players is if they can become commoditized, ideally in combination with the first or (more likely) second place platform, in which case their existence makes no difference to the ISV.

An ISV wants exactly two platform providers in any given space. The first one can be the successful one, with something like 70% market share. The second one can be the underdog, with 25% market share. From the ISV’s perspective, the underdog’s job is to keep the top dog honest, while maintaining sufficient market share to justify the ISV’s investment developing for that platform. Without the latter justification, the ISV can’t justify the investment, which means the underdog eventually loses compelling apps, and loses market share until they can no longer play a meaningful role as underdog. The remaining 5% of the market should be splintered among tiny players. None of them should have sufficient market share to create a compelling business case to the ISV, so the ISV can focus on the two players that really matter.

This effect has been demonstrated over and over again.

• In the golden age of personal computer OSes, the Mac had just enough market share to be worth developing for, which kept Microsoft honest. When the Mac nearly became irrelevant, Microsoft slowed its pace of innovation, and took forever to release Vista. Without OS/X nipping at its heels, it’s exceedingly unlikely that Microsoft would have gone on to produce a nice Windows 7. Thankfully, a personal computer OS is now largely a commodity whose greatest purpose is to run a web browser, and web-based ISVs can often ignore the space entirely.
• In the gaming console space, game ISVs resent Nintendo’s steadfast refusal to die. Microsoft and Sony can keep each other honest on their own. So, from a game developer’s perspective, Nintendo’s existence doesn’t improve their life, it only complicates it.
• When Microsoft maneuvered IE into a position of browser dominance, ISVs had no choice but to optimize for IE, giving Microsoft so much market power that they could ignore the call to adopt standards. When Mozilla, Chrome, and Safari eventually became clawed their way to being good enough and threatening enough, Microsoft finally had to get serious again about making IE good. In this particular case, web standardization has commoditized the smaller players, so as an ISV, I really don’t care whether Mozilla and WebKit both stick around. All that matters is that, collectively, they can force Microsoft to improve.

Now, the mobile OS space is increasingly dominated by iOS and Android. To an ISV, that’s fantastic news! The fewer players, the less work the mobile ISV has to do to reach more users. I’m really hoping Android manages to create a meaningful application marketplace and sustain fast growth. When iPhone was the sole high-end mobile OS of interest, they could afford to subjugate ISVs with completely mysterious and arbitrary rules for who could be in the App Store. With Android on the rise, Apple has been finally forced to open up a bit.

The mobile ISV wants to see that tussle between Apple and Android. But what would really make me happy would be to see those other guys get a lot weaker. The other mobile OS providers don’t weigh enough on their own, and hence can only serve to make the ISV’s life harder. Hey, you guys can all share that last 5%!

Form validation feedback: Be slow to complain, and quick to forgive

Anyone designing a form will eventually come across the problem of: 1) when to validate the form data which the user has entered, and 2) how to provide the user feedback on fields that don’t meet the validation criteria. Many approaches have been tried for the second problem, but I think the first problem—when to validate the data and provide feedback—could use more consideration.

Suppose you’re designing a form containing a text box in which you will ask the user to enter a mobile phone number. For a variety of reasons, you’ve decided that you want to perform some initial validation of the number to minimize the chance of later problems. There’s no easy way to ensure, on the spot, that the number is, in fact, that of a real mobile phone, but you can at least ascertain via some regular expression that the text looks like a valid phone number. (Er, have fun with that, especially if you want to support international numbers.) Your regex is quick to evaluate, but you need to decide when to evaluate it and do something with the result.

Here are some choices for when to validate the phone number, along with some pros and cons:

1. When the user types a key.
   
   Pros: The user will get the feedback as quickly as possible, and so they should be able to correct the problem immediately. Because they’re looking at the phone number field, feedback positioned next to the field will be noticeable. Because the user is thinking about the phone number, they don’t need much prompting to spot the problem. The keyboard focus is probably already in exactly the right place to fix the problem.
   
   Cons: It can be incredibly irritating to use a program which instantly complains about a problem which you yourself can tell you’ve made. If you’re reaching for the “1” key, and see you’ve accidentally hit the “q” key, you can see for yourself you’ve made a mistake. You don’t need the additional shame of being yelled at. A program that validates on a key press can act like the jerk in the car behind you who honks their horn the instant the traffic light turns green.
   
   There are also plenty of situations in which such error feedback is completely premature. Suppose the user is pasting in a phone number they’ve copied from their address book or some other location, and the pasted text contains some extra characters. The user can see the extra characters, and would be perfectly happy to remove them if only the program wouldn’t yell so loud.
    
2. When the field loses focus (e.g., the user has moved the keyboard focus to the next field).
   
   Pros: The user has had a chance to get the field text into the state they desire, so any feedback at this point is likely more warranted. Perhaps the user may not have noticed that they’re missing a digit from the phone number.
   
   Cons: The user’s attention has already begun to move on, so the error feedback may need to be more prominent. Also, while this technique is less hasty than the one above, the error feedback may still preempt the user’s own ability to recognize the problem. The user has to manually move the keyboard focus back to the phone number field.
    
3. When the user attempts to save the form.
   
   Pros: By pressing a commit button like Save, the user has indicated that they think they’re done entering data. If there’s an error at this point, they haven’t noticed it, so the feedback will be timely.
   
   Cons: By this point, the user’s attention may be far from the phone number field, so the feedback needs to be quite prominent. It may need to be supplemented by overall form validation feedback near the commit button or at the top of the page. Once the user sees that overall feedback, it may take a moment for them to visually reacquire the problematic phone number field, diagnose the problem, and get the insertion point to the point where they can correct it.

All these methods have their place, although in a situation like this, I personally prefer to defer giving validation feedback to the point where the user is attempting to save the form (#3 above). I’d rather give the user a reasonable chance to fix any errors, and have observed countless usability studies in which they have done so. I believe this leaves the user feeling in control, and to me this is worth the disadvantages listed above for this approach.

Still, there’s one common downside to this approach: applications that validate on Save tend to keep the error feedback visible until the user tries to save again. I find this annoying; it’s like the program continues to scold me even after I’ve admitted I was wrong and atoned for my mistake. Once I see the problem and have fixed it, I wish I could get credit for fixing it right away.

Asymmetric validation feedback triggers

There’s no reason the triggers for showing and hiding the validation feedback need to be symmetrical. I’ve been working on the idea of asymmetrical validation triggers: validate on save to show validation feedback and validate on keypress hide the feedback. In this scenario, the UI shows validation feedback (validation message, change field background color, etc.) if the user attempts to save the form with something that doesn’t appear to be a phone number. But as soon as the user types the key that fixes the problem, the validation feedback goes away.

The user is typing…

They mistype. The UI doesn’t complain; maybe the user will fix the error.

The user tabs away with the error uncorrected. Still no complaint.

They try to save the form. NOW validation feedback appears (with an explanation nearby).

The user clicks to correct the error…

As soon as they type that fixes the error, the validation feedback goes away.

In other words, the UI is slow to complain, and quick to forgive.

I think this is generally the proper conversational posture for a program to take regarding the validation of user input. Most programs treat validation feedback as if it were the user’s fault, when to me this feels like almost exactly the wrong spirit in which the view the situation. Data validation is a sign of program weakness — a sign that it’s still too hard to design a program that can process input flexibly and resiliently.

If I fill out a paper form that asks for my home and work phone numbers, I can fill in the first phone number and write the word “SAME” for the second phone number, and any human would process that correctly. I can even cross out the field label “Work” and handwrite “Cell” and write in my cell number, and again this is meaningful to a human reader. I can make all kinds of minor errors, and still my input can be interpreted.

That is a breathtaking level of input flexibility which no UI today can match. And so when a form has attempted to recognize user input, and failed to do so, the appropriate stance should be not, “Invalid phone number”, but rather, “I’m really sorry, I’m not smart or sophisticated enough to understand you. Could you please help me by making this more recognizable as a phone number so that I, a mere program, can process it for you?”

I’m not saying that’s what the program should really say, but that’s a useful mindset to have when approaching the situation as a design problem. Such thinking led to the asymmetric validation triggers above, and perhaps more thought along these lines will lead to further refinements to this very common aspect of user experience design.

Every app has a scary basement

It takes a while for a designer on a mature product to realize that not all parts of the application's user interface are equally stable. As an application evolves over the course of years, it tends to develop some critically important yet unbelievably fragile component upon which too much rests. I picture such a feature as a scary basement: the dark, old, mysterious, and temperamental body of code which is vital to the running of the operation. The scary basement is cantankerous and hard to maintain—something only operated upon by the most senior and stalwart of the team's engineers, and conspicuously avoided by everyone else.

When I worked as the lead designer on Microsoft Money, I eventually came across its scary basement: the elaborate checkbook register control for viewing and editing account transactions. This register control was first created around 1990 by legendary Microsoft engineer Doug Klunder. To get the most performance out of the PCs of the day, I believe he had the register itself more or less directly read and write transaction data from disk. In this capacity, this specific UI control was entirely and solely responsible for validating all transaction data; there was no separation between presentation, business logic, and on-disk representation.

This gave rise to all sorts of odd restrictions. For instance, any dialog that created an account transaction had to instantiate, somewhere behind the scenes, a hidden instance of the register control. When the user entered data in dialog fields, the dialog carefully copied those values into the register, told the register to save it, and then tried to divine whether the save operation had worked.

With each new product version, the register control had new functionality bolted on (investments, online banking, localized features), and each addition increased the complexity of the code. By the time I joined the team four years later, the register control had become so incredibly Byzantine, only one or two people on the team could, and would, touch it.

Money register control, circa Money 95: Be afraid… be very afraid.

A distinguishing characteristic of the scary basement is that all work on it will take an indeterminate length of time; any bug fixes or improvements are essentially uncostable. In the case of Money’s register control, simple changing the order of the transaction fields might take a day—or several weeks. There was just no way to tell beforehand.

When I was first exposed to this reality, some friends on the nearby Microsoft Word team shared stories about their app's own scary basement: a routine called FormatLine. Given a point in a document and a column width, FormatLine would lay out the next line of text at that point. As I heard it, this routine had evolved into a handful of functions that were each thousands of lines long. Developers assigned to descend into the depths of FormatLine were treated with the same respect and concern as spelunkers attempting to reach trapped miners.

The basement metaphor isn't just a way of describing the unnerving nature of tiptoeing around such a feature—it's meant to reflect the fact that such a feature is invariably foundational to the application. And like a building foundation, this code can’t be replaced with something more solid without a colossal engineering effort. In most cases, the scary basement just stays that way until the platform the app sits upon becomes irrelevant, and the app is ported over to some new, saner, foundation.

To prevent a critically important aspect of your UI metastasize into a scary basement means investing time in refactoring as you go, and this means moving more slowly that you would like. UI changes need to be evaluated in terms of the degree to which they compromise the solidity of the foundation.

This past week, a developer here at a Cozi came to me with a tough decision. I'd designed what, IMHO, was an interesting modification of our family calendar UI that could have helped optimize screen real estate for both user data and advertising impressions. Unfortunately, after a couple of weeks of working on this, the developer indicated that it was proving ferociously complicated to get the new UI to work correctly with the infinite scrolling on our calendar page. The infinite scrolling feature was itself delicate, and doing anything to it was complicated by the need to work across multiple browsers. While it might be possible to slowly stabilize this particular new feature to an acceptable level of quality, our calendar UI would likely become unacceptably fragile—the next feature we tried to add would apply new stresses, and things would break in unpredictable (and uncostable) ways. Our calendar UI would turn into a scary basement.

We couldn't let that happen. For a family-focused product like Cozi, being able to evolve our calendar UI is crucial to the business. So while it was painful to let a neat feature improvement go, we ultimately decided that it wasn't the right time for it. Maybe someday cross-browser compatability won't be such a pain (probably when we can drop support for IE 7 and 8), and we'll give it another shot. In the meantime, we have a clean, well-lit basement.