By Bob Glaser ©2014

We make hundreds of assumptions every day. We have to make many of them to simply be productive. A very high percentage of them are reasonably accurate enough to meet the needs of any and every situation, often regardless of the situations importance.

The longer we live (given environmental and circumstantial uncertainties), the more we are likely to believe, with increasing certainty, that the assumptions we make are true. This is accurate up to a point. That point is when cognitive biases like confirmation bias, stop us from correcting errors.

Another cause of rationalized support for assumptions is the incidence of needing situation specific survival skills in the form of uniquely personal emotional tools may help an individual survive the high risk situation, but end up being destructive, once the risk is removed. Examples of these situations are children growing up in extremely abusive situations, a soldier returning from combat, an individual developing a drug dependency to address a situation that no longer exists like pain or environmentally triggered anxiety. I won’t be addressing these survival skill based assumptions because they vary too much in both cause and effect, from one individual to another.

Observing the User

As UX designers, we need to curb the use of assumption when silently observing the user. If we are doing a good job at observing, we are taking down facts of an interaction and set of observable behaviors. If there is any supposition based on assumption, it should be made after all the facts are recorded, and not during, since these assumptions are then highly likely to color progressive documentation of facts. We will begin to ignore those that don’t meet the assumption and placing undue weight on those that do meet the assumption. While this may seem obvious to most UX designers, it is often not followed methodically.

1. Get the facts first
2. Ask your predetermined survey questions next, separating:
   1. Qualitative data
   2. Quantitative data
   3. Ask your soft or open questions last.
   4. After all the participants are done, then you can start making and testing assumptions.
   5. Rework and iterate for next round.

It is a great example of how extra work done early can save a lot of time and money later. It is also gives you the opportunity of determining if a high success is due to the design working as intended (this is a very common ego based assumption) or if a high failure rate is caused by an assumed deficit. High speed, high iteration groups tend to make this methodical practice difficult to follow. What must be explained in terms of the project and ROI, is the importance of rigorous adherence to maintaining this clarity of distinction in terms of what assumptions were made.

Consider the following hypothetical where two successive pages of a form on a website are presented to the user. These two dialogues were the bottom of two successive form-pages. The later of the two was the last page in this three page form.

Bottom of page 2, below:

Bottom of page 3, below:

Given the lack of clarity that this causes, there are several possibilities of failure here.

1. The repositioning of the buttons even though they are logically in the same order
   • Left to right followed by top to bottom: 1 Enter text, 2 continue, 3 cancel
   • The position of the “Continue” on the first page is where the “Cancel” is on the second page. (Maintaining common location but with contrary actions.)
2. The changing of the wording.
   • The “Continue” button is two words on the first page but one word on the second page while the opposite is true with the “Cancel” button.
   • There are no words in the “Continue” button that match from page to page since “Submit” is used on the other page.
   • It may not be clear to some users that “Submit” may be for completion of the entire form and might be a dual action button that both saves responses and submits the form as completed. Some users may assume that there is no going back after submission, while others may assume that there will be a confirmation or possibility to edit responses afterwards.

The mistake commonly made by the UX designer, is considering one assumption instead of both (along with the possibility of others.) In spite of this being based on a real page that is currently in use by a major company, this is a somewhat severe example but sadly, not as uncommon as we’d like. There is an actual need to determine: “What is the most common reason for failure?”, based on factual observation. Then a reasonable follow-through would be to make sure that the target demographic has expectations that can be met by the redesign.

This leads next to the sweeping generalization of the type that is based on large group averaging and may need to be presented as such. It is acceptable make reasonable sweeping generalizations to make a point, but it isn’t acceptable when there are specific demographics that are being addressed. In those cases, the sweeping generalization could be flawed if the specific demographics total far less than a significant sample of all people. The sweeping generalization could also be flawed or if the sweeping generalization covers a range of objects of which the specific product being designed is only a small portion (e.g. business app. vs. consumer app.) or different paradigm (e.g. virtual vs. real object). There are many examples where a product is intentionally marketed and designed for an audience who is contrary to the general population despite the general population’s view of the target group. A good example here is the high-end audiophile consumer who wants tube based amplifiers and vinyl disk playing turntables for it’s ‘closer to real’ analog output and it is not because it’s ‘retro’ as the general population may perceive it.

The assumption of intended use

There is the example of the unintended function that is discovered or whose use is reimagined by the user and may surpass (exponentially) the intended function in the use of a product. This may come from need and basic adaptive use, like using a napkin folded to create a shiv to balance a rocking table that’s on an uneven surface. In this example, the problem and solution are obvious and the variable is in determining what is available in close proximity that will meet this need. Usually paper goods are chosen since they be folded to match the correct thickness (an additional sub variable) to solve the problem.

Take Facebook for example. Its original intent was to have a more narrowly focused user group of college students, in fact, it was narrower than that (first Harvard only, then Boston Colleges and Ivy League and Stanford.) It was restrictive by intent. Mark Zuckerberg and others recognized the monetization of the service by making it available to all. This was not accidental but rather smart observance of serendipity. There are countless other similar examples from children’s toys to pharmaceuticals.

The failures come from the apparent security of maintaining the status quo and not wanting to annoy the existing customers. Stay with the idea of “This is what we are known for”, so we can’t deviate from that path. Sometimes you must deviate and sometimes it’s adaptation by dropping a rigid business model to a more flexible one, changing the target demographic, adding/deleting/prioritization of functions, etc.

How to address the facts and assumptions

Be cynical. Don’t move forward thinking that the facts and assumptions are presumed correct.

1. Remember: if you think that you’ve made no assumptions, then you’re already set up for problems unless you’re just plain lucky. Everyone make assumptions. Due diligence is required here.
2. Clearly document and label assumptions and facts as different entities. This doesn’t have to be done in any complex way. Sometimes, something as simple as text formatting can help you keep these sorted.
3. If errors show up later, go to your assumptions list first as this will save a lot of time. If the problem can’t be found there, then consider that there may be an error within the facts.

A personal example of effectively over-riding the common assumptions:

I managed to do something similar to these approaches when I was working in a small self-defined team. The numbers we were dealing with weren’t as massive as Facebook (few are) but they were exponentially greater than the original intent of the project we were working on. We fought diligently to solve a problem that no one perceived as a problem because of common group assumption. This was only a team of three, myself as the UX/UI Visual designer, a Human Factors Engineer to deal with the ergonomics of the machine, and an Industrial Designer.

The problem was identified when the mechanical engineering and R&D came up with some significant innovative and patented invention improvements and features. There was a proposal to make this device suitable for a larger segment by making it a scalable table top machine rather than a built in machine. As with all previous machines, it would use a simple black and white LED UI screen that gave feedback on settings and allowed for process counting (items completed by the machine) and would also require a trained dedicated user.

We proposed a color screen. In order justify the significantly increased cost of it. We had several weeks to come up with a rationale for its implementation. ROI, was the prime focus for a machine that would probably start at $20K for the simplest model.

We brainstormed, and ended up designing a prototype interface that would allow an untrained user to operate this machine. The primary assumption we were discarding was that these machines always have a dedicated user who is well trained. We had no budget beyond the time we spent in its development. So we had to discard common assumptions and make many new assumptions based on heuristics, experience, and simple user interviews. A bare bones user centered design. We gathered data from SW Engineering and Mechanical/Electrical Engineering to validate capabilities and information from Sales and Marketing via the marketing requirements document. We created a sample use case as our demo of user flow. One that would address the highest number of critical problems. We also considered a number of use cases so that we didn’t paint ourselves into a corner. This way, our sample use case in the form of a predefined workflow covered all of the top issues and would be factually defensible in presentation.

With the collaboration of my two colleagues, we designed the basic simple UI of a very complex system. I created the layout, graphic elements, and pseudo-prototype and with the help of the human factors engineer to determine the ergonomic considerations. The industrial designer on the project designed the first rough, of a product typically used on a factory floor, to look like it could look elegant in an office.

We presented our case to executives and major stakeholders. It passed and was implemented. Its success was demonstrated on the day it was released for sale (a few months after a completed prototype was demonstrated at a national convention.) Manufacturing had already built a projected 6 months’ supply of the products which sold out in 3 days. This was a product that ended up selling for between $25K to over $120K depending on the configuration. The majority of the sales were made based on the fact that a dedicated and trained operator would not be required for it.

This is not to say in any way that our solution was flawless, but it was magnitudes better than prior solutions on similar as well as more expensive machines.