How a Customer's Question Frames the Definition of 'What Does a User Interface Architect Do?'

My title is Chief Architect, and the short description of what I do is that I designed the mCUE user interface and telephony middleware systems.

That's not a very satisfactory description for several reasons:

1. The product named mCUE is difficult to pin down: “Unified communications” and “middleware” are industry terms calculated to form meaning in the eye of the beholder.

2. When people hear “user interface” they think “draws pretty pictures”

3. The term “architect” is also nebulous – what is there to architect in a user interface? It's just presentation.

So, when asked, what can I say about the job I do? Recently, a customer's question brought the description of what I do in focus, and also helped clarify the nature of the product I designed. The question was:

How do you ensure consistency of customer experience from platform to platform?

The question was asked because we showed the customer our product in a very portable implementation that depends only on a reasonable Java VM and a small subset of the Java AWT classes, but they needed our product in an environment that requires use of that platform's UI classes and application framework. Why, in this new implementation, should they expect it to work like what they evaluated and liked?

That question gets right to the heart of what it means to design a mobile user experience, and, indeed, right to the heart of the whole project that I have been working on.

My work here started with discussions I had with D2 Technologies' founder David Wong, who is a pioneer in voice over IP technologies (VoIP) and DSP software, on the proposition that VoIP user interfaces were low-quality compared to mobile user interfaces, and that nobody had really thought about VoIP user interfaces the same way as mobile user interfaces.

That is, nobody had thought of VoIP user interfaces as a really important part of the product. VoIP users were fewer, and had fewer options than mobile users. VoIP users were generally enterprise users, accustomed to ill treatment by user-hostile software. VoIP user interface was immature because the resources applied to it were small, and the stakes in the market were correspondingly small. What if we took it seriously and put more mind-share and resources into it than our competitors? Could we make a breakthrough in VoIP user interface and, perhaps, ride that up the value hierarchy to a place among mobile handset technology providers, especially as they found they needed IMS endpoint technologies?

That is how the project that became the mCUE product started at D2 Technologies. It was about VoIP, but, specifically, about what we hoped would be the logical next step for VoIP endpoints: Instead of desk sets that tried to look like PBX phones, VoIP would logically be moving to mobile handset form factors and use WiFi to connect to VoIP systems.

That VoIP user interface market, however, proved to be too small even for a specialist company like D2: WiFi handsets are, still, a tiny fraction of VoIP endpoint market share, and desk sets are still saddled with crude user interfaces. Nor could we make an immediate jump to providing IMS endpoint technology. Only tier-1 OEMs were active in defining their IMS endpoint architectures, and these were mostly prototype efforts.

Nevertheless, we changed our design goals to aim at the intentions of IMS: To make every mode of communication a first-class citizen in the mobile endpoint. And, beyond that, we realized that IMS is not the be-all/end-all of mobile communication. We also made every service a user might want to use a first-class citizen alongside the mobile network. That is, we made IP communication in all modes and media able to either replace, as in a purely VoIP system, or stand alongside mobile service, without relying on an IMS network implementation to aggregate every conceivable IP communication service.

And that gets to the answer to our customer's question: How do we ensure consistency of customer experience from platform to platform? The answer is: we have to, otherwise we could not implement our goals. We must make a new “world” of communications objects that replaces the call-state management in a conventional mobile handset with a model of communication that encompasses all modes, all services, and all networks. And, if user interaction with this much-expanded communications model is consistent in all implementations, the user experience is consistent, no matter the UI toolkit we use to implement the presentation of the user experience.

So, what does an architect of mobile user interfaces do? He makes a model the user is comfortable manipulating, and presents that model in a consistent way across multiple platforms. This sounds a bit general, but aspects of this task are especially critical in mobile user interfaces: The mobile user interface is inherently a multimedia user interface – it used to be almost entirely presented as audible call progress tones and the billions of users of telephone systems worldwide have a strong expectation that the conventions of a telephony user interface and a mobile user interface will be preserved in an interface that brings in other modes of communication.

The mobile interface itself cannot be pulled in new directions very easily, yet assumptions have to be questioned: What, for example, can be done to enhance the task of starting a conversation? On-hook dialing was invented to keep the user off the precious resources of the mobile network until the last possible moment. Now that always-on data connectivity is inherent in VoIP networks and widely available in mobile networks, the “don't touch resources until you absolutely need to start signaling the network to connect a call” assumption is obsolete.

A mobile user interface designer not only makes the presentation of the user experience, he has to be able to design the model manipulated by the interface, and he has to know about the network, and even the business of operating the network, to make a presentation, a model, and a consistent set of functions that work together. And he has to know it all well enough to know the difference between a rule you have to observe and a rule you have to break in order to innovate.

This seems daunting. It is, at least one of the most interdisciplinary pursuits in software design. It is full of both constraints and opportunities. If you are unaware of the constraints you will make mistakes that make you look amateur. If you are unaware of the opportunities and what it takes to exploit them, you only advance by luck. The reward is that good work in mobile user interface design expands your mind the way few tasks can in the increasingly specialized world of software design.