UX Design Basics, Part II

Bob

Good UX does not come easy. There are crucial things to consider, and even if we bear those things in mind: we have no guarantee that our product will enthuse our users. In spite of that, shall we really conduct UX design at all? This post describes what’s crucial for successful UX, addresses the limitations of UX design and tells why it’s worth to do it all the same.

CoffeeBoy Series Schedule

Preconditions for successful UX

We can’t expect boundless enthusiasm from our users just because we’ve build in THAT killer feature into our product. If the other parts (if any) of our product suck, then our users will be disappointed anyway. There are crucial preconditions for successful UX. Our product should fulfill them in order to have a chance to generate good UX at all. Let’s go through these preconditions.

Standard features

The product should have features which are generally expected by users. Let’s take power steering as an example. While it must have been an absolute killer feature in the middle of the recent century1, these days no automobile manufacturer can afford to leave it out. Users would not only be disappointed, but rather appalled.

Working features

Our product’s features should do what we’ve promised that they do. And if they don’t, then the least we should do is to, as quickly as possible, provide an update (in case of a software product) or, if not possible, a compensation. In all other respects the product will have little chance to generate good UX.

Usable features

The product’s features should have a flawless usability. A user interface tends to have a rather bad usability when it forces the user to think about the user interface itself, instead of the actual problem she wants to solve. A common example is a cumbersome navigation path to a certain function within a user interface.

So these are the preconditions. However, a product fulfilling them does not necessarily enthuse the users. It only satisfies the users’ minimal expectations. So how can we reach our users on an emotional level?

Factors for successful UX

We can enthuse our users when we integrate innovative features into our products. Features which our users didn’t expect in the first place and which aren’t available in products of our competitors. With innovative features we can gain a “Wow, that’s cool!” reaction of our users, even though these features might have a suboptimal usability. Right, under some circumstances innovation can beat usability.

A further success factor is to design the product’s appearance and behavior in a way the user subconsciously expects it to be like. In UX design the expectation about the appearance and behavior of a product results from the user’s mental model. It’s a simplified explanation of how a product works, without the inclusion of all the technical details. The opposite of the mental model is the implementation model. It describes how the product actually looks like under the hood. Finally the representation model is the one which actually gets experienced by the user. Now an essential success factor is to approximate the representation model as much as possible to the user’s mental model.

PlantBoy example

In order to illustrate the characteristics and differences between the three models let’s take a plant monitoring software product called PlantBoy as an example. PlantBoy should simply enable to monitor the health status, humidity and temperature of one’s plants which are distributed across one’s flat or house.

Now let’s look at the guy on the above teaser picture. He is the target persona of PlantBoy. His name is Bob, he loves his plants, he gives them names and even talks with them. When he thinks about his plants then he thinks about real personalities. As we can see he named his plants Gaz and Mia.

An excerpt of the highly simplified implementation model of PlantBoy may look as follows:

Implementation Model
Implementation Model

We see a database entity relationship diagram with two tables. The PLANT table contains information about a single plant and SENSOR holds the values of the humidity and temperature sensors. If we would totally ignore Bob’s mental model then the resulting representation model – in this case a simple user interface design mock-up – may look as below:

Bad Representation Model
Bad Representation Model

We see a pragmatically designed user interface featuring a grid which displays the aggregated data of the two database tables. Neither the property values are formatted (the status is “1” or “0” instead of “OK” resp. “Bad”), nor does the grid highlight any important information. And why the heck Bob should ever care about the plant’s id? The development of such user interfaces is very easy and budget-priced. It’s also possible to generate such user interfaces.

User interfaces “designed” by developers or people with a good technical background often tend to approximate the implementation model rather than the user’s mental model. They feel at ease with such user interfaces and forget or simply ignore the fact that they are NOT the target users.

A rather suitable user interface for Bob may be designed as follows:

Good Representation Model
Good Representation Model

We see that Bob’s beloved plants get adequately appreciated by means of a big picture. Moreover the health status of his plants certainly better catch Bob’s eye compared to the previous representation model. All in all we can feel confident that this user interface is on a good way to suit Bob.

Limitations of UX design

When dealing with a software product chances are good that it runs in the context of other products. Typically those products are browsers, operating systems and hardware devices. Shortcomings in those products have a direct or indirect influence on the UX of our product.

For example, a user presses a button in our mobile app and then has to wait 20 seconds for a feedback thanks to weak hardware components of the mobile device. Even worse, the operating system of the mobile device may decide to kill our app due to insufficient memory. These are examples for direct influences on our product’s UX caused by third party products.

Indirect influences on our product’s UX may be flaws within the platform running our software product, as for example an unstable operating system. Also other, bad designed products coming from our company may make it hard for our new, maybe better designed product in the first place. Once we’ve scared our users off it’ll be hard to regain their trust.

There are also sources for bad influences on our product’s UX which have a non-technical nature. For example, if our company produces bad news because it is involved in an ugly scandal, then this may have an indirect influence on how the users perceive our company’s products.

Do we really need UX design?

I’ve asked myself if there are really valid reasons to dispense with UX design in the context of a product development project. In fact, when you can make a check mark behind one of the following bullet points and karma is not something you usually deal with 😉 , then I congratulate for saving a lot of time and money:

  • You have a monopoly with your product and this won’t change in the near future. As long as there are none alternatives for your product within the market, chances are good that it will get sold well, even though it lacks in UX design.
  • You develop a software product for your company and it’s intended for internal use only. Furthermore the efficiency and satisfaction of the employees which will have to use it have no priority. Moreover the development project’s budget is significantly limited.
  • You develop a product because you are in dire need of it. So you are the target user of this product and exactly know what you want. Moreover you are the representative for a whole group of people who are exactly like you.

If you are not in one of the above positions, or simply take your product’s users seriously, then you might consider an integration of UX design into your product development process.

Doing without UX design does not necessarily mean that your product will be totally lousy. If you have experienced developers on board which are able to follow common design and usability rules, then your product could get accepted by users anyway. However, not addressing the user’s needs and desires can also mean doing without the following benefits:

  • Users’ enthusiasm and satisfaction which flows into customer loyalty.
  • Minimizing the risk of a failing product.
  • Having a product with crucial differentiating factors, especially in the face of a hard competition.
  • Long-term strengthening of the product’s brand.
  • Long-term strengthening of the product company’s image.
  • Better identification of the product company’s employees with the product and with the company.

For me as developer the last argument from the above list has the strongest weight. It makes me feel better and satisfied when I develop with the target users in mind. Even though I have not enough information about the target users, I always try to get an idea of them (By the way, that’s what we’ll also do when we’ll design CoffeeBoy.). In the end a pragmatic UX design process with from assumptions derived persona definitions as fundament is still better than an ignorant exclusion of the user.

Up next

Now that we’ve learned some UX design basics let’s pass on to the question: how can make use of it for the design of CoffeeBoy? In the next post we’ll cover the UX design process that’ll be applied for CoffeeBoy. Stay tuned!

Footnotes