Basic concepts of UI
User Interface (UI for short, also known as User Interface) is the medium for interaction and information exchange between the system and the user. The user interface is designed to interact with each other and related software between the user and the hardware. The purpose is to enable the user to conveniently and efficiently operate the hardware to achieve two-way interaction, so UI is a service.
UI service and gameplay design
This principle is placed on the first article of UI production. It is to remind everyone in the project at all times-gameplay design serves users, and UI design serves gameplay design. This principle may be very exciting when talking about it, but in the actual production process, we usually forget it. The reason why it is said to be "serving", first of all, there must be a spirit of service—that is, not changing the needs of the "upstream", and at the same time better expressing the characteristics of the "downstream" to make the "upstream" comfortable.
But unfortunately, most of our game UI productions will violate this principle. The most common example is: the original gameplay was designed with 4 passive skills for each character. Finally, it was found that the UI was "stuffed", and 3 were just right. Therefore, the gameplay is required to be changed and become 3 passive skills. Such thinking is not allowed. UI serves the gameplay, so the gameplay here is the law and cannot be changed. When encountering a problem, what we should do is to sort out our ideas, re-study and re-design, to solve the problem, instead of thinking that it is simple or the fastest to change the problem itself.
Kruger's 3 laws of usability
1. Don't want to think
This is the benchmark for good UI design in any software. An interface should be very easy for users to understand, and they are often based on some conventions. "Unless there is a better choice, follow the standard."-AlanCooper, the father of interaction design.
As the UI of a mobile phone game, we can occasionally use the popular UI design methods on the market (but it should not only be a successful game, but should appear in most games to form a standard), but the mobile phone standard Some of the UI controls and interaction methods are our real benchmarks. Don’t feel that it is completely different from other mobile applications because it is a game. At the user level, the habit of controls is developed by the mobile phone, not the mobile phone. Game development-no one really buys a mobile phone just because they want to play a game.
In addition to some "never seen" designs, there are also confusing ones, usually because the designed content is deceptive, ambiguous or ambiguous, making users feel that they should not do it This interaction occurs, but this kind of "underwhelming" is not formed by thinking about strategies or making decisions.
Second, the UI identity
The result of the choice is surprising, usually because the user's inertial thinking made a choice, only to find that it was completely different from the imagination (violating the "conventional practice"). This "violation" includes, but is not limited to: a surprising UI control, a button whose feedback does not match what the prompt (icon or text) implies after being pressed...
If the blue one is a list that is dragged up and down , Drag it up and you can even see the contents of Article 4 and Article 5, which is really a surprise!
The number of clicks does not matter, but it must be meaningful every time: many times, we will emphasize the concept of "convenience", and the so-called "convenience" bluntly means "do more things with fewer clicks" ". But in fact, this is not really convenient. The so-called convenience does not care how many times you have to click on the button, it just needs to have its meaning every time you click.
3. Cut out half of the text, and cut the rest in half
There should not be too much text on the interface, unless the interface is used to express text, such as the interface for reading books. The text (including numbers) in a good interface does not occupy more than 25% of the area of the entire interface, preferably about 10%.
When designing a UI, especially the UI of a game, we should give more consideration to using gamified elements to do this: For example, the attribute title is more suitable than the text Caption and icon; for example, it is more suitable than a report, radar chart or A histogram would be more appropriate; for example, a progress bar would be more gamified than a percentage number such as "33%" or "355/1200".
Hick's Law
The more choices a person faces, the longer it takes to make a decision. Compared with 2 options, it will take longer for people to make 5 options.
This is very important for the grasp of the overall rhythm of the game-instead of selecting a task from a list of 60 tasks, first select one from 8 chapters, and then from 7 to 8 tasks under this chapter It would be more appropriate to choose one of them. At this point, the picture of the national tour has done a good job.
At the same time, seeing too many choices not only makes people uncomfortable, but also makes people give up choices. Hina Iyengar, a professor at Columbia University School of Business, pointed out in her paper "When Choices Make People Lose Motivation" that consumers are more likely to buy jam when there are fewer choices. When faced with 24 different jams, 60% of consumers would stop and try jams, and only 3% would buy them. When faced with 6 different jams, 40% of people would stop and try them, but 30% would buy them. When the choice seems too difficult, people will choose not to make a choice.
So, don't give your users too many choices. When there are too many choices, you can consider "wrap it in one layer."
Law of approach
Gestalt Psychology: When things are very close, consciousness will think they are related.
The user will subconsciously think that the area in the above picture is divided into 3 blocks, each of which has 2 upper and lower parts. Therefore, if the "button" in the lower left corner (lower part) is associated with the middle "panel" (upper part), whether it is associated with the left "panel" or not, it will make people feel uncomfortable.
Occam's Razor
It is a simple and effective principle, and the representative discourse is "If it is not necessary, do not add substance." We usually like to do addition in the "design" process, and constantly use "more convenient" and "more comprehensive" to convince ourselves, but for a designer, doing subtraction is the most test of skills.
When you add too many additions to your design, especially the interface, not only will it not be as convenient as you think, but it will become unusable-it is more difficult for you to find what the interface wants to "say"; At the same time, it will thoroughly hit the tone of your product, the flow of each function, the interface it has experienced, and the content of the interface at each step, all have a "tone".
The Occam's razor principle is a watershed between ordinary users and designers, and only after mastering it can they be qualified as a designer. Therefore, as a designer, in any design, don't forget to "do subtraction".
The design process really understands a gameplay and understands the tonality in the gameplay
Before actually designing a gameplay UI, the most important thing is to understand the "upstream", that is, the core tone of the gameplay, including but not limited to:
What is this gameplay? Is it a player's effort to give back or verify the gameplay (such as battlefields, arenas, and various "collecting dishes") or a player's strategy for playing (such as talent, skill plus points)?
What kind of feeling should it give the player? Relaxed or serious?
What makes it different? First of all, I believe that the designed gameplay should be unique, even if the same gameplay is placed in a game of different rhythms, it can also be unique.
What kind of rhythm change does it bring to the game as a whole, and how should its own rhythm be? In designs that usually lack design capabilities, designers will regard the modules they are designing as the most important and core modules of the game, and make every effort to design them like the core gameplay of the game. But in fact, each module has its own rhythm, and the attitude of trying to design it is right, but you can't design it in an extreme way. You still have to pay attention to the degree of this gameplay.
At this step, it’s best to have more exchanges with all the people involved, especially those involved in the design, and reach as much consensus as possible. A 100% consensus is impossible. Everyone has their own ideas and ideas. Experience, so everyone’s perspective on the same thing will always be different. But "understanding" definitely shouldn't be "isn't this xxxx?" like this.
Imagine application scenarios
After the design is completed or the gameplay design is roughly understood, it is necessary to imagine the user's application scenario. The most taboo thing here is to represent the user-"When I play, I will do this, then that" or "Players can do that if they play like this". This idea is very much for players and not suitable for designers. What a designer wants to think about is an ordinary user. After we give him these interfaces, how will he use them, such as are you hungry?
1. The user opens Are you hungry because they want to order takeaway.
2. Since the user wants to order food after they come in, what type of food is the most important thing, the main meal? Afternoon tea? fruit? Different individuals have different ideas in different situations, so the concept of "how will I" is not appropriate. So the designer should give users the entrance to choose these.
3. After the user selects the category, there are two possibilities: the user will give priority to the store (such as eating a store, or looking for a brand according to the corresponding food), or the user is very eager to eat something, such as special Want to have a cup of milk tea with stockings. So there should be categories and stores for users to choose from.
Just like this, an application scenario that guides the user to the menu "how to play" is generated. After that, it is time to enter the detailed selection content and return to the selection process. After the selection is completed, the order is placed, the progress is tracked, and the delivery is returned in a closed loop. .
Thinking about the user's application scenario, the most important thing is to think: when and why the user enters this interface, and what he wants to do. Each step in this has its own meaning.
The sequence of steps should usually be an irreversible relationship. If you still think which step is OK, it means that you have not yet cleared the tonality of this "play"-imagine a Fifa or live football type game:
If the step is to select the team first, then the jersey, and then set up. It means that the selection of the team is a prudent thing, you should consider it first, of course, this does not mean that the selection of the jersey is also so prudent, but the final step is also a prudent thing, so the selection of the jersey is independent. But if the selection of the team is synchronized with the selection of the jersey, or the selection of the jersey and the layout are synchronized, he gives the feeling that this step will be more random and even bring a wrong experience.
Think about what users should focus on when choosing a team? It should be the attribute of this team (such as offensive power, etc.). Whether the jersey color is liked by the user is not something strong enough to be equal to the attribute, but an adjustment after accepting the attribute.
So you need to choose two times. When you put these two steps together, you will give a wrong hint: team attributes + jersey color (style, etc.) are the basis for selecting a team. Of course, here you have to "convince yourself" with "Crut's second law of usability"-not to say that it is inconvenient to take a few more steps, because every step here is necessary-this process Clarified the tonality of the gameplay.
List the flow chart of the entire interaction process
After thinking about the application scenario, basically the entire process appears. You might as well write it down, because this is just an ideal process. After determining this ideal process, we must begin to subdivide each step of the operation process, that is, the "things" in each process. Of course, most of the "blocks" in the process should be one thing.
In a moba game, we will first select the mode, then the hero, and finally start the game. The process of selecting a hero can be further subdivided (if there is no ranking mode). Choose the specific hero, select the build (such as talent, rune, etc.), and then select the hero's skin. Here we have to see which ones should be One, which should be divided into steps, choose who and build to form a "hero selection strategy", so they are actually one (the same "thing"), and choosing a skin is to perform a selection on the selected hero The icing on the cake, so separate to the next step.
What does the interface solve by listing the information that needs to be displayed and the content of interaction with the user?
After determining the process, we have to start to determine how many UIs. Each UI should only solve one "thing" (that is, one UI per theme), and there should not be too many things to do to avoid one UI with too many themes. So we have to find out from the process, what exactly is there, and then make a UI for each thing.
For example, in the game's equipment system gameplay, players can equip (use) acquired equipment (props), can enhance equipment (props), and can sell equipment (props), but these are three things that are not related to each other, so you should There are 3 corresponding interfaces, and they are recognizable. After all, although these 3 things have similar operations, they have completely different operation results.
Should I set up selling and enhancement functions in the "Select Equipment" interface to facilitate user operations? First of all, it is definitely not necessary to sell: "I" is here to choose a piece of equipment to wear, at least "I" hopes that it and the corresponding equipment (props) are still "me". "You" (designer) gave me a button to make the equipment (props) not "me". This is a burden to my mind, so I must not sell it! Then let's see if reinforcement is needed?
This depends on the tonality of the enhancement gameplay. If enhancement itself is a strategic gameplay different from equipment, "I" want to enhance an equipment (props) need to allocate my resources reasonably (such as enhancement stones and other props, as well as gold coins, etc.) ) Is a process of careful selection, so it shouldn’t appear here, because the solution here is the “strategy of selecting equipment”, but if the enhancement is only to spend a little money to upgrade (provided that money is the most common currency, so the shape It’s not a strategy, it’s just a process of transforming accumulated currency)
Then it can appear here as an "auxiliary strategy" for "choosing equipment"-different enhanced gameplay tonality and different design directions are determined by whether enhancement and equipment can be regarded as "the same thing."
What information helps to solve this matter
You can simply list all the helpful information in the game for this "thing". The so-called helpful information can be simply analyzed as:
1. This information is related to the elements of this matter: the prop’s icon, name, type, and quality level represent the "what equipment" of an equipment (prop), so they may be useful for any prop-related interface Information.
2. This information can help "I" make decisions about this "thing": For the equipment selection interface, the attributes of each piece of equipment (props) (such as attack power, defense power, etc.) are all such information; but The price of equipment (props) is definitely not-because for the usual RPG games, the price does not affect whether I choose to wear it, unless this is also a special rule of the game.
3. "I" would like to know this information: some information may not be directly useful for solving "things", but this information will give "me" certain help in this application context, or give me some psychologically Hint etc. For example: the original price of discounted items in the mall, and "recommended by the manager" in Ele.
It should be noted that here we only need to think about the information that needs to be listed, not how to express it. In contrast, we should not think about some "beautifying" UI elements.
Get rid of unnecessary information
After sorting out the required information, we have to take out the "Occam's razor" to get rid of the information that is not important to this matter. Often the less important information in this information has the following characteristics:
1. Information that is irrelevant to the process of this "thing": There is a lot of information that seems to be important to this "thing", but in this part of the process, it is not necessary information. We envision an equipment (props) gameplay. Each piece of equipment (props) has passive skills (similar to MHW). Configuring passive skills and even generating Build is one of the core gameplay of this equipment.
Therefore, it is necessary to know what passive skills will be obtained after the equipment is equipped, and the effects of these passive skills due to the current equipment may be necessary information. However, in the matter of "selecting equipment", what is the effect of this passive skill and its current The degree of effectiveness is actually not important, because the user is more concerned about how many skills "I" is equipped with, how many levels (or percentages), the specific effects of this skill and the specific effectiveness of this level are further (Another interface) thing, so of course it can be killed in this UI.
2. Unnecessary "temptation" in the interface: After some elements corresponding to the information are added, it will arouse the user's curiosity and make users expect to perform "off-topic" operations, which in turn leads to some seemingly related to the entire process but incompatible with the whole process. Process and interface.
For example, if you list the icon of the hero skill in the list of hero selections, the user may have been familiar with the hero already, but when you list these skill icons (and only the icon), the user will want to see this icon ( Unfamiliar with this interface), or the information corresponding to the icon's skills (after familiarizing with the interface), this is wrongly "tempting" the user, causing him to have "off-topic" thoughts that he shouldn't have.
3. More (strategic) information: Many gameplays have strategies, so information is provided, but some information will indirectly generate more strategies, but these strategies are actually not related to the matter itself. If it does not comply, then it should not appear in this interface, but in another interface.
Imagine the skill interface in D3. What happens if the rune that appears below the skill name is not the currently selected rune, but lists all runes that are highlighted? This is also similar to "unnecessary temptation in the interface", because "I" should see the current skill plan of "I" in the skill interface. The strategy here is: "Which one should I replace" instead of "I want Replace which with which".
4. Information that brings mental burden: When "I" is browsing various fashion skins in the mall, and configuring them on my character, watching the role of the young lady chosen by "I" become more beautiful and intoxicated, "You" (the designer) listed me how much the current fashion costs in total.
Even "I" still have much money left to buy it. This is a typical "unnecessary mental burden". After all, "I" is admiring beauty and beautiful things. Finally, these beautiful things may move me to buy, please "you" (designer) in "me" When you really decide to buy, tell "me" what's worse, instead of telling "me" anytime, anywhere.
Layout interface
After determining the information required by an interface, we can almost determine the interaction of the interface (that is, the operations that the user can perform), after all, an interface solves a "thing".
Sort information according to importance
First of all, we should sort out all the information elements and interactions that have been filtered out and list their importance to the "thing". There must be a sequential relationship here-that is, no two pieces of information (or interactions) are equivalent. Otherwise, there are still some problems with information or interaction (even if it is a "yes" or "no" choice, there should be a more important one, that is, the designer expects the user to order it. The sorting basis can be:
1. Closer to this "thing" theme: For example, in the interface of selecting a team in a football game, the team is the first, because it is the most important basis and interaction for the player to choose. Everything revolves around "selecting the ball." Team" expands; the second is the strength of the team. In contrast, the team strength information itself is also a very important basis for "selecting a team". It is the fundamental factor for the player to make a decision, but it is not interactive. The first focus.
2. More needs to be the user's visual focus: For example, in a "replacement equipment" interface, there are every optional equipment (props), as well as the current character attributes. These two pieces of information are the key information for users to make decisions, and they have the same status in terms of "closer to this matter", but as a designer, I hope that users should see the attributes of each piece of equipment ( And the changes it brings), because the strategic point of this gameplay is to decide which equipment (props) to choose after comparison. The second is the result of the change after equipment, that is, the character attributes.
In addition, another important task of sorting is "blocking", that is, which information is divided into pieces (a "point" or "problem" to solve this "thing"). Of course, the fewer blocks, the design is explained. The better.
Arrange elements according to sorting
Selecting interface elements means selecting the elements (controls, components) used by the UI. This process not only tests the designer’s sense of beauty, but also has several key points:
1. No text (including numbers) that can use graphics: This is exactly Kruger’s third law. Since it is a game UI, those that can use graphic elements to narrate must not use text, even if text must be used. The matching graphics should be considered. The most common is the progress bar, radar chart with attribute values.
Plain text UI is not suitable for games, and of course it is inevitable for reading software. Of course, one of the most common examples is to use colors to express the quality of equipment, instead of stupidly writing words such as "excellent" and "excellent". Even if this one is not a game, it should be as close as possible.
2. No windows controls: Since it is a software on a mobile phone (it's just a game), then windows controls should not be used. No matter from the perspective of product tonality or convention, Combobox and RadioGroup are particularly not allowed. In the actual design, including some pop-up hint boxes, strictly speaking, they are all windows controls. Unless it is completely unavoidable, it should not be designed, especially if it is wrongly believed that it can be "more convenient".
Windows control does not bring more convenience or better performance, it can only bring more uncomfortable operation, unless your product is a "end-to-hand" or "counterfeit end-game" product, and some details must use these Controls can reflect the "authentic". For example, many UI designs of Honor of Kings are actually designed to show that this is the mobile version of LoL, so some windows designs are used.
3. Uniform style: The style of each interface should be integrated. It is recommended to refer to some design templates similar to Material Design. Of course, the effect of the reference template alone is not good, because many junior designers will simply put a control (group) that is incompatible with the overall sense on the interface for reasons such as "rapidly".
Design layout according to elements
After selecting the elements, we can start to select the areas where these elements should appear. The idea of this step is very simple and straightforward-the more important the block, the closer its center point is to the center of the entire screen. Of course The "close" here refers to the distance between two points (the center of the screen and the center of the component)/the diagonal length of the component. At the same time, the more important the block, the larger the area. Of course, this will also depend on the controls used, so this step is just a concept, not an absolute.
In addition, it is especially important to note here that things with similar functions should be put together as much as possible-close to the law.
Adjust the content according to the layout
After that is the layout of the entire interface, here will begin to fine-tune the size of some controls, and fine-tune their positions (note that they are all "fine-tuning"). The mobile UI is recommended to use a flat style, so that it can also make the interface look non-windows by the way. So there are several key points:
1. Make alignment lines to align elements, especially related elements. Alignment is a sense of beauty and a good embodiment of relevance.
2. If you want to use a list, then the list should run through the entire screen (horizontal or vertical), and the dragging direction of a good list conforms to the long side of the screen (for example, the horizontal screen is dragging horizontally); its element aspect ratio is opposite to that of the list (horizontal). Each element of the dragged list should be vertically long); the number of elements in a single row/column should not exceed 2, and 1 is recommended.
3. Don't worry about the button being too big, but worry that the button will make people misunderstand its function. A button that is too small will not only look like windows, but its associated objects will also be different-the law of proximity.
4. Pay attention to balance, and don't make the UI on one side appear heavy (too many elements, too dense) and make the entire screen seem to fall to one side.
5. The golden ratio is good, but don't be trapped. It can only be said that the elements, especially those elements that look like cards, should be as close as possible (rather than fully in line with) the golden ratio.
Check the rhythm according to the content
Our UI design is almost complete, but "one who travels a hundred miles is half to ninety." From here, we have to verify whether the UI design is good or not, first of all, we have to verify it ourselves:
1. Compare by "try it out": In fact, when we are designing, we will encounter some entanglements, such as whether a certain element is better to be expressed in another way? For example, will the effect of changing an icon be different? Don't dream about these questions, try them, compare them, and then choose.
2. Design every possible situation instead of fantasizing: Many elements in the UI are very good when using repeated and the same elements. For example, the props in the list are all with the same icon, the same name, It’s great with the same quality color, but will it still be the case if you change it to an actual color? It might even look very flowery? Also, it looks good when there are many elements in the list, but will it be out of balance if there is only one element? Rather than guessing these, it is better to directly deduct more points to see the "final effect" and then make a conclusion.
3. Remember to look at the rhythm of the interaction: UI design should also consider the animation performance of the UI, and also consider the UE operated by the user. This operation is still not "convenient" or not, but depends on the time taken by the entire process and whether it is consistent. If the rhythm of this interface is too slow or too fast, it will destroy a good UI design. But the design of rhythm itself has no rules to follow. This conclusion can only be reached by combining the designer's spirituality and the grasp of the overall tone of the game.
See "Feedback" from "Users"
After finishing a UI design, we should show it to others and treat them as users. For my team, I am their "user" and will show it to me first after they finish the design. As their "user", I will publish my feelings and my guidance, but most users are not professional, so learn to refine the real feedback from users by yourself.
Show it to your "user" instead of telling it to your "user"
What you need to do is to show your UI to your users, and then do not make any explanation, if it is a plan, it is best not to bring any explanatory text. Let your "users" understand for themselves. If there is something that you don't understand, it can only show that there is a problem with the design. This is also a core reason why many excellent teams adopt the one page design pattern—all the problems are clearly stated.
Listen, analyze, reflect, not explain
Show the UI to your users and see how they react. His expression, manners, and subconscious questions are the feedback to your UI (of course, some people look at the UI with a mentality of finding faults and learn to filter by themselves).
In this step, you should find out what causes the user to be confused, and what performance makes the user incomprehensible. Never answer the UI, especially when your "user" asks you, you also have to pretend that you are another unknowing crowd, and don't tell him what you thought of when designing, because his confusion will be affected. You mislead and disappear, but not all users have the opportunity to listen to you.
"Prescribe the right medicine"
To solve a design problem, you must prescribe the right medicine, not what is wrong. Even when necessary, it is necessary to completely delete the interface that has been designed, and to reorganize and redesign from 0.
For example, sometimes your users are surprised-"This button is not controlling this change?" Is this problem really just the position and size of the button?
Specific problems still require specific analysis before making solutions. The most important point: don't be afraid of hard work! Designing the UI consumes a lot of time and energy, because designing the UI means you are teaching your game how to communicate with players freely, and even telling them the story of the game!
