Author: Old pull
preface
As the front end of the big front end era, we are increasingly confronted with the need to develop various internal products.
Without the professional help of product students, how can we technicians design an excellent product by ourselves, give consideration to both functionality and interactive experience, and make it stand at the crossroads of science and technology and humanities?
This article wants to talk about some of my thoughts on making products.
(It is in Apple’s DNA that technology alone is not enough — It’s technology married with liberal arts, married with the humanities, that yields us the results that make our heart sing.
It’s not enough to have technology in Apple’s DNA. It’s when technology is combined with the arts and humanities that our hearts will resonate with it.)
One of the things that we do is we often build our own products
I have used no fewer internal products and have been involved in the development of several. The interaction logic of the products I participated in were all designed by our front end. Everyone was very passionate, organized a lot of brain storms, and had a lot of fights over the product experience, but the final product was ridiculed by many users. What we found was that we made a product that we were happy with, but our users weren’t happy with. This makes people reflect, what is the problem?
There are several thought traps that can lead to this result
One, behind closed doors
We take it for granted that users will use the product as we expect them to, and we use our own perspective to make assumptions about their perspective. When we often bring this guesswork into our product design process to solve specific problems, we lose touch with real users. Wait until the product goes online, user collective scold niang, everyone just once by reality big mouth ba son smoke wake up.
Get bogged down in detail
The details here not only refer to the grinding of product details, but also refer to the entanglement of details. Introducing a complex solution to a small problem, for example, trivializes interactions or affects the functionality of other products. If this happens frequently, it can even affect the user experience of the product as a whole.
Third, programmer thinking
We often use normal programming thinking to design interaction logic and apply engineering concepts to products. For example, when I was creating a project with a product, I had to fill out a lot of forms, but some of the information was not required at the beginning. From a programmer’s point of view, we need to ensure that all information and variables are complete before we can start running runtime. However, if the user needs to provide complete information at the beginning, it will add unnecessary psychological burden to him.
To avoid these pitfalls, you need to do the following
First, close to users
Put people first. A lot of discussions come down to people. A product manager is only as good as whether he cares about “people”; A product is only as good as its concern for people. We need to get used to thinking of our users as emotional people like ourselves, not as mere code names like “users” and “customers”, or depersonalised buried data. If we can take a step back to the starting point of “people” and find the most intuitive way to interact with many interaction problems, we may suddenly see the light.
If the user is a developer, think like a developer who is actually using the product. If the user is a business or product, think of yourself as a real business. Only in the way of thinking close to users, it is possible to design interactive logic for users.
Keep researching. Many internal products have service groups and help and feedback portals in the product interface. However, these communication methods require active input from users and are more passive in collecting product suggestions. Most of the time, our users are inside of us, whether it’s the developers around you, or the operators and PD you work with. This is a unique advantage, so that we can seek their advice anytime and anywhere. By actively communicating frequently with our real customers, we can largely avoid guesswork.
Second, the big picture
To do anything complex that needs to be shown, the bones must be set up before the skin is painted. Because the cognitive processes of users, or humans, or all mammals, go from coarse to fine. So the big frame is always dominant. And the big framework of a product, often reflected in those most routine functions, the most important process.
Focus on the big and release the small. Product meeting will encounter some details but quite troublesome problems, everyone quarrel all afternoon, the more the more angry. You may end up with a plan that doesn’t work, wasting time and energy. We are unconsciously attracted to what we see. When we are talking about the overall plan, and someone asks a question in detail, we will naturally join the discussion. The more we discuss, the more excited we become. Make a conscious effort to pull your attention away from the details and back to the big picture. Let go of the details for a while. When we design the whole thing and look back at the details, sometimes it becomes easier to solve, and sometimes it disappears as the whole thing changes.
In the final analysis, only when the overall design is good, can the details play its value. Too much detail will hurt the product.
Third, pay attention to details
First of all, it should be noted that the details here are not in contradiction with the big picture. In fact, we are not against detail digging, but against the blind, to the end of detail digging, in the final analysis, we are against an “irrational” way of thinking.
Happy experiences accumulate, and so do bad experiences. When I experience a well-designed product and am occasionally touched by its human details, its impression in my mind will at a certain critical point produce a feeling of sublimation and establish a sense of trust, which I think is the human root of the so-called “brand premium”. Details are the soul of a product. Through the accumulation of little by little, users can fall in love with or hate a product. So you need to do a good job of detail.
First, work out the details in time. Sometimes we have more important features at hand that need to be developed, leading to small, obvious problems being put off. These issues can be a style bug or an unfriendly interaction detail that doesn’t take much time to fix, but may not be “cost-effective” from our perspective, or not helpful to KPIs. However, in the user’s opinion, it is just like a grain of sand in a mouthful of rice. No matter how delicious the rice is, his attention will be attracted by the sand, and finally he can’t stand it. He may swallow the whole rice, or he may spit out the whole rice and eat another mouthful without sand. Sometimes that’s how users get lost.
Users don’t like to guess what you’re thinking. We sometimes unconsciously complicate simple problems and use a complex interactive logic to solve a simple detailed problem. The result is a place that users actually experience and wonder why it was designed that way. Users won’t go through the same brain circuitry you used to solve the problem, and a complex solution is more likely to be counterintuitive. So when we agonize over a simple detail, try going back to basics and bringing the focus back to the user’s point of view.
Users don’t like surprises. I believe that many people and I, for a variety of reasons, have the misfortune to install a few rogue software in Windows. They can be in the installation of the time along with “default check” the means to you installed other a few belong to the same “rogue alliance” software, in the process of your use still play a window from time to time, when you want to uninstall it still installs pitiful, incidentally installed a few rogue software to you. You have no love for this kind of software, and the entire Windows ecosystem.
So you want to avoid joint operations. Although our own design products would not be so extreme, but also often make similar mistakes, such as the default check some reading notes, or when performing an operation help users to do the next operation, by the way, these help the user to make a decision, with no obvious hints of logic, will cause the user’s sense of surprise and confusion. Not surprising users is essentially a trust-building process — I know what’s going to happen and what’s not going to happen when I press a button. Over time, I developed a basic trust in the product.
Four, the most fundamental is: are you interested in making products
The above are some of my thoughts during the process of participating in internal product development and product usability research projects. Probably a lot of it is already known, and there may be some disagreement. But that doesn’t matter. What really matters is whether we can maintain the pursuit of good products and build the habit of thinking about products into our daily work. And it all comes down to whether you’re interested in making a product. Frankly, interest is largely genetic, but it can still be cultivated. Perhaps in the process of constantly thinking about the product, you will also find that you develop a love of the product and a good sense of how to design a good product.