Requirements design
mind Mapping
tool:
- Mindjet MindManager
UML modeling
Flow charts, sequence diagrams, use case diagrams, etc., are basic skills.
tool:
- Microsoft Visio （Win）
- OmniGraffle （Mac）
prototype
tool:
- Axure (required)
- Pencil
- Balsamiq Mockups
- Sketch
specification
The pros and cons of the design content need to be carefully looked at and thought about to know. But the problems in the specification can be found at the first glance.
Therefore, the output charts and documents must be standardized. This is the most basic requirement.
Take the flowchart as an example:
- There must be a beginning, an end, and only one beginning
- Arrows must be drawn at the tip of the flow line
- Only the judgment has two branch flow directions, and the rest are all one
Other details must also be paid attention to.
To collect and organize requirements, you can draw more mind maps, because there are correlations between some requirements, and the relationship and hierarchy of requirements must be straightened out.
What needs should be ignored
There is no large amount of data to prove that it actually meets the actual needs of users.
1. Ideas obtained by patting the head are often useless
Every coin has two sides, and it is necessary to examine the product manager's ideas with a critical eye.
At this stage, everyone is a product manager, and all kinds of wild ways are springing up, making good product managers rare.
When the product manager pats his head and comes up with an idea, what he should do is to ask him to do a detailed market research first, and give a report and feasibility analysis.
To give an example I've seen:
A long time ago, our team received a task to design a new gateway product. The product manager's idea is to target the audience user group at young people. In this way, it coincides with Xiaomi - "born for fever", and we are facing a relatively strong competitor.
At that time, I put forward a vision for aging. The theme was foolishness, real intelligence, and products that can be easily used by middle-aged and elderly people. It was not until 2016 that a slightly similar product such as the "Patriot Jurou" came out.
2. User feedback information should not be directly incorporated into requirements
According to the 28th principle, focus 80% of your energy on the 20% of the most valuable output.
The needs of users are needs, but not necessarily the needs of the public. So if it is a feedback group with only thirty or fifty active users, the feedback information obtained can only be used as a reference.
for example:
Suppose there is such a question: Does the smart door lock need to enter a password to unlock it through a mobile phone. In the user group, some users reported that it is very troublesome to enter the password to unlock the mobile app. It is better to remove the password verification in this step, which has received support from a group of people.
But such a requirement is not desirable. The actual demand still needs a lot of data to support. On the one hand, convenience and safety need to be considered. On the other hand, if a large number of users feel that this is troublesome, the best practice should be to keep the password unlocking function on the App, but you can set it to be on or off. It is enabled by default and controlled by the user. For convenience, it can be turned off. However, the security risks caused by such user-initiated behaviors must be borne by the users themselves.
3. The need to change user habits will not be considered
User behavior guidance should be a slow and gradual process. When doing technical architecture, you can be a little more radical, and try to use some new architecture and new technologies to improve system performance; but when doing product architecture, don’t be rash.
for example:
In the original user account system, mobile phone number registration and login are not supported. After adding this new function, it should guide the user to bind the mobile phone, allow the original method to log in, and add a new method to log in. Respect the original user's habit of using user names, and gradually cultivate the security behavior of binding mobile phone numbers, but users cannot be forced to change their login habits to log in with mobile phone numbers.
Because it is assumed that my user name wzlor willinwill be more convenient to enter than the mobile phone number (11 digits), so this kind of guidance does not help users get any benefits. Not advisable.
What needs should be paid attention to
1. Conclusions drawn from the analysis of data results in the operation and maintenance system
Improve the operation and maintenance system and collect more needed information. Reliable conclusions based on information analysis are the most important demand points.
I won’t give examples here. On the one hand, the data is relatively private. On the other hand, the problems displayed by the data are relatively obvious.
2. Pay attention to every word of insight
What kind of people output what kind of ideas. No bias, objective statement. A dog can't spit ivory, so don't expect good advice from superficial people. And those who can give good ideas can continuously output good ideas.
Design, mainly comes from thought and experience.
Thought, although there is room for making up for it later in life, it is basically innate and can be regarded as an innate advantage. Experience, on the other hand, requires a combination of knowledge and practice, which can be regarded as acquired wealth. Only when both are satisfied can one become a good designer. Harsh, but it's true.
product design
core idea principles
Security > Concurrency > User Experience (UE) > User Interface (UI)
The emphasis here is on concurrency performance, which is more important than user experience. The reason is simple, because the concurrency performance directly leads to the requirements for the server hardware environment, so it can be regarded as the cost of concurrency performance. No project or product can improve user experience regardless of cost.
Minimum Viable Product (MVP) Principle
Focus on a breaking point. Don't go big blindly.
It is not a day's cold to freeze three feet, and one bite cannot make you fat. All huge systems are gradually evolved from small subsystems.
Clarify the audience users, clarify the core functions, and iterate quickly.
User experience design experience
The focus of the experience is not the overall feeling, but the details
The logic of the display password button is reversed, and problems like this may not be noticed unless you look carefully.
The pop-up window includes the close button in the upper right corner, the cancel button in the middle, and the automatic close when you click on the blank space on the screen. There are 3 closures in total, and the "Cancel" button is completely unnecessary.
Consumption downgrade ≠ experience downgrade
- Avoid adding unnecessary operations in the interaction and simplify complex operations;
- In the interface display, avoid unrelated stacking, and the intuitive data reduces the user's thinking.
Taking the chart here as a counter example, the chart should reflect the progress of project implementation. Among them, the 70% highlighted in the middle may be the proportion of completed tasks, and each specific item displayed on the mobile is the number (the proportion is not displayed). Although it seems to be rich in content, it does not have any statistical significance. I don't know how many tasks have been completed, nor do I know what the proportion is when I have time to look again.
System architecture design
core idea principles
divide and conquer
Divide and conquer.
Distribute the huge computing and storage pressure to the lower levels. It can also be seen as a practical way of decentralization.
The data center only undertakes the storage of some core data; each server can store some non-common data and bear part of the calculation and load pressure. Subordinate routers, smart terminal devices, smart mobile devices, etc. can all share the pressure on the server.
High Cohesion, Low Coupling
Coupling and cohesion are two qualitative standards for module independence. When dividing a software system into modules, try to achieve high cohesion and low coupling, improve the independence of modules, and lay the foundation for designing high-quality software structures.
** Low coupling externally , high cohesion internally
An example is easy to understand:
A program has 50 functions, and this program executes very well; however, once you modify one of the functions, the other 49 functions need to be modified, which is the consequence of high coupling. Once you understand it, you will naturally consider "high cohesion, low coupling" when designing classes or modules when you write the outline design.
- The evaluation standard of coupling and cohesion is ** strength **, the weaker the coupling, the better, and the stronger the cohesion, the better;
- The so-called ** excessive ** refers to the design with the opposite effect due to misunderstanding;
- Coupling refers to the relationship between modules , and the weakest coupling design is to coordinate the operation of n modules through a main control module. Let me give you an example that I have given before: the customer requests to add a field on the interface, how many places do you need to modify in your project? If you only need to modify the project document, then your development framework is the lowest-strength coupling, and this kind of mature development team has already done it. They use development tools to drive the database and code at all levels through the project model, instead of directly modifying those codes;
- Cohesion refers to the functions inside the module . The strongest cohesion is that the function is so single that it cannot be split, that is, atomization;
- Therefore, strong cohesion and weak coupling complement each other, and a good design is assembled by several strong cohesion modules in a weakly coupled manner. **
Separation of front and rear ends
References:
- https://segmentfault.com/a/1190000002978095
- http://2014.jsconf.cn/slides/herman-taobaoweb/index.html
Points to note: Separation of front and back ends does not only refer to the front and back ends of the Web, but also includes the separation of clients (front) and servers (back).
Project Practice
The general idea of an open platform design.
Step 1: Locating Users
Developers, sub-enterprise developers and individual developers.
The second step: system function design
Have an outline in mind and make a list.
The core functional modules:
- Provide an open interface
- Provide open documentation
- Provide API documentation
- Provide SDK
- SDK downloads, from various groups, such as embedded, mobile development, server-side, provide SDK versions in various languages
- In addition to the SDK download, it is also necessary to provide the SDK usage instructions and integrate them into the document
Other functional modules:
- User Center
- Developer Certification
- product management
Then you can design the process of core business modules with modeling tools such as mind maps, flowcharts, sequence diagrams, and use case diagrams.
example
Mind map (brain map):
System structure diagram:
Use case diagram:
Timing diagram:
flow chart:
Step 3: Design the database table structure
Building databases and tables is very important. The main principles are to reduce redundant data, avoid too many table fields, and improve query performance.
It is best to use the numeric id as the primary key, avoid using self-incrementing ids (affecting data synchronization), do not use foreign keys for foreign key relationships, and set indexes for key fields.
First of all, the first table should be the user table. Although it is not a core business, all core businesses are associated with users and require registration and login.
So design the user table first. The user table should have at least two tables, one is the user basic information table, which only stores the user name, password, etc. or the most commonly used fields, such as login information; the other is the authentication information, of course, it can also be respectively for enterprise developer users, personal Developers and users create two tables, because different authentication methods require different fields. Associate other user information table data through the user id field.
Example:
The picture above is an example of an ER diagram. There are tools such as PowerDesigner and Visio under Windows, and MySQLWorkbench under Mac.
(You can refer to the user system design of the existing system, but there are some differences in details between the developer platform and the user product system.)
In addition, you can also consider adding some log tables in the early stage, such as authentication record tables, to store some historical authentication information. According to the project time budget, if it is not considered in the early stage, it also needs to be considered in the later stage.
Step 4: Build the system framework
First build a large framework, configure the cache database, add common classes, configure ports, and be able to run.
(You can refer to existing projects and the structure of project chapters)
Build a test framework (if the project schedule and budget allow). Details in the project implementation process will be explained in the next chapter.
Step 5: Iterate
Repeat the above process to improve the design of new functional modules and add them to the existing system.