Todd Biske: Outside the Box

Phil Windley, in his latest Technometria podcast on IT Conversations, had a discussion (well, he listened a lot) with David Platt, author of a new book entitled “Why Software Sucks… and What You Can Do About It.”

While the podcast is quite lengthy, it’s very good and quite entertaining. As someone with a background in human computer interaction and usability, David’s comments certainly hit home for me. While it wasn’t anything that I haven’t heard before, it’s still something that every developer should hear. Near the end of the podcast, he gave some guidelines for both users of systems and developers of systems. One thing he said that should be done is to have someone involved in the design of the user interface that has absolutely no clue about the implementation of the system. He gave an example where this person would ask the question, “Why are those two fields next to each other?” Often times, the response would be, “Well, those two columns are next to each other in the database.” Guess what? You’re letting the implementation drive the interface.

This is by no means an easy task. I had a conversation with a good friend of mine who is a consultant on user centered design and usability, where he was asked about some of the potential conflicts between a user centered design approach and an SOA approach. My comments were that there shouldn’t be. UCD should be concerned with the user interface, period. There will be backing services that support that user interface, but those interfaces are system interfaces, not something that gets exposed to the user. The conflict only arises when that separation between interface and implementation begins to blur. Everyone knows that people tend to take the path of least resistance, so it’s very easy to design a system where the user interface unduly influences backend implementation (and hence service design), and vice versa. The challenge is to realize that there is a separation of concerns. The UI team shouldn’t be telling the service developers how to do their job, and the service developers shouldn’t be telling the UI team how to do theirs. At the end of all of this, we somehow have to come up with a system that meets both concerns. It’s not an easy task, but it’s what makes our jobs fun!

Now, keep reading to my next post with another great item from this podacst. I didn’t want to include it here, in case people didn’t have interest in this part of it.