I think the title states quite the obvious, User Experience practitioners would agree with me. But in the context of your ICT activities, do you find that Software Architects take the same view? It is not so clear cut in practice, in fact tensions or misunderstandings can be easily found. The situation I am discussing here mostly applies to large IT organisations, where design and development and rollout activities and responsibilities are split across multiple groups. This is not the case for small organisation or tiny start-ups.
In my experience, software architecture tends to be the discipline or at least the responsibility given to people with an Sofware Architect profile. In this text, I am referring to Software Architect as the profile that is often contrasted to UI Architect in some ways. The former is the title given to the guy who knows the inner workings of the software, the person who can perform back-end coding and is intimate with it. Whereas, the latter doesn’t get credited for his/her technical skills beyond pure front-end coding considerations. Then there is also the IT Architect, the role given to the persons that build or look after machines. Incidentally, when the Software Architect and the IT Architect roles are not working closely together, problems arise at the time of deployment where organisations find that many production staging aspects where not tackled properly. But that is a subject for another talk.
Recently I tweeted a link to an old posting by Richard Monson-Haefel about 97 things every software architect should know. @multifarious remarked that he found it interesting that (experience) design was not one of the 97 things mentioned in the article. This blog entry is an attempt to expand on my thought a little bit.
As I understand it, R. Monson-Haefel polled a few people whom he deemed authoritative in his quest. A quick reading of the entries will support @multifarious’ suspicions. There was probably no intention to exclude UI experts. Whatever R. M-H’s intentions, @multifarious might have just singled out one of the shortcomings of software architecture practice. You can get the impression that designing user interface code is taken for granted, if the “back-end” stuff is sorted out that is. Often case, discussions on usability is really bogged down to response-time in a context of request/response. If the actual interaction proves unworkable, blame is easily laid on business analysts or business owners for not clearly indicating their intentions.
In my opinion, the Total Experience should really be the focus of usability at any point of a software architecture crafting process. I think Google got this right when they launched google.com all these years back. It is no a flashy web site, but everyone agree that you get precisely what you are looking for without hassle. And that is a fundamental point. Perhaps the current maturity level still focuses too much on the inner workings of the underlying software, but is little cogent of the user interaction issues.
I give it to @multifarious, R. M-H’s article ought to mention user experience design. Maybe it does in the book, which I haven’t read yet. Maybe they’d cover it in a future iteration.