Adaptive Path Blog

In many organizations, especially those that are technology-centric, software architects play a dominant role in shaping the solutions that either frustrate or delight the end-users. It’s long been the case that many architects didn’t consider the user’s experience until nearing completion of development, much like painting some pin-striping on a Dodge Dart. For example, just consider those big “internal applications” like that corporate timesheet application or the requisitioning app you last used — chances are you had to be trained on how to jump through all the hoops to complete some very basic tasks.

Well, there might be some forces at play to increase the importance of UX in the mind of software architects of these big enterprise applications:

• increasing competition and a need for differentiation;
• the rise of the web services model that reduces companies’ switching costs;
• and increasingly savvy customers and buyers.

The forces are even greater for software architects designing consumer software products, where the need for product desirability long ago caused a shift towards embracing UX.

Another point of evidence of change is the SparkUX forum hosted by Microsoft earlier this week. The mission provided to the 30 architects and UX professionals in attendance was a lofty one: empower software architects to improve the UX of products.

The mission itself implies a frustrating description of the current state from some organizations. It implies the software architect is accountable for the product quality, yet the architect isn’t able to improve the UX of products. Hmpf. I’m perturbed already. This mission also raises some basic questions: Are software architects ready to be empowered to improve UX? Who is really ultimately responsible for the UX of a product? Can ownership of the technical architecture and UX architecture be split and shared, or must a single person be accountable for it all (as a director is ultimately accountable for an entire movie, including acting, story, lighting, and effects)?

The SparkUX forum was dedicated to addressing these and other questions, some of which you can learn about from the post of another attendee, Adam Richardson of Frog. I must admit that the role of software architect isn’t something I’m intimately familiar with, so the forum was a change for me to build some insights about the role. Still, I’ll take this opportunity to share the conclusions I reached:

1. There’s a time for UX. As industries mature, the basic offerings become more and more similar and there’s far fewer efficiencies to be gained through pure technological improvements. User experience becomes one of the key differentiators between your product and the competitors. Better UX design can lead to faster adoption, higher completion rates, or more of whatever behaviors you desire of the end-user that lead to real business value (provided that the UX was designed with it in mind). The ugly corollary is that there might be a time when an industry isn’t yet ripe for UX, when a technological solution with a poor UX is still economically advantageous and competitively viable. This is when battling for organizational investment into UX is a uphill battle, both ways, in six-feet of snow. Regardless of how much I want technology to be humanized, it probably won’t be in a very immature market. The opportunity is to identify when an industry and organization is ready for engaging in UX. The challenge then is to communicate the value of UX and delivering on it.
2. The industry grows software architects that are narrowly focused, and therefore less receptive to UX. Attendees at the forum pointed out that most architects began their career as fairly specialized developers, in networking say, and then advanced in their career to become a software architect. Compare this to a mature organization with a leadership development program that cycles young promising employees through manufacturing, accounting, sales, marketing or other business functions to eventually create senior business leaders that have a more holistic skill set for solving business challenges. Today, the tech industry doesn’t create natural career paths for architects that encourages exposure to business, marketing, or UX job experiences.
3. The practice of UX isn’t highly accessible to architects. Yes, there are plenty of blogs, methodologies, frameworks, and posters out there; but UX is most often conveyed as activities, methods, and values, not packaged as desirable benefits that attract and motivate architects to embrace the practice.

Much credit goes to Simon Guest, Norman Guadagno, and the team at Microsoft for bringing together a diverse set of voices to take some much-needed initial stabs at addressing this intersection of UX and software architecture.

This entry was posted on Thursday, October 5th, 2006 at 5:20 pm and is filed under Conference commentary. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

This post is licensed under a Attribution-Noncommercial-No Derivative Works 3.0 Unported License.