The Developer Mindset

Last week, as I was wrapping up a user interface item that I had been working on at work, I called my boss over to have a quick look at the web page I had created, to make sure it made sense to a fresh set of eyes. It was a means for me to get some perspective to determine if there were any glaring problems with what I had created. In other words, I wanted to do a brief usability test.

He took one look at the screen and said, "You know, don't worry too much about creating a good user interface. We have a team of user interface engineers working right now to design something for customers, so you don't need to spend your time worrying about this. Focus more on getting it functional, and we'll overhaul it later." (This was the first I had heard of external user interface engineers being involved in any way.)

He then went on to explain that in his experience, he and his business partners could sit there, furrow their brows, and brainstorm all day long about how to make a particular piece of the interface more intuitive. In the end, he realized, it didn't matter. Whatever they came up with confused some customers in a way that they hadn't foreseen. No matter the case, they always ended up having to take the feedback given to them by customers and improve the interface going on this feedback.

Now, he has a good point in this case, and I happen to agree with him entirely. I'm a backend developer and have very little interface experience. In my case, I wasn't trying to create a perfect user interface. I was merely trying to avoid introducing any additional confusion to what was already there.

And while my boss is well within his rights to tell me how to use my time (since he's paying me), there is a slight fallacy in what he was implying. Telling me not to concern myself with the user interface because there's a team of interface engineers that are going to come in and fix it later is like telling a person they don't need to learn to spell because their word processor has a spell checker. Spell checkers don't always catch missing words, or find errors that are contextual.

Creating software that's usable is a process, and I think it actually requires getting customer feedback and then fixing those problems. You're never going to anticipate all of the problems in advance, without asking a customer to try and use the software.

I'm not a expert on either, but whenever I create code for something, I do take a little bit of time to think about how I would break something I had written. I look for Cross-Site Scripting holes or other security vulnerabilities. I step back a page and then come back to the page I'm working on a few hours later to see if the interface makes sense. I code my HTML so that people with screen readers can use it effectively.

From a security, usability, and accessibility standpoint, this is a good mindset to have. It doesn't make my code 100% secure, or usable, or accessible, but I try to avoid adding more problems by keeping aware of the low-hanging fruit. When you're designing something, you don't have to be an expert on these particular fields, but knowing the basics and how to incorporate them will reduce frustration down the road.

It helps if you make this process a habit. In instant messenger chats with friends, I tend to be a stickler for correct spelling, punctuation, and grammar. This isn't because my friends care whether I use my English good or not. It's because later, when I'm typing an e-mail to my boss or a customer at work, I'm already in the habit, and therefore I'm less likely to make a mistake when it might matter.