Let's start out with a lie, shall we?
When I first started applying what I learned from books and tutorials about UX design, I found out that each method worked amazingly well.
Well not exactly.
Applying the design theory you know in real life is really hard because of the situation you are in each project.
Some projects you join in the beginning, some you join at the end. Some have large team sizes and some you are the sole designer.
Thus, I realized early on I had to learn to ask the right questions to identify the roadblocks and constraints of any project before I learned to solve particular problems.
There are many great "how-to" books in UX design such as About Face by Alan Cooper.
Yet, they don't teach why these techniques exist in the first place and in which situations they should be applied.
Today, I will talk about one of these books called The Elements of User Experience by Jesse James Garrett and 5 things I learned from this book that I still use to this day.
A well-designed product does what it promises to its users
Every product we use from simple scissors to mobile applications makes us a promise. Either through convention or perception, we believe if we squatted on the chair 90 degrees, it will support our legs and it won't break.
We believe the scissors will cut simple thin linens.
We hate that chair that screams at our faces that we are fat with its squeaky response when we sat on it.
We despise the scissor that mocks our grip power when it fails to cut that piece of paper.
Thus, we hate products when they fail at the simple things we thought and assumed they could do.
That is why Jesse James Garrett says:
" A well-designed product is one that does what it promises to do. And a badly designed product is one that somehow doesn't."
A badly designed product is not a product that can't do everything. It is not a product that doesn't have many features.
Seriously, if a scissor does not turn on your Netflix you don't get pissed off.
Thus, the goal is not to add new features to a product or make it do everything but make it do a few things that its users expect it to do well.
What is the difference between designing a product and designing a user experience
Now, here is a question for you. I want you to look at this beautiful pair of scissors:
What are the things you can do with this pair of scissors?
These are all of the examples I could come up with:
- cut stuff
- use it as a stress toy maybe?
- This is difficult!!!
Now think of let's say using Spotify. How many things can you do with this product?
You can do:
- Search for new songs
- save songs
- pick your taste in music for recommendations
- create a playlist
- delete a playlist
Now, the difference between the two products is that Spotify is way more complex than scissors. You have complex behavior with it and the user has too many more interactions such as typing the song they want to listen to compared to just picking up the scissors and cutting that piece of paper.
That is why Jesse says:
"But the manufacturers of chairs and tables tend not to employ user experience designers. In these simple cases, the requirement to deliver a successful user experience is built into the definition of the product itself: In some sense, a chair you can't sit on isn't a chair at all.
With more complex products, though, the requirements to deliver a successful user experience are independent of the definition of the product."
Decisions at the beginning of a project has ripple effect
Fucking up in later parts of the project is way better than fucking up earlier in the project.
You messing up when wireframing, you can redo it again it would take 10 hours but hey not bad.
If you mess up in the scope, planning phases of the project, if you are solving the wrong problem, you are kind of wasting your efforts.
I don't know about you but I always feel an itching sensation to get through the research phase of the project. Maybe it is because I am more lenient to UI design yet the research phase is important for a reason.
In my previous guide, I told you guys that the research phase before any sketching will help us figure out what problem to solve and after that everything we are trying to do is to figure out the right solution.
Solving the right problem with wrong is solutions is often better than solving the wrong problem with the right solution.
That is why Jesse says:
"This dependence will mean that decisions on the strategy plane will have a sort of "ripple effect" all the way up to the chain."
Any decision you make early on during the planning and scope stages of a project will influence all of your design decisions.
Prevention > Correction > Recovery when it comes to errors(pg 87)
Did you know in 2018, there were over a hundred fifty thousand motorcycle accidents in Canada?
Now, I will ask you a stupid question and you will answer okay?
Why do you think we have "stop" signs at all?
Seriously, if we have breaks in our cars or motorcycles why do we need these wankers? :
Or here is a better one why do we need breaks at all when we can simply help people recover in one of these dreaded places:
The answer is simple. The "stop" sign's functionality is to prevent accidents. In any complex system such as traffic, the prevention of errors is key.
That is why Jesse says:
"The first and best defense against errors is to design the system so that errors are simply impossible."
Yet, almost in all complex systems errors are going to happen. A drunk asshole will not see the stop sign until it is 5 meters before.
That is why James continues his explanation of the second technique to decrease errors ina system. He says:
"The next best thing to making errors impossible is to make them merely difficult."
To reduce the chance of accidents, every car has a break so that a drunk person can still press on breaks and prevent the accident. This is called a correction.
Yet, even this is not enough. Some car accidents will happen because the correction measures will be taken too late.
Thus, we arrive at the last resource which is mitigation and recovery. Which is why the victim of the car accident ends up in an emergency.
Therefore, we have the following formula when it comes to handling errors: Prevention > Correction > Recovery
Prototype complexity depends on the organization
I had this first question when I was developing A VR app for chemistry students at my University.
I had asked myself: "Should I make this a detailed wireframe with UX writing and clear explanation? Or should this be just a general one?"
I picked the latter one and I still regret it. It was the wrong decision.
The reason why I picked the wrong one is more important though. It was because those were the wrong questions.
The question I had to ask was:
"What are my constraints?"
I knew that after my team and I have shipped the current version of the product, a new team would take place and that team would need a good design guide.
Constraints matter a lot to determine your sketches, designs, prototypes. That is why Jesse says:
"Some of the most successful wireframes I have ever worked with have been nothing more than pencil sketches with sticky notes attached. For a small team in which the designer and the programmer sit right next to each other, that level of documentation is perfectly sufficient. But when programming is the responsibility of an entire team and not just one person- and that team is halfway around the world -something a bit more formal is probably called for."
Thus, a prototype being general or too specific depends a lot on variability such as:
- Your deadline
- The team size
- When you joined the project
- Company size
Instead of answering that question myself for the VR project, I should have talked with my client and teammates to clarify the above points and then make my decision.
Call to Action
What are the books that influenced you recently and changed your assumptions about your field? Write in comments ;)