It’s the User’s Problem
Why are address forms like this?…
And not like this?…
You might say, “that’s the way forms have always been done.” But there’s two problems with that. First, do you fill in boxes when you write on an envelope? Second, it isn’t always wise to keep doing things the way they’ve always been done.
The real reason that we have a tradition like this is because the address eventually ends up in a database. The database designer has columns or fields for each component of the address. The engineer wants to validate the components of the address and puts them into member variables of an object. The UI developer knows the object and creates a form that fits the object. Done.
But, is this good for the user?
What if all of the engineering challenges of identifying the pieces of an address and validating an address were solved. What if you could present one box to the user so she can fill it out just like she would on an envelope? What if the UI could be developed to auto-complete the city and state etc, all within the confines of a single input? Which is easier? Arguably, filling out an empty box is easier. So, if the single box is good for the user, why do we still create multi-field forms? Because it’s easier for the engineers.
Easy for Engineers Means It’s the User’s Problem
When we make decisions like this–take a hard engineering problem and make the user deal with it–we diminish the user experience. However, there is always a balance. Sometimes, due to resource constraints or timing, engineers simply can’t deliver a solution that is better for the user.
It’s a constant trade-off.
As UI-building teams, we need to be aware of this trade-off. How often do we burden users with problems we don’t know how to solve? Every time we make that decision, we diminish the overall experience. Unfortunately, we’ve reached a point where we make the trade-off too often in favor of engineers without fully thinking through the user experience.