The author | Xiong Zichuan (ThoughtWorks retail business chief designer)
When design thinking is widely discussed, the so-called “engineer thinking” comes into being as a result of conventional thinking. Intuitively, “engineer thinking” seems to stand on the opposite side of “design thinking”, but in fact, engineer thinking is a non-existent concept, and design thinking has no direct connection with the role of designer.
So while your question is: how can designers train their engineer mind, the real question should be: how can they work with engineers?
Better cooperation with engineers is not to master the so-called engineer thinking, but to learn how to think like engineers, so how do engineers think about a problem?
An important thinking habit of engineers is to generate patterns from several aspects of information, from which codes are generated. Therefore, a good communication Pattern is for designers to provide as much information as possible to help engineers form “patterns”.
On the other hand, designers tend to talk about processes from the user’s point of view, whereas engineers tend to focus on “data interaction” rather than “human-machine interaction”, which is one of the differences between the way designers and engineers think.
This does not mean that it is not important to talk to engineers about the interaction process, but that we need to combine “data interaction” with “human-machine interaction” to communicate with engineers.
Data interaction
Designers are usually good at talking about “human-computer interaction”, so let’s look at how designers should talk about “data interaction”. We recommend designers to think about the following four aspects:
- Condition (Condition)
- Exception
- Logic
- Data
Suppose we want to express a log-in design to an engineer:
- A user name input box
- A limited number of password input box
- A button
The most traditional way of communication is to use the page flow diagram, which shows the usage scenario, information architecture, page flow and interaction completely from the perspective of users. However, if we consider the way of thinking of engineers, we can reflect the following information:
What are the trigger conditions for entering the design, such as the login entry, clicking on what can trigger the login interface; What are the prerequisites for entering the design, such as the user not logged in.
The exception here usually refers to the data input of an exception, as opposed to an error result, which is only a result of a judgment logic, and the former exception occurs before the execution of the logic.
Logic is used to handle: 1) abnormal data input; 2) Correct or wrong processing results; 3) Other background write logic.
In our example they correspond to: 1) passwords that exceed the digit limit; 2) Password verification logic; 3) Record the login time in the background.
Data records what data is required as input, what data is required as presentation, and what data is read and written throughout the design.
System complexity
System complexity is often not designers are difficult to understand the concept of engineering background, because most of the “user-centric” designers usually is designed with the user’s sensory experience, rather than the system, it is not against the way of “user-centered design”, but more a kind of thinking habit to understand the concerns of the engineer to implement. How do you feel about system complexity?
When you think about the conditions, exceptions, logic, and data mentioned above, the more requirements there are in each category, the more complexity will naturally increase, and this kind of thinking will allow you to simplify your design gradually.
A break through the existing mode of “new model” will improve the system complexity, for example, when we have a model called “click a certain content, pop-up login screen”, if you want a new model called “click on the content of more than 5 times, the login page”, here need to modify existing pattern before and the complexity of the whole is also improved.
In addition, the correlation of data also needs to be considered. When the data comes from different systems, or different systems are used to process the existing logic, the complexity of the system will be greatly increased.
So when engineers do estimates, listen to how they do them. Their language is not always based on the page, but rather give examples to evaluate system complexity, for example: “three data from a third party is required to, call three interface, have 10 backend logic to write, five front desk logic, two new page template, one needs to reconstruct are incorporated into the other modules, data, need to modify the core business logic test”. When you look at your design, you can count off the factors that affect the complexity of the system, and you can understand the language of the engineers when you talk to them.
Design thinking
The reason why I think the opposite of design thinking is definitely not engineer thinking is that design thinking itself is the thinking habit that engineers and designers should have together, without distinguishing between roles. Apart from “data interaction” and “human-computer interaction”, designers should help engineers understand the Context.
Context is what hides behind “data interaction” and “human-computer interaction”, and it usually includes many aspects, such as market changes, customer habits, application trends, behavioral data, and so on. For example, the context behind “click more than 5 times to bring up the login page” might be: the user stays on the “discovery page” for a long time, but once clicking on a content brings up a dialog box, the page leaves at a high rate.
Often, such information is beyond the grasp of even the designer, let alone the engineer, when what the designer should be doing is showing both the above and below water parts of the two-headed iceberg, which is a true expression of design thinking.
Real cultivation
In the end, the real discipline is to “experience what programmers do,” such as abstract patterns, inductive logic, assumptions, and standards. Some people say that the excessive pursuit of logic and pattern may make the design lack of “human” factor, in fact, most designers do not even “pursue”, do not need to worry about “excessive pursuit”.
The previous article “experience designers should learn a bit of front-end technology” has mentioned about the accumulation of skills in web engineering, in addition to mastering a certain front-end knowledge, to cultivate their system thinking ability is also essential, cultivating system thinking mainly points:
Understanding the internal relationships of a system helps us see through a seemingly closed system (which is often invisible to the user and unaddressed by user-centered design). Childhood like to read, rube goldberg machine, seemingly ordinary things finally completed a wonderful interaction between ordinary tasks, this is the fun of the system, furthermore studied several famous story “system” can also gradually cultivate your logic and system thinking, such as “prisoner’s dilemma”, “beer game”.
External links to help us understand the system at a higher Angle to understand the whole ecosystem, contact as well as the engineers pay more attention to the data link here, including economic, cultural, cultural, political, environmental, and many other links, this does not mean that design a login interface need to consider what impact to the environment, this is just a way of thinking, This way of thinking helps designers communicate and collaborate with engineers.
From designers to builders
The word Architect has two meanings in the Greek source arkhitekton arkhi- chief + Tekton Builder, also known as chief Builder, through cooperation with the project investor and the builder, They combine the aesthetic vision of an artist, the mechanics and materials knowledge of an engineer, and the business acumen to convince commercial investors to create buildings that are technically, economically, functionally and sculpturally sound. Here, they are not “designers” but “builders”.
In software, there is a distinction between “Developer” and “Architect”. Interestingly, in what we call design (digital product design), the concept of “Architect” is rare, and the role of “product manager” is at best (incomplete). I believe that in the near future, we are in the field, there will be characters like this, who have:
- Hci designers’ aesthetic appreciation of information, interface, interaction and visual performance;
- Engineer’s way of thinking about logic, process, data and system;
- An examination of business, environmental, cultural, human and political factors.
We often fall into a myth, afraid of some kind of way of thinking affects our existing way of thinking (e.g., one of the above responses), such as logical thinking too much will not affect my concern for people and intuition, and finally affect the design of I, when the design is more and more is not a separate skills evolve as a part of the “overall construction behavior”, The way we cling to thinking also needs to evolve.
That doesn’t mean we need to know there is no “engineer thinking”, use it and engineers to cooperate, but the way engineers view design it into our own habits of thinking, this will also help us complete transformation from designer to create, as the “build”, one will transcend engineers, product managers, and as a designer you now.
Xiong Zichuan
Design thinking and Agile/Lean UX promoter
ThoughtWorks China Design business founder
Design blog a thief (www.tuzei8.com) blogger
He currently works in San Francisco
ThoughtWorks Retail Lead Designer