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.
I agree! 😀
This is actually something that has kept parts of my mind occupied for the past, say, year-and-a-half-or-so. And there’s so many aspects to this issue that it’s hard to pinpoint exactly what the ..anti-pattern is here.
I think, to begin, there’s an issue to ponder and an issue to take notice of.
This is the food for thought, in the process of developing a web-based enterprise scale application it seems as if there still is a gap between the core of the application (backend,infrastructure etc) and what the designers and application owners see. Sometimes it feels like a house is build and all the interaction (doors, windows, bells and whistles) are painted on the house. If this makes any sense..
It then seems as if the team between business-analyst and software engineers were on a hiatus, were out of the loop. In my personal experience this isn’t far from the truth.
Why this is, I can probably kill this page with musings and ideas about that, so I might have to do that on my own blog. Bottomline is, when the creatives and the hybrids (the UX developers) lack in involvement, there must be some kind of disconnect in that part of the site and often internal communication.
Another issue which should be raised and noted is that front-end development is maturing to a level, and a breath, to where it just doesn’t fly no more to take it for granted.
Not in the sense that it should be seen as something one does in between (oh, the atrocities I’ve seen people dare to call structural html). It has become SO intricate that I suspect nature invented AD/HD just so there would be a group of humans able to cope with the wide range of technologies you should be interested in and acquainted with as a front-end developer.
But neither should the front-end people be left to their own devices. That the technology has matured still isn’t a guarantee that your particular front end guy has it in him to code on a mature level without losing sight on what level he is supposed to operate.. IE; building an intricately abstracted and ajax-e-fied front-end framework might be interesting on a proof-of-concept and/or intranet level, for the average web service it might just as soon become the page-render bottleneck.
So yeah, there’s definitely work to be done and challenges to overcome. But I think there’s also a lot to be gained, not in the least in keeping a client happy and reaching targets in ways that currently might not seem reachable or even obvious.
oh, that is quite long.. what can I say.. don’t get me started 😉