Designing like an engineer is bad for business
Making great software is a huge challenge.
The challenge only gets harder for those that have to wear multiple hats because of constraints, self-imposed or otherwise.
As most readers of the blog know I act as the main designer and developer for Cashboard (shameless plug #10384). This situation arose from many factors, but the main one being I wanted to get the product up and running under my own power. I've seen too many projects fail and I didn't want anyone to blame on this one but myself.
I tell most people I'm a designer first, but I program out of necessity. Anyone in the software engineering field knows this is usually a bad idea and results in a shit product, yet I believe I'm able to pull it off because I'm able to "switch modes" or "switch hats" most of the time.
I'm damn good at what I do, but I'm definitely not above the classic problem. I routinely have to catch myself "designing like an engineer" instead of designing as a user experience person. Case in point, Cashboard's "Account Preferences" screen.
The old screen is shown below in all of it's fucked up, cluttered, and confusing failure.
This particular screen was built over time. Sections were added as the product grew, and it shows.
The design made complete sense to the programmer side of my brain. Sections of the screen directly map to functions of the code. As it usually turns out in situations like this, it was the exact wrong way to approach the design of that screen.
Non-relevant information is shown which clutters the view and detracts from the goal at hand. Things aren't logically grouped from a customer's point of view, and worst yet the screen has an overall busy look that's quite perplexing.
There are two forms on the page, with two buttons, and a link to update other relevant information on yet another screen. (yuck!)
Preferences Screen Remix
Finally fed up with the design I took it upon myself to give that screen a makeover. Putting on my designer hat I busted out the design documents necessary, re-assessed the goals of customers visiting that screen, and had a revelation.
Customers of the app visiting this screen just want to update their preferences. They don't care that changing their currency is a different operation from setting their date formats or billing address on the back-end, and they shouldn't have to.
As with most design breakthroughs, this one was sitting right in front of my face. The solution was plainly there, yet I was missing it up until now because I wasn't paying attention.
The updated design eliminates unnecessary information presented from the first screen, brings the "billing address" fields into the mix, and consolidates the multiple forms into one.
The result is a much cleaner looking form that actually makes sense for the goals at hand and is pleasing to look at as well.
As someone once told me - it doesn't cost a thing to pay attention, but not paying attention can cost you dearly. True words indeed.