Show me your UX work – The portfolio and skill assessment in UX.

By Bob Glaser ©2014

From whiteboard to delivery.

I am occasionally annoyed by the often misleading concept of the UX portfolio. The very concept of it is often paradoxical. Showing completed work doesn’t address the myriad problems and directional changes and all the complex dependencies that drove solutions that were used to achieve the result. When those problems and associated solutions are presented, it is often overwhelming. What’s worse, is that no one has time or wants to read a lot about the problems. The paradox is further strengthened by the request for demonstrating simple solutions to complex problems. By their very nature and designation, a complex problem is ostensibly complex. You cannot understand the rationale and elegance of the simple solution if you don’t understand the complexity of the problem, and not merely that the problem was complex, but how and in what ways.

How often have you been in development meetings or brainstorming sessions and had each solution knocked down by one countering practical reality after another, not to mention personal agendas. These practical realities may not be known until you suggest solutions. This winnowing process is often time consuming but important, because it progressively leads you toward the the better solution given current restrictions. I avoid the ‘best solution’ because I’ve not worked on many problems with unlimited timeframes.

You can pick one specific example to explain that, but often, that may not be the problem to solution process and result that the viewer of the portfolio is looking for. They want a specific match rather than an example approach. If that approach is generalized, then you run the risk of not being specific enough. I’ve had reviewers look at a project and say, “Well that’s not a particularly complex UI.” To which, I will respond that “The UX/IxD/UI specification document is over 700 pages long.” So we’ve quickly gone from “too simple” to “too much information”.

If samples of work appear unremarkable, that may be the point of good UX. Most UI’s though not all) are not dazzling spectacles of design. They also should not be. They should be making the task simple, easy and relatively intuitive to the user. When someone has just purchased a new big screen TV, then the chances are pretty high that viewing content is their goal. It is not about have a great memorable experience in turning it on or off or changing channels or inputs, etc. That kind of emphasis may sell a TV, but it’s going to be very annoying after it’s sold. This is why demo’s and demo modes on appliances and software should be handled as separate items from UX. It is not that they should not work together, but rather that they have different goals which are likely to be contrary in many aspects.

The process of UX design is the same whether you’re designing a child’s toy or an application for Enterprise wide data analytics. The more knowledge I have in the proposed genre (whether children’s toys or enterprise software, the more likely I am to have biases.) Overcoming those biases can be as time consuming if not more so than learning from scratch from the observation of users. The reason is that the skill set of the UX designer is in knowing how to gather this data, ask questions, develop a strategy and design a process based on best UX design practices, and be more open to considering alternative approaches that were previously discounted by rote because of no longer valid or understood reasons.

Over-reliance on visual imagery vs. function in UX

Because of this lack of time to read about the problems, the visuals that are presented are typically only the visual aspects of UX and the visual solutions that were used to solve them. The other aspects that are not so easily described in a visual manner, are the nonvisual aspects of the user experience and the intangible problems, processes and solutions used to address and fix those problems. If you start to explain issues that have to do with cognitive load, cultural acceptance, mixed but specific demographics, user data, affordances and so on, there is difficulty in simply explaining this in a portfolio. The very existence of UX designers is often about “simplifying the complex” but in order to understand this, you must explain what the complexities where that you were simplifying. Typically the UX designer simplifies the presentation of complexity without actually eliminating it. This is necessary in any complex application. There is often a tremendous amount of thought, research, trial and error that goes into wireframing that has nothing to do with the look and feel of the end product. At the wireframing stage, these problems need to be solved before moving on. This is not to say that the visual design is unimportant or even that there no visual design consideration during the wireframing process, but rather that wireframing includes a lot more attributes than the just the visual design structure. Also wireframing is meant to help identify structure, interaction, and flow prior to the creation of a visual language in order to prevent a lot of unnecessary design and asset rework.

As someone who started out as a visual designer working in medical publishing, I often saw an attitude between the writers and graphic designers that each thought that their output was the more critical information in an article. Collaboration was something that happened by force and necessity and each thought the others field was something that anyone can do. I thought, along with a few of the writers, that we were interdependent on each other, but this was not the common view. I know personally that often professional graphic designers (as we were called then) were viewed as having some mysterious internal gift for creating art. Not that there was a massive amount of formal training, technical knowledge, and the understanding that what we created wasn’t something that we liked because of some inherent artistic gift but rather a carefully crafted design that was appropriate for the purpose and the audience for which it was intended, whether we liked it or not. I also know, from personal experience, that I’ve created some truly hideous designs that were extremely successful, because they were properly designed in that manner. Any inherent aesthetic ability I had told me that some of these designs were hideous. However, it was my training and experience and knowledge of the audience that informed the best design for these specific products was not aimed at me.

This desire to dazzle and distract the user rather than really do what the user wants (which, all too often, to the internal team, seems boring) often stems from internal political pressures. The user will often say, “I find this difficult to use or understand” To which the response is some form of either “Yes but isn’t it pretty.” or worse, (whether intentionally or not) incorrectly reinterpreting the users reaction to one of boredom rather than annoyance or confusion. This is reinforced even more by the “I know what I want and I know everyone else wants it too.” type of bias.

Flash vs. substance

There are 3 aspects of this. First, the ‘kitchen sink’ feature approach, and the second is a new feature approach, particularly when the new feature is considered more important than the needed feature and third, the ‘fix-it’ or triage approach. Surprisingly often, the emphasis on flash blinds the designer and often everyone on the production side of a product from executives, to marketing, to product development to engineering to quality assurance, to implementer/deployment (e.g. sales, integrators, VARs etc.)

1 The kitchen sink approach

This is often more of a marketing requirement rather than a user need. This is a way of selling a product based on an expansive set of features to accommodate anyone. Unfortunately there is no one “anyone” individual. The most common individual user will probably rely on a few features at best. Depending on their environment, habits, and expectations, those few features can vary significantly from one user (and associated use cases) to the next. In each of these use cases, most of the other features are either background noise or may unnecessary cognitive load, annoyance or confusion. Here the UX designer has to address the issue by simplifying the UI to accommodate the different use cases. The methods used vary depending on size of user base, resources (time, money, etc.) and actual capabilities existing that allow the desired outcome to be implemented. Here’s where there can be a huge difference between first impression and second impression. On an enterprise level, I would call it the primary impression (decision maker/purchaser of the product) and secondary and on impression (the user who may have little choice in the purchasing decision.) The UX designer must manage these second(ary) impressions since the focus is on using and reusing the product and less on selling the product. This also means that the UX designer should make sure that business goals of Marketing and UX are aligned.

2 The new feature approach

This is also focused more on selling than using the product. In this case, the new feature may have been added based on user requests, new available technology or some other innovation. In any case, the adoption of the feature may or may not be as expected. If the new feature is based on anything other than user request, then there should be an expectation of slow adoption, even if the feature works exceptionally well. New features are competitive market objects which are often used as differentiators or to follow new trends in predicted (but not tested) user expectations.

3 UX as a ‘fix-it’ step in the process

When UX is introduced late in the development cycle, the work that is done by UX designers is more about triage than design. It’s too late and far too costly to redesign something properly, so while the intent is to make a good UX design, the end result is making a bad design, “less bad.” This also tends to put the UX designer in a defensive mode rather than in a productive one. This is because, their failure to completely fix a problem which was caused by implementing UX too late in the process, reinforces the bias that it is an ineffective skill set of knowledge and expertise. Sometimes we [UX designers] are lucky and are presented with problems that are easily solved. This is when, for example, myopic product design vision fails to see obvious simple usability problems that are easily fixed. It is the responsibility of the UX designer to indicate at cycle wrap up, that what was addressed was the “low hanging fruit” of the product and that substantial changes may still need to be made on the next round. What happens after that depends on internal politics. Dancing around the individual and group egos is just something that you have to learn in business. That is a different subject that’s beyond the scope of this article.

Internal resistance to change

Interestingly, in small but growing companies, every time they add a new department (like research, design, new technology etc., and which is often initially a single person) to the production mix (and I’m assuming for this argument that the department/person is knowledgeable and experienced in their field), there is going to be a moment when that new department is likely to say “The emperor has no clothes.” A well-run company will say “Then tell us what we need to do.” Often, though, particularly as you start addressing progressively larger companies the new department may be dismissed as not understanding what has been done so far. Even though the new department’s expertise didn’t exist previously, there is still resistance to this change. Often, the skills of the new department are diminished by considering them obvious or a commodity or something that doesn’t require formal training or specialized skills and tools. This is normal human behavior but bad for business. Nevertheless, the new department will often have to earn respect rather than being given it initially. This is not very productive, and the department can end up failing in the process. Many seasoned UX designers know that more time and effort is spent on defending UX improvements than is spent on presenting UX improvements.

Originality

“How much of what I’m looking at did you do?” This question varies as much in meaning from person to person who is asking the question as does to the person who answers it.

Consider the following:

If addressing a painter (art): did you create this image entirely from your imagination (which is still derivative), Did you gesso the canvas?, Did you stretch the canvas yourself? Did you weave the linen? Did you grow the flax? Did you make the canvas frame? Did you cut the wood for the frame? Did you grow the tree that the wood came from? And so on with the pigments and brushes and any other tool used in the painting creation.

This example above shows that there may have been many people involved with the creation and production of a painting. While the example may seem ridiculous to many, it strikes close to home when dealing with a UX Designer. While reviewing my own portfolio, I can can point out myriad attributes that someone else or some other group was responsible for even though I may have had intense input and responsible for designing many of the assets or other more trivial aspects of UX design and production. These are irrelevant to me.

I’m more interested in the ability to use tools and resources, rather than making sure everything is original. Not everything needs to be a new invention. The great majority of the time, good UX design comes far more often from simplifying the UX than it does from coming up with and ‘innovative new concept’. Innovation is typically (though not always) more cost effective than invention is so you don’t have to waste resources “reinventing the wheel.” To that end, if you are replacing the wheel with something new, is it truly better or just ‘new’.

Consider the iPod. Here was a product that had virtually no invention (in terms of UI/UX) but rather innovated the world of UX in terms of creating an aspirational experience that superseded all of the prior mp3 players (and there were hundreds on the market when the iPod came out. There was little invention in this product, but rather a very clever marketing of music via the ‘experience of the iPod.’ A great majority of consumers [still] have a perception that Apple was the first to release a personal digital music player.

UX Design Knowledge ≠ Domain Knowledge

There is a counter-intuitive requirement that the UX Designer needs to have domain expertise in the product/marketing space. I have found that this concept seems like a no-brainer to the product developer. If you are going to work for a company that produces software for data analytics and solutions or a company that is producing an electronic music instrument for children or produces jewelry and accessories for the fashion conscious woman on a budget, there is this misguided idea that the domain knowledge and experience that is required is essential for the UX Designer. This myopic view causes problems for a UX designer. Prior knowledge also creates biases. Any good UX designer follows a process that includes determining the product features and functionality, research to determine an unbiased definition of the target user (interviews, persona creation, etc.), amongst a number of other process steps. Prior experience is more likely to prejudice the UX designer to draw premature conclusions. Learning the domain from scratch will often reveal more opportunities and expose areas of need in the existing products (if they exist.) This allows for creating more innovative UX because of the fresh outlook rather than innovation for the sake of innovation (which often has a poor ROI.) The more objective I am as a UX designer, the better the results of my work will be. This objectivity also helps reduce becoming emotionally attached to particular concepts and defending them without a solid foundation of logic, data, and testing.

Legal issues of IP

I’m curious as to how many companies want to see samples of your wireframe work, or specification documents, strategic UX planning etc. but don’t think that doing so would be breaching NDA’s or inappropriate (even if unintentional) requests to see the inner workings of another companies products and processes. I know I have to be very cautious of this sort of thing, but it seems oddly hypocritical to disallow you show your work for them and yet they want to see detailed work of others. Additionally, by the time you may be able to publicly display the material, it’s often old enough that it’s age alone will draw more focus than the solutions provided.

Concluding thoughts

I don’t think the requests for a UX portfolio are going to stop, but I believe that until we address the concepts of UX design as far more than merely a visual portfolio, it will be deemed an acceptable practice. Sadly, this means that good visual design may push a good visual designer into a UX role they are unequipped for while the right UX professional sits waiting. This also includes the fact that the visual designer, who may be brilliant in design, might be forced to do work in areas that they don’t want to be doing. The same goes for the coder.

“UX” is often tacked on to job titles without any real understanding of what UX designers do, or with the belief that UX design is a minor adjunct skill. This means that the job description and actual responsibilities relegate less than 20% of work to UX design, while the majority of the work that must be done is coding or visual design, or even marketing.

So if a job description places requirements of ‘expert knowledge’ in areas other than UX and then the UX requirements are looser, such as “Must be familiar with UX/UI best practices.” then the area where expertise is required is what the job is really about. The issue is not whether I have expertise in these areas but rather that the job is less about UX and more about the areas where “Expert Knowledge” is a must-have requirement.