UX Strategy II: About the iterative diagram: What is it?

In the second part of this Strategy discussion, I will concentrate on the Strategy diagram from the previous post. This post will cover what the diagram is and who is it for. There are more issues than that to be complete, but I can always add an additional post if there is a desire to read more detailed information about it. [Note this post, like all my posts are revised based on user comments or feedback.]

Just to review from my previous presentation (see post below): this diagram is a way of anchoring the design process to key strategic activities thereby assuring both a true design process as well as a strategic execution of this User Experience design process. The alternatives that are in vogue now are either

• seeing the User Experience as a bolt-on to engineering processes
• 'Bolt-on' being American for: just embedding a UX process in to a software engineering process
• A software engineering process which is already cumbersome and unpredictable
• In general adding design process to software engineering process is like forcing the square peg into a round hole.
• or at best its own independent process that mimics a software engineering process

Where the UX process eventually turns into something that looks like some variation of

• a waterfall
• incremental design
• Some other variation of the straightest line between two points approach

The above points coupled with my belief that software engineering process is a contradiction in terms pleads for the necessity of this new diagram.

Figure 1: the UX STrategy Iteration Diagram

In general terms you can think of the diagram as a planning tool one can talk over with a program manager or client or even all key stakeholders during a workshop. You can also think of it like a hula hoop, somewhere, anywhere in the hoop you can cut it flatten out and make a project manager or software engineer happy to see a simplified overview of what activities you are going to do for the current cycle.
These diagrams can be stacked on top of each other and connected at key points to plan multiple user experiences among different channels, products or services. This would allow planning and illustrating hos a mobile product project can inform a web application project. Likewise a strategy iteration can inform a tactical one, etc.
The strategy diagram and the planned activities should be revisited after each activity and see if it assumptions are still valid or if it is time to iterate the activities. In this way the very strategy is iterative just as the User Experience. But before going into too much details, I want to discuss two points here:

• What is the diagram
• Who is the diagram for

What is this diagram

This diagram is an attempt to create a model for User Experience Strategy and in so doing create also an instrument for both:

• understanding User Experience Strategy
• planning an User Experience project for your
• company organization
• or heaven forbid for a client if you are one of those charlatan UX consultants like me.

The diagram consists of the following (names are provisional):

• Circles
• Elements
• Activity
• Properties

Circles

The circles represent iteration cycles. But iterations are centered on an element or two or more, but they have iterative effects also on its neighboring elements and then even ripple effects through the entire UX element landscape (see below). Even when an iteration confirms an already existing UX element it still strengthens that element and thereby changing it. The circles show the interdependent nature of the User Experience as an expression of a series of elements.

Elements

The elements are a major area of the User Experience, usually with one or more associated deliverables. In order to qualify as a major element in the User experience it must meet the following criteria”

1. Plays an essential role in UX products, services, and other expressions (brochures, ads, etc.).
2. Major risk to the resulting product and/or organization if this element is not ready.

With this definition it speaks for itself that each project/company/organization may have a slightly different diagram, but complete coverage is essential.

We (my colleagues at Stroomt and the helpful people who kindly mailed in their suggestions) identified a generic set of UX elements, namely:

• Mission Statement
• Vision
• Goals and principles
• Channels
• Brand design
• Business Case
• Business Plan
• Requirements
• Define product/service(s)
• Conceptual Design
• Detailed Iterative Design
• Evaluate and refine design
• Release product and plan for next iteration

Each of these elements must have a sufficient level of maturity and stability in order to release a product or service to the world. The User Experience Strategist is obliged to review the state of each of these elements. It is not the job of the User Experience Strategist to be the person who delivers or executes on these elements, UX is by nature multi, or I would say macro-discplinary. The UX Strategist is a facilitator first and foremost.
Figure 2 UX Strategy Diagram with activities

Activities

If these elements are not in an acceptable state then activities should be planned to bring them up to the appropriate level. It is not the User Experience Strategists job to perform all of these activities, or even any of these activities. Like the elements, the activities also require many different disciplines. The UX Strategist may be able to assist and find and support the right people to perform the activities. However the strategist is primarily concerned that all the information is available, up to date, stable and mature.

Properties

Both activities and elements have properties, these depend on the need of the organization, but can include things such as:

• Staffing
• Resources
• Start and end dates
• Deliverable requirements
• Budgets
• Etc.

Who is this for: Multi-disciplinary vs Macro-disciplinary

Last topic for this week: Who is this diagram for?
Well definitely not for the faint of heart.
The User Experience Strategist, Designer, Project Sponsors, Program Manager, Project Manager are those most to gain from getting this overview as well as wanting to be able to plan on a macro level. But the fact is, this is one way of getting all of the multi, or rather Macro-disciplinary team literally on the same page about who is doing what and how it all fits together.
I use the term Macro-disciplinary because unfortunately too often the word multi-disciplinary is bandied about to mean multiple disciplines without recognizing that these are mostly separate people. Most UI multi-disciplinary projects means the designer--or whoever the UI one man band is called-- is up late at night and weekends. They are also often caught talking to themselves in a desperate attempt to bring in another disciplines or perspective into their work. By Macro-disciplinary I want to show that it is impossible not to include many talented people with many complementary, but more often contradictory perspectives.
This last concept: contradictory perspectives is essential to every successful design project I have ever worked on. This diagram allows these contradictory perspectives to elegantly be laid plain in a map. It also allows you to plan activities for incorporating those perspectives back into the larger UX iteration so contradiction are resolved rather than brushed under the carpet.

Next week the UX Declaration of Engineering Independence.

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.

UX Strategy as told by the paintings of Jan Steen

View more presentations from Jonathan Arnowitz.

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