Emerged and submerged UX


Icebergs. Not an original metaphor, I know.

Any kind of product isn’t just defined by quantitative boundaries such as budget and time, but also by the user experience it offers

  • as a product, to its end users;
  • as project, to its makers.

An application it’s not just about interface design but also about a great deal of backend programming and integration, the entire user experience of a project. The deception of minimal design is often, if not always, supported by complex and invisible supporting systems.

Building systems

It’s 2012 and if your are not building systems, or you’re not fully aware you’re building them, you better watch your back. The days in which “an app that does that” was enough to be successful are long gone. Building systems is hard. It requires a lot of thinking, a lot of different thinkers.

We like front-ends. It’s what make our applications shine in front of the world. It’s how we win prizes. It’s how we get new clients. It’s how we impress people that may want to work with us.

We know that truly great front-ends come for great back-ends design and development.

Putting it in a really dumbed-down way, building a system requires making different front-ends and back-ends to talk to each other — sometimes across different platforms and different contexts for each system.

Emerged UX

This “emerged” user experience is what we commonly call “just UX”. This is not the place were I explain what UX is and isn’t — yep, there’s still a lot of confusion about that. Let’s just say that a user experience is not (only) interface design and cool animations.

The emerged UX of an application requires great design skills and a lot of research: after all, your applications could influence behaviors, as learning, productivity and customer satisfaction – you don’t want to screw that up, do you?

Submerged UX

This kind of user experience is as important as the better-known, emerged one. As Matt Gemmell wrote:

“APIs are UX for developers”

If you take a look at what APIs are, you might get why I’m using them as an example of submerged UX. Clearly, your graphic designers may not be interested in API design. You clients or users won’t care either.

Providing context

I’m not suggesting that submerged UX requires a specific set of knowledge and tools to be put in practice.

It can be simple and straightforward as asking your best developers what makes them happy and how things needs to get done. It’s likely that following that path will lead to great applications, even if nobody out there will care to know how did you get there – we like being shown how wireframes becomes real applications, not how an API architecture must be documented or what’s at stakes when you’re battling with your clients over business models’ matters.

You have to provide a common context in which all the people involved in the project understand that they’re building a system, not an app.

You probably got it: handling submerged UX is, at the end of the day, just great project management.