User Experience (UX) seems to have recently become ‘trendy’ (and I mean this in a disapproving sense.) It all happened because effectively UX has become a vaguely defined buzzword. UX should be thought of and referred to as a specifically defined and equally important part of a product life cycle chain. In this article I would like to address the concept of a product life cycle and the UX element of it.
It had occurred to me several decades ago that any portion of a company’s product life cycle for which an individual or group was responsible, was biased by the individual (or group) as being more important than the other stages. Whether the product was tangible (physical appliance, website or software, etc.) or intangible (service, consultancy, etc.) was and is, subsequently irrelevant. Each individual or group often saw their contribution as being the most critical to the product. The individual departments in the process of development may be siloed, by choice (for autonomy), by precedent (it was always that way), or by structure (an unintegrated acquisition.)
The Product Life Cycle
Below I have listed the most common elements in the product’s life. Typically, a department, individual, or group is assigned with the charge of the element:
- Concept
- Research
- Development
- Content
- Architecture / Flow
- Prototyping
- Testing
- Fixing
- Usability
- Visual Design
- Implementation
- Marketing
- Sales
- Installation
- Support
- Training
- Upgrade and/or Replacement and/or ‘end of life’
While all these elements are in a rough order, depending on the product, the order or number may change as some may not be relevant to a product. (e.g. ‘upgrade’ may not be relevant for a one-off product.) Some of these areas may be clustered into one individual’s or one group’s purview, depending on the company’s structure (size, product type, market, etc.) Additionally, there may be elements which have not been listed here and which are specific to certain types of companies (e.g. elements prior to ‘concept’ such as ‘invention’.)
These elements make up a complete chain of a product’s life but do not necessarily define the process as this may include all of them even though in different ways. For example, some may be involved in one step in the process whereas others may be involved in two or more steps (due to iterative correction, market changes, supply or technology changes, etc.). The number is first based on need and requirements, then comes the connection of the correct number of links at the beginning of the development cycle. There are some companies that erroneously think that some of the elements of this chain are unnecessary so as to justify cutting their costs but they do so at high risk.
No Link In The Product Life Cycle Chain Is More Important Than Another
What is most interesting though, as I noted earlier, is that with many companies, the individual or group charged with any one specific element tends to often think that they are singularly the most important link in the chain without the perspective of seeing that it is in fact a chain. As obvious as the old expression “A chain is only as strong as its weakest link.” is, it is often lost in the noise of company politics and personal agendas.
This manner of looking at a product’s life cycle produces some biases and reinforces others. It allows for an environment in which it can cast blame incorrectly for certain problems while taking credit in a similarly unbalanced way for success. You would think this is obvious, but it’s becoming more and more common in businesses.
Then Why Do Some People Think So?
It is easy to see how these types of problems are created. Necessarily, disparate concepts between grouped or individual skill sets which span from one end would be based on empirical data to the other end which is based on generalized cognitive perceptions. For example, an engineering researcher may require that the results of their work be based entirely on statistics or even more specifically on results from formulas which will produce a specific result or range.
This does not mean they must be devoid of creative methods for problem solving, but rather that the results be measurable and repeatable.
Reason #1: Lack Of Understanding
On the other hand, there is the visual designer who will make aesthetic choices based on years of experience. These are based, amongst other things, on behavioral responses to design decisions. These are not easily measurable, since there are so many possible variants that the visual designer weighs and then quickly incorporates or rejects as the design process progresses. It is easy to see how these two different areas are dealt with in what seems to be an almost diametric manner. The engineer wants to see numbers and algorithms which are clear and directly applicable and shows the visual designer as being unscientific and arbitrary. Conversely, the visual designer will see their work as being based on the result of human behavior and not simply a set of numbers which eliminates the variability of the cognitive and social mind.
Reason #2: Ego
The other way on which these types of problems are created is not one based on lack of understanding as in the previous example, but rather based on ego. Whether that ego is expressed in terms of insecurity or in terms of power and control, the result is placing uneven weight on some links in the chain vs. others for the purpose of localized (being their own area of responsibility) success over other areas. Regardless of whether the rationale is for personal gain, or self-preservation, the result can create a weak link in the chain which causes the failure of the entire product. This is also the point where the risk of ignoring or dismissing one of the elements of the chain produces problems which end up creating a need to cast blame. Most often this is done on one of the ‘links’ involved rather than the fact that another was not included.
Every marketing student learns early on that no amount of brilliant marketing can sustain results of a bad product. I emphasize ‘sustain’ because brilliant marketing can get the product into a massive number of hands, but it cannot continue if the product itself is faulty at some level. This applies to all the links in the product life cycle chain.
User Experience (UX)
The breadth of a UX designer’s charge encompasses the entire chain but doesn’t control it.
Problem #1: Misconception Of What Is A UX Designer
It is not uncommon (at present at least) to relegate good UX design as a mere adjunct to another skill set. This is evident by its overuse or dismissive use in many job titles. Often, I’ve seen jobs that are titled “UX Designer” when the description will be that of a visual designer with “some UX experience” or the description will indicate that they are looking for website developer with “some UX experience.” The telltale giveaways to these are, in the case of the visual designer, many references to aesthetic requirements like graphic portfolios with lots of designs to be viewed with minimal description of problems addressed, processes used and how solutions were devised.
A sort of “spectacle is more important than structure” prevails. On the coding side, there are all the references to “must be an expert in HTML5, CSS3, JS, jQuery” etc. A person who is an expert in these areas, will have little time to do significant UX work since coding (or scripting) is a time consuming process and the more time spent on perfect code and all that entails (such as portability, responsiveness, documentation/commenting, reusability, etc.) indicates again that real UX design is a minor adjunct skill.
Problem #2: Misconception Of What It Takes To Be One
These views are often based on the oversimplification of UX being a ‘common sense’ skill. “Common sense is not so common” attributed to Voltaire, is a maxim to remember. UX design includes incorporation of intuitive flows. These are not based on common sense at all but rather on user expectation. This includes the specifics of the target user and their experience (culture, knowledge, age, environment, etc.). It also requires careful consideration and testing, particularly if the concept of the flow is new or if it is one which has been built on biases (e.g. the context based expectation of position of integers on a 3×4 numeric/calculator keypad above left vs. a 3×4 phone keypad above right). While it is true that you set or guide user expectations, they first need a common reference point from which to start. I prefer trying to avoid the use of the phrase “common sense” since it is very subjective.
Problem #3: UX Is Viewed As A Stand-alone Process
The other area of oversimplification is a point I addressed earlier. User experience is not a step in the process. User experience encompasses the span of the life of a product in the user’s realm. Their first awareness of the product, their first impressions of seeing it in action, the purchase process, the ‘out of box’ process (delivery, installation, assembly, initial use, etc.), the regularity of the product (i.e. ‘daily’), the support for problems not addressed by the product directly (i.e. calling tech support vs. user directed error recovery), the upgrade or replacement or end-of-life processes. Too often UX is simply used to define the subset of the UI. There’s far more ‘experience’ to be had than that alone. Another problem from this oversimplification is that UX is applied too late in the process as if it were a triage to address only the most egregious problems with a product being far closer to the end of the development cycle than the beginning.
UX And The Product Life Cycle
This is why the collaborative aspects of UX are often more important than with other areas of the chain. As a UX Designer, I need to work with Marketing, Sales, R&D, Engineering, Systems, Support, QA, and many more. It is not simply a single step in the process. I need to get information from them and provide them with information for their specific point(s) in the process. I realize that my portion of the chain needs to be strong, but I also realize that it is only possible by working collaboratively with every element which will have an effect, directly or indirectly, on the user’s experience.
The UX designer’s task is to be aware of all this, address the problem with viable solutions, and convey those results to any and every element with which it is associated within chain. It would be foolish of me to think I had responsibility of the entire product, but if for example an application crashes, I’m not the one who should be responsible for debugging the app. That would be the task of the software engineering. Nor would I be responsible for determining why crashes happen as that would be QA or tech support (depending on the point at which the cycle happens). The UX designer’s responsibility is to convey the effects of the crash on the user and what those results would mean. As any UX designer knows, this isn’t a “one size fits all” answer. The answer could be one of annoyance, even leading to catastrophic loss, depending on the situation, and I should be aware of that before conveying its results and affects.
No one link in the chain can be uniquely responsible for the success of a product, but one link can be responsible for its failure. However, it should also be noted that the failing link ought to be noted by any other subsequent link following it. This last statement puts the UX designer as someone who should have the means to make that assessment and convey it before it goes to market. If the warnings are ignored then there are other issues to deal with that are outside of the responsibility of UX design.
Want to learn more?
If you’re interested in the managerial and strategic aspects of UX, then consider to take the online course on UX Management and Strategy. If, on the other hand, you want to brush up on the basics of UX and Usability, then consider to take the online course on User Experience (or another design topic). Good luck on your learning journey!
(Lead image: Depositphotos)
