09 February 2010

UX Strategy is different than UI strategy Part I

[Note: First of three parts.
Next post Part II, a detailed discussion of the diagram below.
Part III. the UX Declaration of Independence from Engineering.]

Here is some big news: UX strategy is not UI strategy. This must be big news since the two seem identical in how they are practiced. There seems to be a fundamental flaw in our ability to make a difference between UX practice and UI practice. However, there does not seem to be a shortage of differences between defining the two that is covered and almost written to death (so I won’t cover it here if you are interested in that wikipedia is a fun to place to start). Yet when the rubber meets the road, most strategists, designers, usability engineers and other nefarious UX practitioners like me, explain a process that looks awfully similar to UI design best practices anno 1989.

So here is some other big news, amazing news for everyone in the UX business: design is not engineering. What? You knew that already? That is strange since I am yet to see a single UX strategy or UI process that is actually iterative let alone independent of a development cycle. Oh I am sure they are out there, its just the secret sauce of a chosen few who really get it right? Not likely. It seems to me that most people who claim to be UX designers are in fact UI designers.

That fact is so few people understand UI design that no one really notices when it goes by another name, especially one that sounds more expensive like UX design does. The reality is UI designers have nothing to be ashamed of: it is one of the most difficult and nuanced professions due to its inherent multi-disciplinary focus. The inclusion of Interaction Design, Information Architecture, Graphic Design, User Research etc is all classical UI design not User Experience design. Because of this confusion, too many people are spinning their wheels in UX design when they are really discussing the important and essential issues around UI design. Here I would like to discuss my take on the practice of User Experience design.

Here is the good news: there is a solution
I recently gave a talk in Utrecht UX Strategy. I include the slides with this post.



I think my most important point in that talk is a real iterative UX Strategy that is based on Design practice not software engineering practice. A subsidiary thesis to that talk could be: if you are fixated on how UX fits in a development method (e.g. Agile, RUP, Waterfall, etc.) than you are not a User Experience Designer at all but a UI Designer. There is no shame in doing UI design but then let’s not muddy the UX waters with it.
Moreover a real UX strategy should not only not resemble an engineering process, but should also be independent of it. To not accept this reality, is to concede the hegemony of engineering in both process and decision making on UX. That hegemony is not the reality except in engineering driven companies. UX is inherently strategic, whereas UI design is inherently tactical requiring a close association with engineering toward realization. Perhaps it bears noting that not all User Experiences have UI’s or have UI’s as their most important component. UI Design is in fact the place where Engineering and UX meet but UI design is not the end of the UX strategy, it is rather one of its many expressions.
The presentation above identified 3 goals of UX Strategy, they are not the three goals rather just the three I am concerned about:
1. Keep the client/business/organization focused on their business goals
2. Keep the Design and Technical teams focused on the Conceptual Design
3. Provide a predictable repeatable process
4. Maintain a UX reality check that is at once iterative, open-ended, and reliant on solid analysis (some may call this trusting one's gut) as any good design process should.

A good UX strategy is therefore better represented by a loop, as it is in the slide presentation above. A loop unlike any engineering process. A loop with no beginning, because we invariable enter at some arbitrary moment: when we contracted, when we were hired, etc. It reflects reality that we start anywhere in the process and it also reflects the interdependent nature that one step will invariably influence the other, if not for this product than maybe the next. Moreover there maybe multiple simultaneous iterations occuring at the same time.
A much improved version of the image from the presentation would look like the image below. This is what looks like a ferris wheel approach. Each node on the wheel below represents a common analytical element of a User Experience. This is a 1.0 release so hopefully some helpful comments will come forward and allow me to iterate on it.
This image recognizes the interconnectivity of an organization to the user experience and the ripple effect of one UX element will have on the rest. One error in the drawing is that everything appears to be the same weight and magnitude, which is not true. A gear like metaphor would be better. Each element, mission, goals, etc. could be represented as a gear that turns the larger iteration gear. A gear, whose size could change with each of the UX elements could have a bigger or smaller gear depending on the character of the company or organization.

Each element can have a series of activities associated with them. These activities will help continue the iteration cycle. The activity can vary with organization, its needs and (the weak link in the chain) the talents of whom they hired to iterate the User Experience.
Another important aspect to the drawing is the iteration cycle does not end. There is no ultimate goal with which life starts and then ends. The reality is relases/successes are temporary and no sooner is one goal achieved than the next goal must take over, the next quarter’s numbers must be met, the next new thing must be created to stay ahead, etc. In this way the UX evolves throughout the life of the organization.
A few examples of a chart completely filled in are given below. The first example is a complete cycle refresh. The next one is a product oriented iteration. The last one an organizational iteration with a proof of concept product at the end of the iteration cycle.
After the images below i welcome your comments. I will refine the presentation and the drawing (maybe a good visual designer would volunteer?). The the drawing will start to live, and will it ever be finished? I hope not, or we will be out of a job.
UX Strategy wheel template


UX Strategy wheel completely filled out



UX Strategy wheel completely filled out for a product oriented iteration


UX Strategy wheel completely filled out for a company iteration with a proof of concept product or service

5 comments:

Nils Vergeer said...

Thanks Jonathan for this intriguing post. This is certainly a quote that will give me hours of discussion with peers and students from the field (which field, UX/UI/engineering LOL):

"if you are fixated on how UX fits in a development method (e.g. Agile, RUP, Waterfall, etc.) than you are not a User Experience Designer at all but a UI Designer."

Thanks again.

Anouschka said...

Very nice article Jonathan! Nicely transelated in the wheels pictures, makes it more transparant although I also have some questions/doubts in how things are put in there... time to meet each other;-)

Perhaps you've seen this discussion : http://www.baekdal.com/articles/usability/usabilty-vs-user-experience-battle/

A bit of a different approach, what do you think?

Jonathan said...

@Anouschka Thank you so much, we should definitely get together it has been too long already. About the article link you sent, I am afraid that is exactly the confusion I am talking about. Both discussions are not only not leaving the UI design plane they don't even leave the usability plane, so far from comparing UX, UX does not even enter into the discussion I have seen, at least not as I understood it. I will add maybe a fourth part to discuss what UX is or at least how I understand it.

Billy-Bob said...

I'm not sure I buy the argument Jonathan (Ux versus UI).

The wheel looks (to me) more like the way in which one would go about designing a business than designing a user experience.

The range of skill sets required to perform all the activities on the wheel would require a broad assortment of expertise, e.g., marketeers, designers, engineers, fabricators, sales/merchandising experts, business planners, etc. Generally these skills are way beyond the domain expertise of any UI/Ux team I've worked with or on over the years.

If you had said "customer experience" instead of "user experience" I could have played along.

Jon Innes said...

Interesting post. I'm in strong agreement with most of what you write. A few things I don't agree with:

Strategy cannot be formed without consideration for tactics. Strategy that is not supported by tactics is just idle thinking...

The UX designer HAS to be concerned about development methods if they influence the UX delivered. You can't design in a vacuum. Design that doesn't consider implementation (including methods) is just art.

Your wheel diagram only shows labels for UX roles at the 9 o'clock position. Does that mean that's the only place they are engaged? I doubt you mean that. Most of what is shown between 12 and 6 positions looks like typical business activities. Most folks would argue that's not really UX work as you show it.

I'd argue that doing the user research you list just after 6 o'clock as pretty inefficient at that stage. Why not do ethnographic and survey work earlier as part of competitive analysis so it can inform business plans? Also, shouldn’t the UX team be involved in the brand design work providing expertise in personas, visual design, and testing emotional responses?