Advice for developers about UX, requirements, project management

Read why Justin James thinks developers should continue to focus on user experience, get to know their users, and improve project management.

A couple of weeks ago I talked about how some advice I have given to software developers in the past is no longer accurate. But as the old saying goes, "the more things change, the more things stay the same." Here are three things in software development that continue to hold true.

User experience is king

From iPhones to Facebook, the world is filled with examples of products that have deep technical and other shortcomings yet are wildly successful. And what these products have in common is that they deliver a good user experience (UX). For all of Facebook's warts, it allows users to do what they want on the site. Who needs a personal website or blog when Facebook is "good enough" for most people's needs on those fronts? Why try a BlackBerry or Windows 8 phone when you know the iPhone delivers the "it just works" experience for the most part?

When you do find counter examples to this, it is typically because of price. Windows beat Mac OS not because it was better (they both had their flaws and still do), but because it was cheaper. When you look globally, Android beats the iPhone, but in the U.S. where carrier subsidies bring the cost of iPhones down quite a bit, the iPhone handily wins. Facebook's killer advantage is its critical mass of users, which is vital to their experience and no amount of programming can replicate.

While the recent batch of consumer-driven applications and devices are starting to finally put usability and UX at the forefront, enterprise applications are still a train wreck on this topic. For new and small companies where there is little vendor lock-in, folks are choosing the better experience over and over again. Companies like Salesforce that deliver a good experience are only going to get more successful, while their competitors will need to rely on vendor lock-in and the traditional sales model to stay afloat. As developers, we no longer have the luxury (if we ever did) of writing software with a poor UX.

Get to know your users

The longer I am in this industry, the more I am struck by how many people think software can be written in a vacuum. It's not enough to talk to your users -- you need to get to know how your users do whatever it is that your application does; otherwise, you get a list of requirements that do not explain what the user is trying to do and often specifies a sub-optimal approach. Compare these two requirements:

"Screen should have a drop-down list of all of the users in the system."

"Screen should allow a user to be found and selected."

They sound the same, right? Not really. Maybe a drop-down list is the right approach, but if there are hundreds of items in that list, a search system, an auto-completing input box, or perhaps a pop-up window with an advanced search would all be better options. When you learn how users do their jobs, you can deliver great software that is a success. My favorite technique is to be a fly on the wall while they use their current systems, and then ask targeted questions afterwards to understand why they made some of their decisions.

The need for improved project management

I think the only groups of people who get things wrong more than software development teams are the weather forecasters. While there are no definitive studies (that I am aware of) proving exactly how many software development projects are failures, I consistently read numbers well above 50%. Part of the difficulty in getting a good number is what is considered failure. Over budget or late is considered a failure by some but not others, for example. Some folks are happy to eventually get a mostly working product.

A lot of the failures (regardless of how you define them) come down to basic miscommunications between development teams and the business teams. The difficulties come from differences in how they talk to each other, in expectations, baseline assumptions, and more. These are the kinds of things that software developers need to keep improving if we want to remain employed, particularly for in-house IT. I have been saying for some time that developers need to work better with the business, and it is truer now more than ever.


Related TechRepublic resources

Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.


Justin James is the Lead Architect for Conigent.


'you need to get to know how your users do whatever it is that your application does" It's easy to lose perspective when your developing something because you live and breathe it. You know all the shortcuts, all the tricks and do them without even thinking. But that's why it's important to take a step back (or maybe let someone else step in) and look at your application with a fresh and non-biased eye. How will people actually use your application? Not how you want them to---how they will (or at least try).


I went from a large company, developing applications for internal customers (i.e. other employees), to a small company with external customers. It's been very difficult to get feedback from my new customers. At the big company, I could always meet face-to-face with them, and had some leverage if (like everyone else) they didn't feel they had the time to provide the feedback. Any suggestions on how to get that feedback? Talking to the company Help Desk folks is one option, but to me that's second-hand info at best.

Tony Hopkinson
Tony Hopkinson

to avoid the classic pitfalls around designing a UI for you (the developer) instead of the customer, cognitive walk through for instance, but you still need customer feedback, and it needs to be good. One or two customers won't cut it, all that does is move the issue. You need good metrics, they need to be collected frequently. You need to monitor the effectiveness of the changes you make. There's input from branding and marketing, the device being used can have a huge impact, and if you are talking legacy applications... Best advice I can give to a software developer, is do the job properly and make sure you have separation of concerns, or no matter how "wrong" your UX is you won't be allowed to do anything about it anyway.


I find the weather forecasts to be pretty good in my part of the world. Definitely 'good enough', 'most of the time'. Not like software. Otherwise some great advice. Developers - listen up!

Tony Hopkinson
Tony Hopkinson

That means target it. It means use it. It means the customer should get something out of it. It means demonstrating how their feedback impacted the result. It means checking that the change you made had the effect you both wanted and none either of you really didn't want. Empower them. Give them optionA and optionB, they tick a box in the software, It dials back and logs their vote. Could be a prototype add on, a storyboard, just a link to a web page. "Have your say" Your leverage, is they get something back for spending their valuable time on you. I wouldn't knock the help desk myself. At the very least top complaint / query will give you something to look at, because by definition it means they find it hard to use. But if you really want to do something pro-active, then it's sales and marketing you want to lock up with. Just make sure they know you haven't done the work yet. :) Have a look at SUS (Software Usability Score).

Editor's Picks