It is sometimes uneasy to explain why I use the term “User experience architect” instead of usability expert, or something equivalent.

It is mainly because I consider that usability is a set of tools the UX architect uses to reach a higher goal: building a system’s experience, i.e. the relation between humans and systems.

As an architect, I always base my work on narratives and not on usability rules. These rules are applied when it is time to shape the narratives into an actual system (system= web site, web app, software, physical machinery, etc.).

Why is that? It is because narratives are always more powerful than rules, methods or analyse. For example, it is not rare to see systems with badly flawed usability, but with a very strong narratives, being praised by users: MySpace, Windows, mobile phones, etc. In each case, it’s the narrative that makes the product used even if it is hardly usable.

A narrative is a simple phrase that would describe a system in a very human way. For instance the narrative of a mobile phone is “you can call and receive calls from anywhere”. With such a strong narrative, anyone can produce and sell very unusable phones because the narrative remains intact even with the worst phone, providing it sends and receives calls.

Now, how to build a better experience on a mobile phone?

As we can see, even with a very thorough usability treatment to the phone’s interface, users won’t get hooked because the narrative remains the same. Then the mobile phone industry is stuck, and competition is based on very weak arguments: design, coolness, feature list… but nothing really change for the users.

Worse than that, phone manufacturers tend to pile up irrelevant features into their products for the sake of offering “more” to their customers (i.e. agendas, chronometre, truncated web surfing, fake e-mails, etc.). But these features are not supported by strong narratives. In most users’ minds, a kind of web experience equals no web experience at all.

So, as soon as a new narrative pops up, it’s an immediate success. See for instance: “you can really send and receive e-mails from anywhere, anytime”, and here we have the Blackberry. Then again: “you can really surf the real web from anywhere”, it’s the iPhone. What next ? What about “you can keep your full profile anywhere, anytime, on any available device”.

Once the architect has extracted the core narratives, he can put his skills at work to draw the interfaces that will materialize the narratives. Then he can apply usability rules to maintain consistancy and user-friendliness. He may also set new usability paradigms if required by the narratives.

There is not one - or “best” - way to materialize a narrative into an interface; but the first materialization of a new narrative has a very big chance to set a standard. Not because it is better, but because it is unique when it appears.

Conclusion:

• The UX architect will extract and strenghen the narratives hidden behind your project.
• The UX architect will materialize the narrative into an Interface (relying not only on his usability skills, but also on his own sensitivity).
• The UX architect will deliver a blueprint of the system’s experience (interface mockups + map)
• The UX architect will support the building of the system (visual design, coding, implementation) as a guardian of the narratives, and a helper to sort issues during production cycles.

Conclusion of the conclusion: good usability is not enough to diffenriate your project, narratives are its real substance in the users mind.