一、背景

现状

在新公司工作快半年了，我对这里的工作模式已经有清晰的了解了。这里的设计师不多，但每个人要负责多个内部系统的 UI 和交互设计。

有些需求方的系统本身业务不复杂，都是简单的增删查改，但希望自己的系统能够与众不同，让人产生眼前一亮的感觉；而有些系统里的功能交互逻辑比较复杂，不同状态、不同情况比较多，希望设计师出一个交互方案能够让功能简单易用。

按这几个月的工作情况来看，第一种情况对我来说比较棘手。因为我当时面试的岗位是交互设计师，所以心理上和能力上都没有预期是要接触这样的需求的，而现实是这种需求的占比还不少。

所以我在遇到这种要为某个系统进行门户网站的设计，或者将内部系统打造得光鲜亮丽的需求的时候，我会耗费比较多时间，以及进行很多的尝试。

想法

于是我就在想：需求方们都希望自己的系统能在一众的高度规范化和模版化的系统中脱颖而出，那么使用 3D 素材会不会是一个比较好的解决方案？

有了这个想法之后，我调研了下网上其他大公司的对外产品，看看他们在 B 端产品中的 3D 素材使用情况。

看了一圈下来，我得出了这样的规律：

1. 3D 视觉素材在展示型页面用的较多。如官网首页，门户首页，登陆页等页面；
2. 在后台界面中使用较少。但也会用在功能入口、状态反馈、背景装饰等场景。

结论

基于这个规律、现实工作中的情况以及小范围的尝试之后，我得出了这样的结论：

1. 3D 素材在 B 端后台的场景使用的频率不高。恰当使用可以提升画面的丰富程度。但不必在此花太多时间。
2. 如果遇到需求方要求该项目需要与那种高度模版化的后台有明显区别的时候，使用 3D 素材确实是能满足需求方期待的。

二、难点

由于我没有 3D 设计的能力，同时公司的需求密集程度也似乎不允许我们专门花时间为一些日常需求来渲染 3D 视觉图，所以在最开始我是通过在素材网站上面搜寻 3D 素材，然后直接应用在工作当中。

这个方法最开始很好用，我可以快速地完成需求，但用久了之后发现短板也很明显。

1. 难以贴近公司业务。网络素材难以贴合公司内部的业务场景。大部份情况下只能找到通用素材，无法满足具体需求。
2. 缺乏系列素材。即使找到一个合适的素材，但要找到同系列的其他类型素材犹如大海捞针。
3. 侵权风险。网上找到的素材可能涉及版权问题，直接使用存在风险。
4. 质量参差不齐。高质量的素材通常需要付费，免费的素材质量参差不齐，难以满足设计内部标准。

所以我得出了一个结论：

仅靠找素材的方式对我们帮助有限，不能完全依靠这种方法。

如果不能仅依靠找素材的话，这意味着我需要有 3D 设计的能力？

当初我得出这个结论的时候，心里感到一丝的恐慌：现在的工作强度，还哪有时间学习复杂的 Cinema 4D 或者 Blender 之类的专业 3D 设计软件啊！

然后我再往深处想了想，其实我需要的不是 3D 设计的能力，而是需要有获得 3D 素材的能力！意思是我不一定得会用这种专业的 3D 软件，但我要有办法获得想要的 3D 视觉素材，并且这个过程必须具备以下特点才能满足我的实际工作情境：

1. 出图耗时短。因为实际工作中就是不值得在这方面投入过多时间。
2. 风格高度统一。才能保证扩展性，以及系统风格的统一性，而这正正是通过找素材的方式没法做到的。
3. 可定制程度高。指的是我要有办法定制 3D 素材里面的图像和元素，这样做才能确保产出物贴近实际业务，那用起来才有意义。

在想到这些东西的时候，刚好我了解到有一个叫做 Vector to 3D 的插件，似乎能够满足到以上三点需求，来提升我的工作效率和质量。于是我向领导提出这个设想，她也支持我去探索这个新工具。

这篇文章是公司内部分享会的文稿，记录着我当时探索出来的经验：如何利用 Vector to 3D 插件在 Figma 建立 3D 设计流程来提升我们的设计效率和质量。

三、通过 Vector to 3D 进行工作

插件介绍

这是一款付费插件，可以在 Figma 社区搜索并安装。

这款插件的 3D 能力分为两部分，全局配置项和当前物体配置项。接下来我将通过介绍这个插件的界面来简单介绍下这款插件。

对于全局配置项，我们可以在 “常规” 面板里配置视角和背景等参数、“渲染” 面板可以配置渲染质量、“光影” 面板可以配置灯光相关参数，如灯光数量 / 大小 / 位置 / 强度和颜色等。

对于单个物体配置项，我们可以通过 “厚度” 或 “旋转” 等的方式建立模型，并使用 “细分品质” 提升模型的质量。值得注意的是，这个软件是通过将矢量图形挤压或旋转生成出 3D 模型的，不能像传统 3D 软件那样有多种建模方式（比如克隆、布尔运算或雕刻等）。

除此之外，该插件还支持配置材质参数，如粗糙度、金属度、折射率等。这些简单材质足以应对绝大部分的 B 端场景了。

制作模版

这一小节会介绍两个该插件的功能，保存配置和模版化。

保存配置允许我们将当前画框内的视角参数、建模参数和材质参数等记录到该画框当中。下次打开编辑，或者分享给其他人打开的时候可以读取之前的配置，一键将矢量图形变成之前保存好参数的 3D 场景。

模版化则是该插件与 Figma 原生功能联动的完美范例，也是高效产出 3D 素材的关键因素。

先说效果：插件会将当前物体的配置项（如厚度、位置、材质等）记录，然后用户可以将任意元素与该物体替换，并继承该物体的配置项。

这个能力极大便利了模版化生产素材。我们只要做好一个模版，然后无限替换元素，就可以生产出适用于各种业务场景的素材了。

方法很也简单，我们需要将画框设为组件，想要替换的元素也要作为这个画框组件内的子组件。（下面的例子中，我将圆球的底座作为可替换元素）

将这个画框组件拖一个出来，在插件中设定好 3D 配置并保存。

然后做出其他可供替换的元素，确保图层的数量、排序、命名与画框内的替换元素一致

最后我们在左侧面板中按住 Cmd + Option 将其他替换元素与画框内的替换元素进行替换，然后在插件中重新加载一遍模型，我们能看到新的形状也应用上原有替换素材的参数。

这时，我们的模版已经制作成功了，后续只要无限制作替换素材，就可以获得无限的视觉素材。

实际应用

这里分享一个我在工作中实际应用的例子。我制作了一个生成蓝色 3D 玻璃风格图标的模版。

这个模版中，图标和背景面板的形状均可以替换，由此可以生产出很多种变化，适应不同的业务场景。所以也可以积累成为素材库，供团队的其他成员使用。

同时，我也建立了一个色板，可以用于表达一些状态（成功、失败、警告等），或者用在不同颜色主题风格的系统内。这样我们的模版能产生更多的变化，适用到更多的场景中。

四、总结

上文介绍了 Vector to 3D 的界面使用、如何制作模版以及分享了我在实际工作中应用的例子，我们现在已经掌握了在 Figma 中进行 3D 设计的流程。文章的最后总结一下做这件事的优点。

1.学习成本低

可以将 Vector to 3D 理解为是一个简化版的 3D 软件，移除了像传统 3D 软件比如 Cinema 4D、Blender 里面的很多复杂功能，仅保留基础能力。

2.Figma 内完成全流程

用这套工作流程可以使设计师不离开 Figma 工作环境就能生产出不错的 3D 素材，并且出图后也能在 Figma 内进行简单调色。不需要像传统 3D 工作流程那样在不同软件里的来回导出导入。

3.可定制程度高

Vector to 3D 的特点是基于矢量图形生成 3D 模型，所以我们能轻松生产出业务相关的元素，使得视觉素材能高度贴近业务场景。

4.风格高度统一

Vector to 3D 能够与 Figma 组件能力联动。可以将灯光、摄像机等全局参数记忆在组件中，替换子组件也能继承原本的材质、位置参数。同时能够将这些参数模版化，无限产出相同风格的视觉素材。

这套工作流除了在我自己的实际工作中有成功应用，也成功影响到了团队中的其他设计师。在这次分享会过后，团队中有50%成员已经用在需求中使用该插件来生成视觉素材了。

五、非 Figma 工作流

最后看到这里的朋友如果当前团队没有在用 Figma 作为工作软件，或者并非 UI/UX 设计师也想试试通过 SVG 图形制作 3D 模型的过程，这里我贴 Vector to 3D 的网页版连接：https://www.meimu.design/vector-to-3d/

A curious discovery

When my workflow had fully transformed from Sketch to Figma, I found there was an option “Case-Sensitive Forms” placed in several typeface setting panels. The appearance of the font might change slightly and occasionally when I enable this setting.

I was interested in this setting option, then I tried to find out concepts and related knowledge about the term “Case-Sensitive Forms.”

In this post, I will explain what Case-Sensitive Forms are, when should we implement this feature to uplift our design with several practices, and how to use it in our workflow.

Features

The “Case-Sensitive Forms” is a feature of OpenType features, which are like hidden compartments in fonts that allow us to change how fonts look and behave. When we use this feature, the font will:

1. Shift some punctuation marks up to a higher position;
2. Change oldstyle figures to modern figures.

Feature 1: Shifting some punctuation marks up to a higher position

In general, punctuation marks are vertically centered with lowercase characters, which is known as “x-height.”

However, when using the Case-Sensitive Forms feature, some punctuation marks are aligned with the height of uppercase characters, which we call “Cap height.”

Feature 2: Changing oldstyle figures to modern figures

Some fonts use oldstyle figures by default to add visual attraction. It is often used in traditional publications like books and newspapers since this font has a rhythmic beauty with varied heights.

When using the Case-Sensitive Forms feature, fonts will be directly changed to modern figures, also known as “lining figures.”

Realistic practices

Inspiring by the feature 1, shifting some punctuation marks up to a higher position, it is well-suited for compositions that mix uppercase characters, figures, and CJK characters.

Here is a list of compositions that might be visually improved by using the Case-Sensitive Forms feature.

1. International phone number

Because figure glyphs are as high as uppercase characters, the use of Case-Sensitive Forms is ideal for displaying phone numbers that include area codes.

2. Date and time

Similarly, date and time is also well-suited for using the Case-Sensitive Forms feature since they are typically consisted of figures and marks.

3. All caps text

To make titles or other important information visually prominent, we often capitalize the text, which is also ideal for using the Case-Sensitive Forms feature.

4. East Asian typography

East Asian typography looks like a square, meaning the visual height of Chinese, Japanese, Korean, and Vietnamese characters is similar to the “X” letter’s cap height.

Therefore, the Case-Sensitive Forms feature are also fitting for the East Asian typography scenario, ensuring marks are vertically aligned with the characters.

5. Sensitive information

When displaying sensitive information on digital interfaces, such as Social Security Number(SSNs), bank account numbers, and phone numbers, we often use asterisks (*) or dots (•) to partially obscure it. In that case, the Case-Sensitive Forms feature is highly suitable.

6. Text face

A rare scenario that may be ideal for using the Case-Sensitive Forms feature is text faces, such as “:D” and “:-)”

How to use

1. Supported typefaces

Only typefaces that support the OpenType feature of Case-Sensitive Forms can enable this feature.

It means that not ALL typefaces support this feature, even if we implement this setting in design tools or through coding. I’ve simply made a list to clarify which typefaces support it and which not.

Typefaces that support the Case-Sensitive Forms feature:

1. DIN Pro;
2. Inter;
3. San Francisco (fonts for Apple platforms);
4. Inria Sans;
5. Warnock Pro…

Typefaces that DO NOT support the Case-Sensitive Forms feature:

1. Arial;
2. Helvetica;
3. Noto Sans;
4. Roboto;
5. Source Sans;
6. Segoe UI…

In other words, the Case-Sensitive Forms feature only works on Apple devices if we use the system default font on our website.

2. Figma

Follow these steps to implement the Case-Sensitive Forms feature in Figma. Select a text layer, then:

1. Open the “Type settings” panel;
2. Switch to the “Details” tab;
3. Check the “Case-sensitive forms” option.

3. CSS

To use the Case-Sensitive Forms feature on the website, we just need to simply add font-feature-settings: ‘case’; to the element that we want to implement this feature.

The CSS Compatibility of this style is quite good. Again, we need to ensure the typefaces support the Case-Sensitive Forms feature; otherwise there will be no changes.

Set as default?

We’ve discussed many scenarios and advantages of using the Case-Sensitive Forms feature. So should we set it as the default style?

My answer is NO.

Although it can uplift visual details with numbers and capital text, it is quite awful when used with lowercase letters, which are more commonly used on our website.

However, we can safely implement the Case-Sensitive Forms feature in some components that always consist of numbers, marks, and capital letters. Here is the list of UI components:

1. Avatar;
2. Badge;
3. Pagination (Image viewer, Swiper and the likes);
4. Letter counter.

For comparison, let’s see the most common solution in which the Case-Sensitive Forms feature is not implemented on digital interfaces.

Recently, my team has been redesigning our mobile component library. I’ve suggested using the Case-Sensitive Forms feature on the components listed above. Let’s see the outcomes in the future.

References

1. Feature: case — Case sensitive Forms
2. 高级排版功能：Case-Sensitive Forms 是什么？

Uplifting your design details with the Case-Sensitive Forms feature was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently, I heard that Coursera has a UX design course developed by Google’s design team. This course covers the entire design process and teaches us how to present our portfolio, prepare interviews, and the like.

It is necessary to enroll in this course even though it is designed primarily for beginners and fresh graduates. It would enhance my English skills on one hand, and deepen my understanding of Western design practices and culture on the other. Since the term “UX design” is called out by Western designers and I am eager to compare Western design cultures with those I’ve experienced in China.

So I enrolled in this online course, trying to spare my time on it. Such as during lunch and dinner breaks on weekdays, or parts of the weekend. I completed the whole certificate within two months. And now I’d like to write down what I learned from this course:

1. Introducing concepts I had never heard of. Despite my 5+ yoe in a wide range of companies, from startups to large corporations in China, those new concepts opened up a lot of room for me to explore.
2. Enhancing my listening and reading skills. The course covers plenty of video and reading materials that include industry jargon that translators cannot provide. Moreover, certain phrases and sentence structures are repeatedly used throughout the course. I think my reading skills and speed are slightly improved.
3. Pointing out concepts like accessibility and equity early throughout the course. I used to think only seasoned designers or well-developed products consider these aspects, however, they are mentioned early on and repeatedly. These concepts resonated with me and will truly influence my work.
4. Elaborating comprehensive and detailed guidance for designers to prepare their portfolios, resumes, and interviews. They not only tell us what content should be included in our portfolios, but also how to prepare for interviews at different stages. I resonated with these instructions as well, since I did think those details over when looking for a new job.

Table of content

• New concepts
• Listening and Reading Proficiency
• Accessibility and Equity
• Guidance for Job Hunting

New concepts

I have consistently tried to think about and expand design boundaries through different aspects, which requires a breadth of knowledge. Here, I will share several new concepts along with my personal understanding.

Affinity diagram

This is a method of synthesizing that organizes data into groups with common themes or relationships. It can be used in different stages of the design process, such as during brainstorming or after collecting users feedback. The example below focuses on the latter.

After collecting a batch of user feedback, the design team condense each piece of feedback into a single sentence and write it on sticky notes. Then we post them up on a whiteboard or digital tools like Figma. Then the design team look for sticky notes that reference similar ideas, issues, or functionality and collaboratively organizes them into clusters representing different themes.

When I first learned about this approach in the course, I realized that this approach is similar to another method called “Card sorting” that was included in an article I translated earlier named [English to Chinese Translation] How we rebuilt Shopify’s developer docs. Both methods involve clustering sticky notes, naming these groups and summarizing the themes or relationships.

However, card sorting is implemented by external participants and aims to uncover users’ mental models to improve information architecture; Whereas affinity diagramming organizes a large amount of raw data to show the team which problems users are most concerned about and consider high priority.

* This concept is mentioned in Module 3 of Course 4 (Conduct UX Research and Test Early Concepts — Module 3 — Gather, organize, and reflect on data)

Digital literacy

This concept refers to an individual’s ability to gather, communicate, and create content using digital products and the internet. For example, senior adults or those living in areas with poor internet infrastructure may find it difficult to understand interfaces and functionalities, they are considered to have lower digital literacy.

In contrast, young people, especially those working in the information technology industries, are typically familiar with new software and concepts, and can quickly adapt to them.

This course does not dig deeply into this concept, rather, it emphasizes the importance of understanding our users. If our product targets a broad range of users, it is good to consider the needs of users with lower digital literacy. Moreover, this factor should also be considered when recruiting participants for usability tests.

* This concept is mentioned in Module 2 of Course 1 (Foundations of User Experience (UX) Design — Module 2 — Get to know the user)

Deceptive pattern

This concept refers to a group of UX methods that trick users into doing or buying something they wouldn’t otherwise have done or bought.

In the course, instructors clearly point out that this is an unethical and not a good practice. Businesses may lose their clients’ respect and trust once clients realize that they have fallen into deceptive patterns. I will share a few interesting examples that the course provided.

1. Confirmshaming: Making users feel ashamed of their decision. For example, a subscribe button on a news website usually reads “Subscribe now / No thanks”. BBut if the service provider wants to manipulate readers’ emotions, the text might be changed to: “Subscribe now / No, I don’t care about things around me.”
2. Urgency: Pushing users to make a decision within a limited time. For example, an e-commerce website might give you a coupon that is only available for 24 hours, prompting you to purchase items without a thoughtful consideration. The course doesn’t judge these marketing strategies or promotions; instead, it suggests that we should avoid putting pressure on users. As designers, we should try our best to balance business promotions and avoid manipulating users’ emotions.
3. Scarcity: Making users very aware of the limited number of items. For example, a popup or attractive advertisement stating “Only 5 items left in stock.” The course suggests that designers should concentrate on helping users to understand products better, rather than using designs to encourage impulsive buying.

It is really interesting that these deceptive patterns are so common in the Chinese e-commerce industry that it might seem unusual if those strategies were to disappear.

This seems to reflect cultural differences between China and the West. In China, core team members, such as designers, product managers, and operators, collaboratively discuss how to induce and prompt users to make a hasty decision. Also, we regularly hold reflections to discuss and share insights on how to deeply incite users’ motivation.

In 2018, I landed my first job as a UI designer at an e-commerce company. One of my main tasks is designing promotions, such as “claim your vouchers”, “flash sales ending in N hours”, and creating illustrations of red pockets and flying coins, and the like. I didn’t really like these approaches at that time, so I eventually turned to the B2B and SaaS industry, focusing more on UX design.

Although I am not fond of these types of designs, these seem to really help companies grow and generate income. We could stabilize our employment only if our company were earning profits. Perhaps that is an inextricable cycle: obviously, deceptive patterns are unethical and bad as they are inducing and annoying our users, but we must continuously implement these approaches and think about how to make them more effective.

* This concept is mentioned in Module 3 of Course 3 (Build Wireframes and Low-Fidelity Prototypes — Module 3 — Understand ethical and inclusive design)

Biases

The course thoroughly explains a concept called “implicit bias”. It refers to the collection of attitudes and stereotypes associated, influencing our understanding of and decisions for a specific group of people.

For example, imagine you’re designing an app to help parents buy childcare. To personalize your onboarding process, you start by displaying bold text saying, “Welcome, moms. We’re here to help you…”

This is an example of implicit bias, since it excludes every other type of caregiver, like grandparents, guardians, dads and others.

In addition, here are some interesting biases the course introduced:

1. Confirmation bias. Refers to the tendency to find evidence that supports people’s assumptions when gathering and analyzing information.
2. Friendliness bias. Refers to the tendency to give more desirable answers or positive comments in order to please interviewers. This usually occurs in usability tests, where participants may not share their honest feedback because they are afraid that real answers or negative comments might offend interviewers and be considered unfriendly.
3. False-consensus bias. Refers to the tendency that people tend to believe that their personal views or behaviors are more widely accepted than they actually are, and consider others’ opinions to be minor or marginal. For example, an optimist might think that most people around the world are optimistic; or designers can easily understand iconographies and illustrations they created, they might assume other users might easily to understand too.

I was shocked when I was learning this part. I strongly resonated with these biases which I had never perceived before. After all, the course lets us be aware of these biases and provides approaches to help us avoid falling into these pitfalls.

* This concept is mentioned in Module 3 of Course 3 (Build Wireframes and Low-Fidelity Prototypes — Module 3 — Understand ethical and inclusive design)

I listed some concepts above that I had barely encountered in my workspace. Becoming a UX designer appears to require a broad range of knowledge, such as design, the humanities, psychology, and sociology. I am now interested in psychology after completing this course.

Listening and Reading Proficiency

There are plenty of listening and reading materials involved in the course. Typically, each video lesson is accompanied by an article. If there are additional knowledge points, a single video might be accompanied by two or three articles.

Most instructors in the course speak with American accents. They also speak slowly and clearly, which makes me comfortable and usually allows me to understand without opening closed caption. Sometimes, I need to rewind a few seconds when they are speaking long sentences with many clauses or introducing new concepts, and I will open closed captions if I am still confused.

It is worth pointing out that the course contains lots of industry jargon, and I resonated with this because I used similar approaches or processes in my workspace by using Chinese. As a learner, I created a spreadsheet to record expressions that might be useful, such as:

1. Above the fold, the content on a web page that doesn’t require scrolling to experience;
2. Deliverable, final products like mockups or documents that can be handed over to clients or developers to bring designs to life.
3. Digital real estate, space within the digital interface where designers can arrange visual elements;
4. Firm parameters, refer to rigid design boundaries or limitations like time, project resources, and budget.

I think it is valuable to collect this industry jargon because it is authentically expressed, which can’t be translated by common translation tools. This will be helpful for me to read design articles and write blogs in English.

Accessibility and Equity

Accessibility

The course introduces several assistive technologies, such as color modification, voice control, switch devices, and screen readers, which can help people with different types of disabilities to use our products easily.

Instructors also point out that even people who don’t have disabilities, or who do not perceive themselves as having disabilities might benefit from these assistive technologies. The course suggests that we think these factors over throughout the entire design process. For instance:

1. Supporting color modification. Features that increase the contrast of colors on a screen, like high-contrast mode or dark mode;
2. Supporting voice control. Allows users to navigate and interact with the elements on their devices using only their voice. They also mention a concept called “Voice User Interface (VUI)”;
3. Supporting switch devices. This is a one-button device that functions as an alternative to conventional input methods such as the keyboard, mouse, and touch, allowing users to complete common tasks like browsing webpages and typing text;
4. Supporting screen readers. Allows users with vision impairment to perceive the content. The course suggests that we write alternative text to images, add appropriate aria labels to interactive elements like buttons, and consider the focus order of elements.

Here is a website that demonstrates the color modification feature: HubSpot.com

On the top navigation of this website, it provides a switch for us to toggle a high-contrast mode. Moreover, it also supports reduced motion effects — if I enable the reduced motion setting on my device, this website will minimize motion effects as much as possible.

Equity

The course also introduces a concept called “equity-focused design.”

Instructors clearly define the difference between “equality” and “equity”:

1. Equality: Providing the same amount of opportunity and support, everyone receives the same thing;
2. Equity: Providing different amount of opportunity and support according to individual circumstances, ensuring everyone can achieve the same outcomes.

The course also points out that equity-focused design means considering all races, genders, and abilities, especially focusing on groups that have been historically underrepresented or ignored when building products.

They use a survey question as an example: when gathering participants’ demographic information like gender, it is not enough to provide three options: “Male”, “Female” and “Other”. To make our design more inclusive and equitable, we should offer additional choices, including “Male”, “Female”, “Gender-nonconforming”, “nonbinary” and a blank field. The latter provides non-conventional gender options, uplifting those who might be marginalized in conventional surveys. This approach also aims to balance the opportunities for all groups to express themselves, ensuring their voices are treated fairly and heard.

In this lesson, I clearly faced a culture gap from the West. In fact, I don’t really like to dig into this concept deeply, mainly because I can’t determine whether this approach is right. Sometimes I think it is unnecessarily complicated, but at other times, I recognize that there are people with non-traditional genders around us who may truly be eager to be treated fairly.

When I was learning this lesson, I realized that there was an opportunity to incorporate accessibility features into the project I was recently working on. I will write a new post if this project lands successfully.

* This concept is mentioned in Module 2 of Course 1 (Foundations of User Experience (UX) Design — Module 2 — Get to know the user)

Guidance for Job Hunting

In the final course, instructors teach us how to lay out a portfolio and what content should be included. They also inform us the process of interviews and how to thoroughly prepare for interviews.

The guidance they mentioned is for the Western workplace, which may not seamlessly fit in the Chinese workplace. For example:

1. They point out that designers should have a personal website and case studies regularly. However, Chinese designers prefer to publish their case studies on public platforms like ZCOOL and UI.CN;
2. They also teach us how to build our digital presence and network through LinkedIn. However, these approaches are not common in the Chinese job market, where the most popular methods are directly submitting resumes and getting recommendations through acquaintances.
3. They inform us how to handle panel interviews. I have interviewed with a wide range of companies, from startups to corporations, and never encountered panel interviews, which means that the panel interview is not popular in this industry.

I was deeply impressed by how they elaborated on the preparation and important considerations during the interview process. For example:

1. Research the main business of the company you interview for beforehand, and clearly understand why you are a good fit for the company;
2. Prepare answers to common interview questions beforehand, such as a personal introduction, your strengths, and descriptions of your case studies;
3. We should learn how to answer difficult questions using the STAR method, and prepare well before starting an interview;
4. Adapt the focus and questions according to the interviewer’s role to show you are a professional;
5. During the interview process, you might be asked to complete a task. Therefore, we should practice the ability to think aloud and clearly define questions, since interviewers might pose vague questions on purpose.

I resonated with the approaches and tricks mentioned in the course that I had previously used, which gave me a strong feeling that I was on the right track.

Additionally, the course also provides detailed instructions on how to pursue freelance design work. For instance:

1. Clearly identify your target audience and understand why they should choose your service;
2. Know your competitors, identifying what they can’t provide but you can;
3. Promote your service and build word-of-mouth by attending online and in-person events, and getting recommended through acquaintances;
4. Calculate the business expenses, set fair prices for your services, and make financial projections — estimate what your finances will look like in the first month, the first 6 months, and the first year.

* This concept is mentioned in Module 3 of Course 7 (Design a User Experience for Social Good & Prepare for Jobs — Module 3)

To sum it up

Well, above are lessons I’ve learned from the Google UX Design Professional Certificate on Coursera over the past two months. I think that this is an interesting course, although not all content can be applied in my daily work, I’ve also learned the thinking processes and workplace cultures of designers in another part of the world.

I strongly recommend designers reading this post consider to enrolling in the Google UX Design Professional Certificate, by doing this, you might probably gain new insights. The course costs $49 monthly, which is not expensive. It is likely to complete the entire course over two or three months if you have a full-time job.

Things worked as I expected, and I will start my next project in the second half of the year.

Lessons I learned after completing the Google UX Design Professional Certificate was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

最近了解到 Coursera 这个平台里面有一个 Google 设计团队出品的的 UX 设计课程，课程里会介绍完整的 UX 设计过程，并且教我们怎么写作品集和准备面试之类的。

即便这是一门面向初学者或应届生的课程，我觉得也有必要参加这个课程看看。一方面能锻炼下自己刚闭关修炼出来的的英语能力，更重要的是还能了解下西方职场的设计流程和设计文化（毕竟 “UX 设计” 这个概念是西方人创造出来的），我一直想对比看看老外的设计文化和自己这几年在国内职场的感受有没有什么异同。

于是就报名参加了这个网课，都是抽时间来学习的。比如工作日吃午饭和吃晚饭那段时间，或者周末的部份时间等等。总共花了 2 个月完成了所有课程。写这篇文章的目的也是记录下结课之后的感受：

1. 里面提到的一些概念我没有听说过。即便我工作了 5 年，在小公司和大集团都呆过，里面有些概念仍然给了我很大的探索空间；
2. 英文听力、阅读能力锻炼。里面有大量的视频和阅读材料，用词应该就是比较地道的行业术语，这些是翻译软件不能提供的。而且里面的材料都会不断重复一些短语或句型。我觉得我的阅读能力和速度是有所提升的；
3. “无障碍” 和 “公平” 的概念被很早提及并贯穿全课程。我一直以为只有比较成熟的设计师或产品才会考虑到这些，但这些概念在课程中很早就被提及了，而且是反复提及。这触动了我，并真正地影响到了我的工作；
4. 提供了全面且周到的指引帮助设计师准备作品集/简历/面试。这方面内容他们写得很细，告诉我们作品集里应该包含哪些，针对不同面试阶段所做的准备等。里面写到的东西我很有共鸣，因为我在找工作的时候也会去思考这些细节。

新的概念

工作这几年，我一直会尝试从更多不同的维度来思考和扩展原有的设计边界，做到这点需要有比较宽广的知识面。这里分享下我在课程里了解到的一些新概念，以及我的理解。

Affinity diagram 亲和图

这是一种组织数据的方法。从不同的反馈和数据中整理出他们的相似之处和关系。亲和图可以用在不同的设计阶段，比如在头脑风暴中，或者收集到用户反馈后，这里以后者为例子。

具体做法是在收集好一批用户反馈后，将每一个原始反馈浓缩成一句话，写在便利贴上并将它们都贴在白板上（当然，也可以用在线工具如 Figma 完成）。然后团队成员一起看这些内容，将提到相似概念/问题/需求的便利贴放在一起，并给这一堆便利贴起个名字概括他们的共同点。

根据分组结果，我们可以总结出一些趋势、痛点，了解到我们需要解决的问题也为后续的洞察报告提供了依据。

最开始在课程里了解到这个方法的时候，我突然想起来这与我两年前翻译的文章：【译文】我们如何重建 Shopify 的开发者文档 里提到的 “卡片分类法” 很像，都是将相似的卡片堆成一组，给该组命名，然后得出结论。

但卡片分类法里面 “分类” 的动作是由团队外部的人参与的，并且用于揭示用户的心智模型并为解决网站信息架构问题提供指引；而亲和图则是通过组织大量原始数据，告诉团队有哪些问题是用户关心的，亟待解决的问题。

*该概念在第四门课程的第三个模块中提及 (Conduct UX Research and Test Early Concepts — Module 3 — Gather, organize, and reflect on data)

Digital literacy 数字素养

这个概念大意是指人们对于数字产品、网络来获取信息、交流和创造内容的能力。比如一些年长的人、生活在网络没那么普及的环境中的人，他们对于使用电子设备和互联网就会有些障碍，理解功能和界面也会感到困难。而年轻人，特别是互联网行业的从业者则对这些就比较熟悉，各种新软件、新概念都能很快上手。

课程中对这个概念并没有展开太多，主要是提醒我们作为设计师，要了解到我们的用户是谁。如果是一个面向较宽广的用户群体，最好考虑也到对电子设备和互联网没那么熟悉的人。包括在做可用性测试时，招募的参与者最好也考虑到这个因素。

*该概念在第一门课程的第二个模块中提及 (Foundations of User Experience (UX) Design — Module 2 — Get to know the user)

Deceptive pattern 欺诈性设计模式

指的是一种设计方法：通过设计去诱导用户去做一些本来不想做的事情，或购买本来不想买的东西。

在课程中，明确指出这是不道德的事情，不是好的做法。一旦用户认为自己陷入了欺诈性设计模式当中，公司将会失去用户的尊重和信任。课程中列举了一些例子，我可以拿几个有意思的的分享出来。

1. Confirmshaming (羞辱性确认): 让用户对自己作出的决定感到愧疚。比如一个新闻网站的订阅按钮，文案里原本可以写 “立即订阅 / 不了，谢谢”，但为了操纵用户的情绪，文案写上 “立即订阅 / 不了，我不关心身边的事情”。
2. Urgency (急迫性): 引诱用户在 “有限的时间内” 作出决定。比如电商网站里给你送了一张仅限当天使用的优惠券，促使你赶紧付钱消费。课程里指出并重点不是限时促销这件事情，而是在这过程中给用户增加了消费的压力。作为设计师，我们应该在曝光公司的促销活动的情况下，尽量避免操纵用户情绪。
3. Scarcity (稀缺性): 使用户感受到这件商品非常稀缺。比如一个弹窗推送或明显的广告写着 “商品仅剩 5 件”。课程中建议设计师聚焦于怎么帮助用户更好地了解该产品，而不是利用设计促使他们进行冲动型消费。

有意思的是这几种 “欺诈性设计模式” 在咱们国内电商环境中太常见了，以至于没有这些反而感觉不正常。

看起来这是国内外文化的差异的一种体现。在国内的环境中丝毫不会避讳这些东西，反而设计、产品、运营都会一起构思怎么做才能更好地 “诱导” 用户做某些事情。甚至还会在内部复盘、分享，看看过程中有哪些地方可以继续改进。

2018 年，我的第一份工作是在面向消费者的电商公司里做 UI 设计师，经常要在界面上做出 “领取优惠券”、“秒杀价剩余 N 小时” 和礼包、金币满天飞的插画等设计，正正是因为自己不喜欢做这种设计，之后才转向了更注重 UX设计的做 B 端、SaaS 行业。

虽然自己本身是一点都不喜欢这种设计方式，但这似乎能实打实地帮助到公司获取收入。公司有一份好的收入，大家的工作才能稳定。似乎陷入了一个无法走出的循环 —— 明知道这种设计方式是不对的，是有诱导性质且给用户带来烦扰的，但又不得不继续做，并想办法做得更好。

*该概念在第三门课程的第三个模块中提及 (Build Wireframes and Low-Fidelity Prototypes — Module 3 — Understand ethical and inclusive design)

Biases 偏见

课程里着重介绍了一个叫做 “隐性偏见 (implicit bias)” 的概念。“隐性偏见” 指的是我们潜意识里有一种态度或偏见，影响了我们对某一群体的理解或决定。

比如一个餐厅老板收到两份简历，求职者 A 是一个二十多岁的毕业生，没有餐饮行业经验；而求职者 B 则是一个 50 多岁的人，有 30 多年餐饮行业经验。但最终老板选择了求职者 A，因为他认为年轻人的体力更好，做事情会比 50 多岁的人要快。这就是一个 “隐性偏见” 的例子。

课程中还介绍了其他几种偏见，这里也分享一些我觉得有意思的：

1. Confirmation bias (确认偏见)。指的是人们在收集信息和分析信息的过程中，倾向于寻找支持自己想法的证据。甚至尝试以更贴近自己预想结果的方式来解释数据；
2. Friendliness bias (友善偏见)。指的是为了令其他人满意，受访者更倾向于做出访问者希望得到的答案或者做出积极评价。通常发生在可用性测试当中，受访者觉得说出真实答案或负面情绪的答案会被认为冒犯和不友善，不将自己的真正想法说出来；
3. False-consensus bias (错误共识偏见)。指的是人们倾向于认为自己的观点或行为比实际情况更广泛地被认同，并且觉得其他人的观点或意见是被少数人接受的。比如一个人很乐观主义，就会认为世界上大多数人都是乐观主义；设计师能够很轻松地理解自己设计出来的图标、图像含义，就会认为其他用户也能轻易理解。

学到这里的时候我似乎被当头一棒，我似乎对里面提到的不少偏见都有共鸣，并且自己从来没意识到有这么一回事。总的来说，课程希望我们认识这些偏见，然后提供方法教我们怎么避免这些偏见。

以上列举了几个我在课程里了解到在日常工作中不怎么接触到的概念。可以看出来做一名 UX 设计师似乎得有宽广的知识背景，比如设计、人文、心理、社会学等等。通过这门课程，我觉得我对心理学产生了一些兴趣。

* 该概念在第三门课程的第三个模块中提及 (Build Wireframes and Low-Fidelity Prototypes — Module 3 — Understand ethical and inclusive design)

听力、阅读能力

课程里面的听力和阅读材料实在是太多了，基本上是一节视频课程，搭配一篇的阅读，如果有其他可以衍生出来的知识点，甚至会多篇阅读。

里面绝大多数老师都是美式口音，语速有刻意地减慢，我听着很舒适，绝大部分情况下不用看字幕。只是到了一些包含大量从句的长句子或新概念时可能会需要倒退一下多听几遍，再听不懂就会开字幕来看。

值得一提的是，里面有大量的行业术语，有很多我在国内日常工作中的用到的设计方法/流程等，这里都有出现到。作为学习者，我自己有做一个表格，把值得记录下来的表达方式都记下来，比如：

1. Above the fold 指的是在首屏（不用滚动）就能看到的内容；
2. Deliverable 设计的交付物；
3. Digital real estate 大概是指视窗范围或可供设计师发挥的空间尺寸；
4. Firm parameters 指一些设计过程中的限制，如时间，项目资源和预算等…

我觉得积累这种行业词汇有一个宝贵之处是，它的表达很地道，用通用的翻译软件是做不到的。这对我阅读设计经验文章，或者自己用英文写设计博客很有帮助。

无障碍和公平

无障碍

课程中介绍了几种辅助技术 (Assistive Technology)，如颜色模式、语音控制、Switch 设备和屏幕阅读器等帮助身体有障碍的人们更好地使用我们的产品。课程强调即便是健全人，或者认为自己是健全人的群体，也有可能会用到这些辅助技术。课程建议我们在设计的全流程都考虑这些因素。具体的做法，比如：

1. 支持多种色彩模式。如亮色/暗色模式，支持增强对比度和减弱透明度等效果；
2. 提供语音控制支持。允许用户通过声音来导航和与界面上的元素交互。另外，里面提到有个概念叫做 “VUI”；
3. 支持一种叫做 “Switch” 的设备。这是一种代替键盘、鼠标或手指等常见输入方式的设备，通常只有一个按钮。用户就是通过一个按钮来实现浏览网页、输入文字等日常操作的；
4. 支持屏幕阅读器。确保人们可以在看不见屏幕的情况下也能获取到主要内容。课程建议我们给图片添加替代文字，或者给按钮等控件加上合适的标签，并且留意元素的聚焦顺序。

这里分享一个在这方面有所体现的网站：HubSpot.com

这个网站提供了强对比的色彩模式，在顶部导航栏里有开关可以切换。同时也支持减弱动画的效果，如果我的设备在系统设置里设置了减弱动画，这个网站的大部份动效都会被移除。

公平

课程中介绍了一个概念叫做 “以公平为中心的设计” (equity-focused design)，并厘清了 “平等” 和 “公平” 这两个概念：

• 平等是每个人都有相同的机会和支持，即每个人都拿到了同样的东西；
• 公平是根据每个人不同的情况而提供不同的机会和支持，最终大家都能有相同的结果。

课程中指明，面向 “公平” 的设计，需要考虑到所有种族、性别、能力，特别是一些曾经被忽视和排除的群体。

他们以一个问卷问题作为例子：在收集受试者的性别信息时，如果只提供三个选项：“男”、“女” 和 “其他” 是不够的。如果想要更包容和公平我们应该提供：“男”、“女”、“非常规性别”、“非二元性别” 和 “请填写”。后者通过提供非传统性别选项和自定义选项，关注到了那些可能在传统问卷调查中被边缘化的群体。试图平衡不同群体间的表达机会，确保他们的声音被平等对待和听见。

从这门课程里我正面感受到了来自西方文化差异。实际上我不是很想太深入学这里面的门道，主要是我没法判断他们这种做法到底是对还是错，我有时候会认为这是在闲着没事干，有时候又认为我们身边确实也会有这种非传统性别的人，他们或许真的需要被 “平等对待”。

学到这里时，刚好公司的工作中有机会可以让我在设计中加入对无障碍的考量，我便抓紧机会在公司实施了一番。如果我的计划落地成功，我也会在这里分享出来的。

*该概念在第一门课程的第二个模块中提及 (Foundations of User Experience (UX) Design — Module 2 — Get to know the user)

求职指引

最后一课老师教授了我们怎么做作品集、一份作品集里要包含哪些东西、面试的流程、怎么准备面试等。

课程里讲述的都是西方世界的职场规则，有些未必在国内职场适用，比如：

1. 比如他会提到设计师应该有一个自己的个人网站，里面需要及时更新自己的作品。但在国内大家似乎更喜欢将作品传上平台提高曝光度，比如站酷和 UI 中国；
2. 他会教我们怎么建立自己在互联网上的形象并通过 LinkedIn 去做 Networking。但似乎在国内的职场上没有这一步，身边的人多数都是直接在网站上投简历，或者有少量的人是熟人内推进去的；
3. 里面有教我们怎么应对小组面试。我这几年在国内面试了大大小小公司，没试过有小组面试的情况，说明小组面试在我们的行业内不是特别流行。

印象比较深的是在课程里他提到了对于面试的准备，以及面试过程中的注意事项。课程里说得真的挺细的，比如：

1. 面试前要了解好公司所做的业务，清楚自己为什么适合去那家公司；
2. 提前准备好一些常用的问题，比如个人介绍、个人优势以及介绍设计案例等；
3. 学会用 STAR 法则回答困难的问题，在面试前提前练习好；
4. 根据面试官身份来改变面试的侧重点和要提问的问题，需要体现出自身的专业性；
5. 面试时可能会有现场测试题。所以我们要练习好将自己的想法说出来的能力，也要有界定清楚问题的能力（因为有时候面试官特意给出很模糊的问题）

有时候刚看看到课程里提到的方法和技巧，正好是我有用过的，我会感到有共鸣，觉得自己的方向是对的。

另外，课程里还有教我们如果想走自由职业，要遵循怎么样的步骤。写得还比较详细，我这里列举几点：

1. 明确目标用户是哪些群体，他们为什么要选择自己的服务；
2. 了解自己的竞争对手，看看有没有东西是他们提供不了而自己是可以的；
3. 通过参加线上推广、线下活动、熟人推荐等方式推销自己的服务和建立口碑；
4. 计算开支，合理定价，并且制定财务计划 —— 构思第一个月、第六个月或第一年自己的财物状况是怎样的。

*该内容在第七门课程的第三个模块中提及 (Design a User Experience for Social Good & Prepare for Jobs — Module 3)

总结

以上就是我这两个月以来在 Coursera 平台里学习 Google UX 课程的一些收获。我觉得还是挺有意思的一门课程，即便不是所有内容都能在日常工作中应用，但至少知道在地球里的另一个世界，那边的设计师他们的思考习惯、职场文化是怎样的。

我很推荐看到这里的设计师们去这门课程 Google UX Design Professional Certificate 里瞧瞧，相信大部份人都是有收获的。收费不是很贵，是按月来收费。每个月 49 美刀，工作党每天抽点时间来看，一般 2～3 个月都能完成了。

事情按照预期发展，五一假期结束了这门课程，下半年又可以开始捣鼓另一件事情了。

最近听说部门里面的产品或本地化运营对 Web 前端相关的内容比较感兴趣，正好我有相关的实践经验，所以在公司做了一个 Web 前端相关的分享会。分享内容包含：

1. 使用 Devtools：介绍 Chrome 浏览器内的模拟、编辑和审查工具；
2. 网页和部署：介绍 HTML, CSS, JavaScript, React，以及网站的部署和托管；
3. 网页性能指标：介绍网页性能常用指标和测量工具；
4. 资源分享：分享浏览器插件、网站和课程推荐。

与以往不同的是，这次分享会中加入了互动环节。我做了一个代码 Playground，尝试帮助观众了解 React，以及 React Props 的概念，并留了两个小任务，给观众尝试去实践对 React 项目进行编码。

完整的分享内容内容请继续浏览本文。

使用 Devtools

这个章节主要介绍 Chrome Devtools 一些可能不为人知的功能，来帮助我们提高日常工作中的效率和解决一些问题。先介绍 Devtool 里面「模拟」相关的功能。

模拟设备和屏幕尺寸

在 Devtool 里打开设备工具栏，在这里除了能够自由调整网页宽高，还能够模拟各种主流设备的屏幕。

甚至还能读取到网页里面的断点样式，提供快捷切换各种断点的方式。

需要注意的是，这里模拟的设备是会带上 UA 的，所以如果想在电脑里调试一些做了移动端特化处理的网站（比如访问主域名时，判断到是手机设备，则会跳到移动端的专门网站），是需要用到这个功能的。

模拟伪类

Devtools 还可以帮助我们排查各种交互状态下的样式问题，最常用的是，比如说我们想仔细排查某个元素的悬停和按下状态的样式，则可以在选中元素之后，勾选对应的伪类选项。

模拟媒体

在渲染面板（需要手动开启，浏览器默认是没有打开这个面板的）能够模拟部分系统设置，比如亮暗模式、打印模式、高对比度和减少动态效果等。

与之对应地，可以扩展一个概念叫做 CSS 的媒体查询，CSS 还可以探测到很多用户设备的属性或者设置，比如设备指针精度、视窗比例、当前是否全屏模式、设备方向等…

能探测的内容很多，但实际能用起来的可能只有寥寥数个，最全面的信息可以取 MDN 上查看。

编辑网页文字样式

Devtools 还提供了一个新的字体编辑器，能够让我们实时更改网页中的字体家族、字体大小、字重等属性。

编辑网页内容

我们在 Devtools 控制台里面执行代码document.designMode = 'on' 后，就可以实时在本地修改网页文字内容了，就跟平常打字一样。很适合用在测试文案长度的场景。最后也会分享一个浏览器插件，能够对网页做更多的编辑。

审查 React 组件

最后介绍一个审查 React 组件的方法，有时候我们想看某个元素是不是用的组件库，或者这个组件包含了什么属性之类的，可以下载 React Developer Tools，然后点选网页中的任意元素，进行审查。

网页和部署

接下来我介绍一下网页构成和网站部署相关的内容。

通常来说，HTML, CSS, JavaScript 是构成网站的三个要素。其中：

• HTML 用来用于定义网页的结构和内容，可以用来创建网站的各个部分，比如标题、段落、图片、链接等。
• CSS 用来定义网页的样式和布局，这个可能会是咱们设计师比较熟悉的部分，我们能够利用 CSS 来定义 HTML 元素的各种样式，控制它们的布局和位置。
• JavaScript 用来实现各种功能逻辑和操作交互。比如响应点击事件、动态修改网页内容，根据条件执行动画效果或展示特定内容等。

CSS 预处理器

上述的三种语言，都有各自对应的语法规则。而 CSS 预处理器，则改进了原有的 CSS 语法，使我们能使用更复杂的逻辑语法，比如使用变量、代码嵌套和继承等。

简单来说，CSS 预处理器能让我们写样式代码的过程更顺畅，使代码有更良好的可读性和扩展性，帮助我们更好地维护代码。

举个简单的例子，比如原本的 CSS 语法中要求我们给每一个元素写样式时，必须以花括号开始和结尾，而且每一条样式规则直接都要以分号隔开，而 Stylus 则能够让我们跳出这个限制。直接用换行和缩进来代替。

CSS 框架

另一个值得一提的概念是 CSS 框架。CSS 框架则提供了一套预设样式，比如颜色板、字体梯度，布局和断点设定等；以及一些常用组件，如导航栏、对话框和页脚等。

简单来说，就是提供了一批开箱即用的样式，便于开发者快速启动项目，同时也会保留高度自定义的空间，用于支持各种各样的需求。通常 CSS 框架都会包含使用某个 CSS 预处理器，甚至内置了一些图标库，主打一个 “开箱即用”。

这里稍微介绍一下一个 CSS 框架：Tailwind CSS。是一个高度定制化的 CSS 框架，通过大量的预定义类名，使开发人员快速构建和设计网页界面。

与其他 CSS 框架相比，有一个显著的特点是 Tailwind CSS 本身不会包装一个组件出来，比如按钮、输入框的样式，没有预设好的。取而代之的是，Tailwind CSS 将各种原子级的 CSS 类名包装起来，比如：

• 设置左右两边的 Padding，用 px-[...] 类名来实现；
• 设置一个元素为块级元素， 用block 类名来实现…

如果想要在 TailwindCSS 中，使用打包好的组件，达到开箱即用的效果，可以通过各种官方/非官方的模版或组件生态来进行。比如：

• Tailwind UI：官方模版库（收费）；
• Headless UI：官方组件库；
• Daisy UI：第三方组件库。

React

接下来介绍另一个概念：React。这是一个用于构建 Web 和原生交互界面的库（是的，它能够用来做 App，不仅仅是网页）。而且引入了 JSX 语法，将 HTML 和 JS 结合起来，以一种更直观和易于理解的方式描述界面的结构和内容。

React 有一点和我们的设计稿很像，就是它的组件思维。在构建用户界面时，React 主张先把内容分解成一个个可以复用的组件（把具体的交互、功能逻辑写在组件里面）。然后在页面中将各个组件连接起来，使数据流经它们。

下图引用了官网中的一个例子，其中：

1. 完整的应用，可以理解为由多个组件拼接成的完成网页；
2. 搜索组件，用来获取用户输入；
3. 数据列表，会根据用户搜索来过滤和展示内容；
4. 每个列表的表头；
5. 表格内每条数据。

现在我们用一个具体例子来简单介绍下 React 的组件。

在上图中，展示了一个页面页面 App.jsx 包含了 Profile、Gallery 和 FAQ 组件，以及 Profile.jsx 组件的代码。右侧是输出页面，展示了三个组件拼接而成的页面效果示意图，其中 Profile 组件模块里展示的内容，是和 Profile.jsx 文件内代码一一对应的。

上述的组件只是将一个模块包装起来，使其能够被其他地方复用。但组件内容是固定的。接下来会为大家展示如何向组件传递 Props，实现上文提到的一句话 “使数据流经他们” 。

在上图中，我们先将一些 Props 传递给组件 Profile（比如这里传递了图片的地址、人物姓名和描述），然后在 Profile 组件内接收这些 Props，并在组件代码内使用这些数据。

现在，我们就做出了一个可以复用的组件了，可以根据不同的内容来展示相关的人物信息。

大家有没有觉得这种做法有点熟悉？是的，在 Figma 中，我们的组件里面也有类似的做法。Figma 组件同样同样传递字符串、布尔和组件等内容。

实际上 React 组件可以传递的参数不仅仅只是上面例子中的字符串和布尔值，还能传递数值、函数、对象、Node 类型甚至另一个组件等。

我做了一个简单的 Playground，提前封装好了一个 Profile 组件，会传递一些字符串、布尔值（是否展示网站标签）以及数值（圆角大小），帮助大家更好地理解。

🛝 Playground

我做了一个 🛝 Playground ，大家可以在里面看到这个组件的具体的情况，实际看一遍代码可能会帮助理解 React 的组建和 Props 概念。

同时我也写了两个小任务给到大家去尝试，大家可以在上面的编辑器中自由尝试。

发布网站

到了这里，相信大家对构建一个网站已经有了初步的认识，接下来我为大家介绍下如何将构建好的网站发布的互联网当中，能够真正地被世界各地的人们浏览。

方法一：部署到服务器

这是比较传统的方法，先将项目相关的文件放进服务器里面（比如阿里云 ECS，或轻量服务器等）。然后在服务器内安装 NGINX，索引到项目文件夹，定义好首页、端口、404 等场景，最后将域名解析到服务器 IP。之后我们的网站就能在互联网上被人们访问了。

方法二：托管到服务商

这种是相对省心的方法，将我们项目所在的 GitHub 仓库，链接到服务商的托管服务当中。等于是由服务商来帮我们部署、发布项目，不用自己来配置服务器的各种内容了。下图列举了几种常见的网站托管服务商，分别是：Vercel，Github Pages 和 Netlify。

以 Vercel 来举例，除了能够托管网站之外，对每一次发布进行管理，甚至能够是对不同代码分支进行独立发布，还能收集网站访问数据等。

网页性能

接下来为大家介绍网页性能相关的内容。通常一个网站性能好不好，我们能够在体验时主观地感受到，比如打开时很慢、滚动时卡顿，或者点击按钮后很久才响应等等。但如果要准确地判断到网页的性能到底如何，是需要依赖具体指标的。

下面介绍三个常用的指标，分别是：FCP（首次内容绘制）、LCP（最大内容绘制）以及 CLS（积累布局偏移）。

FCP（首次内容绘制）

FCP 是一个关键指标，用来测量页面从开始加载到第一个页面内容在屏幕上完成渲染的时间。越快的 FCP 时间能够让用户感知到网页有在正常运行，而不是停滞、无响应。

这里提到的 “内容” ，指的是文本、图像（包括背景图像）、<svg>元素或非白色的<canvas>元素。如下图所示，FCP 出现在第二帧。

LCP（最大内容绘制）

LCP 指的从页面开始加载到可视区域内可见的「最大图像」或「文本块」完成渲染的时间。

这里提到的「最大图像」或「文本块」，具体来说是包含<img>元素、内嵌在<svg>元素内的<image>元素、块级文本等。

而测量方式，则是在页面加载过程中，记录视窗内的元素的渲染大小，取尺寸最大的元素，回溯这个元素被完整渲染的时间。注意，如果元素的有一部分在视窗外，在视窗外的部分不会参与到尺寸比较当中。

如下图所示，LCP 发生在第二帧，因为这个时候渲染尺寸最大的文本块被渲染出来了。后续帧当中，可能渲染出了一些图片，但尺寸都比文本块小，所以文本块依然是这个视窗内的最大元素。

CLS（积累布局偏移）

CLS 是指可视区域内发生的最大布局偏移分数。简单来说就是测量页面在加载时，元素的位置出现意外的偏移情况，如果元素尺寸大，而且位置偏移比较远，那么 CLS 分数就会显著增高。

这个指标会跟实际的用户操作或者体验有直接相关，所以应该也会是咱们设计师需要重点关注的内容，因为有时候布局偏移，是会比较影响用户获取信息、或者进行操作，甚至引发一些不可挽回的损失。

然后我来介绍一下测量网页性能的工具吧。我自己用过这两个，发现其实没啥差别，大家看喜好使用即可：

• DebugBear
• PageSpeed Insights（谷歌官方出品）

两个工具都能模拟桌面设备或者移动设备，记录多项关键指标的数据，并给出改进建议。

观察页面性能情况，不仅仅是前端技术人员要做的事情，了解到设计师也是可以参与到其中的。

比如 Guillaume Granger，他会比较想控制页面中 JavaScript 的数量，所以它提到，他会将所有用了 JavaScript 相关信息记录在表格当中。之后每次在网页中使用 JavaScript 时，都会跟之前的记录进行比对，判断重要性，决定是否在这个位置上使用 JavaScript。

开发者 Thomas Kelly 则提出了当意识到页面性能出现瓶颈时，需要做的事情，比如：

• 制定一个目标，团队一起往这个目标前进；
• 高频收集页面性能数据；
• 尝试用不同方式来解决同一个问题；
• 与同伴分享对性能的一些新发现…

资源分享

最后来分享一下相关的资源吧，包含两个插件、三个学习网站以及一个 React 课程。

插件：VisBug

介绍一个谷歌官方出品的插件：VisBug，主要用来帮助用户在浏览网页时进行调试和设计，包括编辑和可视化页面的 CSS，尺寸和字体等元素。

插件：Motion DevTools

Motion DevTools 是一个检查网页动效的插件，可视化和分析用户交互设计中的滚动、动画效果，并支持实时编辑、预览或导出等功能。

网站推荐

接下来介绍三个在国内外拥有较高知名度和影响力的设计师和开发人员。他们的观点、经验分享往往能给我带来一些新的启发。尤其是他们对钻研新技术的热情，是非常强烈的。

课程推荐

最后强烈推荐一门 React 课程——The Joy of React，这个课程我在年初的文章也有提到过，是以互动式课程的形式，由浅入深地讲解 React。从基础的组件 props 和 JSX 知识，到 Hooks、API 设计等等，讲述非常清晰，强烈推荐。

分享会感想

分享完之后感觉效果可能还不错，大家都有各自的收获。而且分享会中也不时有人提出相关问题，我也一一进行解答了。

或者也有对我分享内容的一些补充，比如我在分享完 Devtools 环节的时候，有同事也分享了一个在 Application — Cookie 面板里快速切换网页语言的方法。

后面了解到大家对于 CSS 和 React 那块听的比较迷糊，因为原本没有实践过的话，会对这些没有什么概念。而且大家好像对 🛝Playground 没有什么兴趣，并没有人对里面的内容有什么提问和看法之类的，可能到这一步都比较迷糊？🤔

指标那块倒是有不少同事关心，问了几个问题，比如有哪些方法来去改进几个指标的数据，或者在设计过程中是否可以提前避免性能问题等等。

总体来说和之前的分享会相比，这次分享会的参与度比较不错。

公司在 5 月上旬的时候举办了一场 AIGC Hackathon 比赛，鼓励内部员工基于公司相关业务，利用 AI 技术进行创作，重塑生产力。

这么有意思的活动我当然也要掺一脚，在同事的怂恿和牵线之下，召集到了另一位设计师，以及一位研发大佬。所以加上我总共是 3 个人，2 个设计，1 个研发。但是严格来说应该是 1.5 个设计，1.5 个研发。因为我会参与到前端界面的实现，这也是我想参与这次活动的其中一个主要原因。

先放上我们开发的小工具的最终效果，其实是通过提前录入 SQL 语句规则，然后用自然语言询问 AI，让 AI 帮忙生成一个可用的 SQL 语句：

过程

想法

因为当前我们公司的业务是研发管理平台，所以我想到能通过 AI 帮助我们的主要是提高效率，减少出错，诸如此类的方向。

尤其是我在刚来到公司的时候有一段时间给我学习体验公司产品。中途就看到有个地方生成图表的话，可以选择各种筛选条件，也能用 SQL 来快速筛选，当时我就觉得如果用 SQL 来筛选会比手动一个个条件添加来的快，但我又不会写 SQL 语句，所以就想到一个主题：「输入自然语言，通过 AI 生成一段 SQL 语句」，产品名称就被定为「SQL-Helper」。

最开始我们讨论到有几种实现方式：

• 产品原生：在公司的产品中搭建一个开发环境，在里面进行对话交互功能的设计和开发。
• 外部网页：搭建一个网页，在网页里实现对话。
• 谷歌插件（Popup）：在浏览器右上角上添加一个 Popup 入口，点击后打开一个浏览器提供的容器，在上面进行对话交互。
• 谷歌插件（嵌入网页）：在公司的产品当中嵌入一个小卡片，在上面实现对话和配置等，会遮盖部分网页内容。

最终选择了谷歌插件（嵌入网页）的方式，因为这样算是能比较融入到产品当中去，不需要来回切换网页这么麻烦，毕竟是一个对话的产品。而且 Popup 有一个致命问题是，如果鼠标点击到了网页的任何地方，Popup 就会收起，这种体验不适合用在聊天式的产品当中。而直接基于公司产品的开发环境中进行开发，这种做法成本比较大而且难以协作，毕竟团队中只有一个正经的研发。

团队合作

得益于大佬的用爱发电，他花了一个休息日的时间把架子搭起来了，技术栈是：

• React
• Ant Design Manifest V3（支持 Chrome 96）
• Stylus 样式结构支持

最初搭建好的框架。是能够在网页中嵌入一个按钮，点击后打开一个弹窗：

这两个地方就是我们作品的主要载体。我们希望点击悬浮窗之后能打开一个聊天小窗口，能在里面填入 SQL 语句相关的 Key 和 Value，然后填入用户的 API Key，并实现与 AI 实时对话。

所以很快，在第一天的时候我们就有了一个大概的原型，中途通过每日下班前的简短碰面来一起决定增加/减少哪些内容。

然后也确定了我们三人小组的分工：

• 我：前期负责设计界面、实现静态界面。后期参与 Prompt 调试。
• 另一个设计师：负责界面设计、图标设计、PPT 制作/包装。
• 研发大佬：负责功能实现，比如表单提交，发送和接收消息，接口调试等。

然后我们就各司其职，我这边按照大佬给的流程，每天把自己做好的部分提交 Pull requests，并标记清楚完成了哪部分，哪部分的功能需要研发大佬来实现等等。

整体的时间表如下图（只有五个工作日，时间紧迫。）：

一些细节

初试 Ant Design 的感受

平常在设计稿中使用基于 Ant Design 组件的经验有很多，但是自己亲自在代码里使用该组件还是第一次。

一个强烈的感受是，Ant Design 组件库确实很丰富，很多常用的组件都有封装好，主题色更改的功能也很强大。但是想要基于 Ant Design 组件库来做一些客制化的改动，实在是太费劲了（也可能是因为我太菜...）。

比如当时我想实现一个 TextArea 根据容器高度来自动填满高度的话，我的样式代码是如此之多：

另一个坑是我们的聊天窗口是嵌入到网站当中的，而且原本我们公司的产品也是基于 Ant Design 组件库搭建的，所以会出现很多样式的冲突。

比如我在自己的界面中使用了 Button 组件，而被嵌入的网站中如果也用了 Button 组件，那么样式将会被原本网页覆盖掉。

如果在这种情况下想要自定义样式，需要在 CSS 中通过多种手段来提升样式的优先级。这里是我比较频繁用到的两个提高优先级的方法：

• 使用选择器提高 Class 的优先级
• 使用 !important

CSS 选择器的优先级相关内容可以参考张鑫旭大神的名著《CSS选择器世界》，写得特别详细。

所以后面回想起来，我在改造 Ant Design 组件库花的时间还是太多了。这个组件库可能在做复杂后台的时候好用，但在做这种小应用，发挥创意的地方，我觉得还限制还是太多了。我觉得我们最开始应该选择使用有更高扩展性的组件库，比如前段时间看到的 Radix UI。

从文档来看，Radix UI 会组件里面每个 DOM 都提前命名好相关的 ClassName，那么用户在想自定义样式的时候，就方便很多了。

对比起 Ant Design，引用一个组件进来后，会生成巨多个没有打标记的 DOM。每个 DOM 的样式巨难选择，想要改组件内某个元素的样式，没有熟练的 CSS 选择器功夫还真搞不定。

但还是得具体试一试才知道 Radix UI 是不是真的好用，或许也会暗藏某些坑。或许我应该拿自己的个人网站来试一试 🤔。

改造弹窗：拖拽和操作

由于这是一个嵌入在网页当中的对话窗口，本着提高一个易用性的初心，我觉得需要对弹窗组件进行魔改，支持以下两种特点：

• 支持拖拽：允许用户拖拽弹窗标题区域，改变弹窗的位置，以免挡住原本页面中的元素。
• 移除遮罩：不展示弹窗背后的黑色遮罩，并且弹窗出现的时候，不影响用户操作原本的网页。

仅仅是改造弹窗这块，足足花了我一天。严重影响了我调试 Prompt 的时间，所以感觉很有必要把它记录下来，即便我的做法绝非最佳实践。

拖拽

拖拽这块我是用了一个名为 DragM 的开源库来实现了，因为看到示例里面效果很不错，所以直接用上了。效果确实也很不错，强烈推荐。

过程有点丢人，就不详细描述了。大概是我参照示例代码做到了弹窗能够实现拖拽，但弹窗的关闭按钮却失效了，后面还是得靠研发大佬来修复。

允许操作背景

这个特点的实现简直是噩梦。Ant Design 文档是提供了一个 API 是能够允许我们隐藏掉黑色的遮罩。

但是这只是让我们看不见遮罩，打开弹窗时，原本页面的元素仍然是无法点击的。所以我试了一些方法，比如说将每一个疑似是遮罩的 DOM 设置为 display: none;，然而并不奏效。

最后生效的方法是用 CSS 选择器选中遮罩层，并将其调整为跟弹窗一样大。那么实际上遮罩还是存在的，但已经被修改为和弹窗一样大，并且叠在弹窗的后面，其实谁都感知不到这个透明遮罩的存在。

所以对于弹窗尺寸以外的部分，是没有被遮罩所覆盖的，自然能够正常响应鼠标操作。

这种做法无法适应弹窗高度会动态变化的情况，但我们这次设计的产品中，弹窗的宽高是固定的，所以即便做法比较不成熟，但确实是达到效果了。

结果

比赛最终有点遗憾，距离拿奖仅一步之遥。获得我们组目标奖项的是一个单人成组的高手。 很可惜的是我们就差一点点，因为最后颁奖的时候大佬也提到了我们的作品，说是如果能更好用一些，比如将生成的 SQL 语句自动填进输入框，或者自动应用然后直接生成图表，就有更大的机会获奖了🤦。

确实我们在演示的时候没有将这个这个产品最强大的功能发挥出来。因为本身产品也有些缺陷，限制了我们的演示范围。

最开始我们设想是演示的时候用自然语言多问几个问题，然后 AI 每次回复都很准确，凸显了自然语言生成 SQL 语句的便利性，而且还想演示输入了几个错别字，AI 仍然能够正确地识别我们的意图，回复正确的 SQL 语句。

但实际上我们最终的产品还是有一个明显的 BUG，在连续聊天时，消息队列不正常，AI有时候会回复我问的上上一个问题，而不是紧接着我的提问来进行回答。

这使得我们演示的时候只能问一个问题，简单带过，没有办法将自然语言带来的便捷性完全地展现出来，实属遗憾。

收获

虽然没能获奖，但参与这次公司内部的 AIGC Hackathon 比赛对我来说有三个特别重要的收获。

参赛经验

简单来说就是产品设计和功能开发的边界，需要根据演示需要来进行规划。

之前我在样式实现中花了太多时间（职业病🤦），比如输入框的聚焦效果，聊天气泡出现的动画，发送消息加载中的动画等等，而实际上在演示的时候，这些可能只展示了 1～2 秒，甚至更少。

因为这些内容大概率不会是评委所在意的东西，反而在过程中怎么调试 Prompt，调试过程中遇到什么挑战，怎么解决，怎么选择模型等等，显得团队很沉浸于与 AI 接口进行交互，通过这个项目积累了挺多经验，可能这些才是大佬们有兴趣了解的地方。

我应该早点完成产品界面还原，然后尽快投入到调试 Prompt 当中的。 如果之后再次参与类似的活动，我觉得我的所有工作都会围绕最后一天的演示来进行，其他东西能减就减。

首次参与代码 PR，并且与真正的研发同事合作

这次是我第一次将代码 PR 到其他成员的仓库当中，并且解决代码冲突，编写改动点，同步最新代码等等。这种团队协作的感觉，让作为设计师的我感觉很新鲜和奇妙。

而且各司其职，每个人都做出了超出自己以往经历的内容，然后每天短会同步下今天的进度、明天的工作内容。尤其是路演前一天晚上一起调试 Prompt，然后把最佳表现录屏，录屏中还出现了几次滑稽的意外...这种协作的经历让我感觉很充实，富有激情。

而且我每天都会遗留一两个事项给峰哥来解决，比如：

• 我做完了一个表单填写框和提交按钮，我就告诉峰哥让他来做表单提交的功能；
• 我做完了聊天气泡（由AI、用户、系统发出的消息）的三种样式，也是一样让峰哥来做相关的展示逻辑...

真正参与产品代码贡献对我来说是一直想去做的事情，因为我一直觉得如果能由做界面/交互设计的人，来亲手将其创作内容实现出来，是一件很酷的事情，也能够减少很多沟通成本。

参与到 AI 的浪潮之中

我最开始是在去年年底的时候，用 ChatGPT 来帮我解决我重构个人网站时的一些实现问题，中途因为好奇心驱使，也问了很多奇奇怪怪的问题。然后最近也在高频使用 ChatGPT，来作为我学习英语的助手。

而这次比赛不仅给了我一个机会去参与创造一个跟 AI 相关的产品（包括代码也有不少是 ChatGPT 参与的），还给了我推强大的动力去了解 AI 在商业中的场应用景。除了在比赛中看到其他参赛者的创意之外，现在还了解到比如 Atlassian 已经有相关的功能前瞻了。

从 Atlassian 在 5 月 4 日发布的股东信当中，也透露到该公司已经在用 AI 来来为客户提供服务了。

"Now that generative AI has reached consumer-grade maturity with LLMs, we can create magical new experiences for our customers."现在，随着大型语言模型（LLMs）带领生成型人工智能达到了消费级的成熟，我们可以为我们的客户创造魔术般的新体验。

除了 Atlassian，另一个互联网巨头：Shopify 也将 AI 能力应用到其产品当中。比如在商品详情页的编辑界面当中，我们可以输入几个关键字，让 AI 帮忙生成一段商品介绍的文本，还能够调整文本的风格。

Shopify 将同样也是利用 LLM 来实现的生成文本能力，这被官方称为「Shopify Magic」。除了在商品详情页生成商品描述，也能在邮件当中根据活动类型或产品关键字生成邮件标题，或者在主题编辑器中根据要求来生成标题等等。

微软就不必多说了，也已经在 Microsoft 的办公软件上集成了很多 AI 功能。

代码仓库

这里放上我们产品的代码仓库吧，记录这段热血时光：

SQL-Helper · Github

最后，通过这次 AIGC Hackathon 活动，我真正参与到了产品的代码贡献，同时也看到了许多 AI 能力的应用场景。听说公司有产品在研究 AI 能力在业务中的应用，希望之后自己也有机会在商业项目上进行更多相关的实践吧！

近况

太久没发博客了，记录下我最近的状态吧。应该没有人想知道，但若干年后的我可能会想知道。

1. 近沉迷于学习英文，所以会导致网站、博客的更新会比之前慢一些。
2. 发现英文还挺有意思的，但在学生时代是看见英文就想睡觉。以前的我应该是比较喜欢数学和历史。
3. 小目标是今年内能出一篇全英文的博客。全程用英文书写，然后在发布之前先给 ChatGPT 帮忙检查和润色一下。
4. 个人网站 LRD.IM 正在开发支持切换语言至「英语」的功能。
5. 有一个前端相关的分享会正在准备进行，是面向部门内产品、本地化运营和设计同事的。
6. 在手机上开通了 ChatGPT Plus。直观感受是 GPT-4 的回答比 GPT-3.5 靠谱很多很多，应该会持续订阅。
7. 正在尝试一种新的作息，再多体会一段时间后，可能也会在博客上记录。

导读：Atlassian UX 团队的设计师 Hannah McKenzie 分享了一个优化图标的小案例。主要目的是使图标对色盲人士也具有良好的可访问性。

小细节会产生巨大的影响

你知道世界上有很多种不同类型的色盲吗？在澳洲，有大约 50 万人生活在某种程度的色盲当中。在美国，这个数字接近 1200 万。而在全世界，估计有 3 亿人生活在某种程度的色盲当中，网上的一些资料显示，这个数字甚至接近 3.5 亿。

其中红绿色盲占据了大多数，他们难以区分红色和绿色。

现在 Jira 的 Pull request 的图标是通过用灰色、绿色和红色来区分 Open, Merged, Declined 这三种状态。

红绿色盲人士看到的图标就像这样：

在 Jira 的软件项目管理看板当中，这些图标很小，并且与每个缺陷中其他小元素一起出现。比如故事点、负责人头像和缺陷 ID。

这是一个 Jira iOS app 项目看板的例子。其中 Pull request 图标用红色圆圈高亮起来作为示意。

虽然图标很小，但这些图标确实在传达有用的信息。

在 2021 年末，我开始进行优化开发状态图标的工作，并让色盲用户可以访问它们。它开始于一则我在无障碍团队 Slack 频道里的消息：

“我们最近有改进 Jira pull request 图标计划吗？现在这些图标是完全相同的，只能通过颜色来区分。”

在 2022 年初，几位设计师和研发在 Slack 的讨论中尝试了一个粗略的方案：

设计师开始尝试多种概念，产生了更多的方案：

在几个发散性的讨论和设计环节之后，全新的，具有可访问性的 Pull request 图标诞生了！

虽然这些图标仍然由灰色、绿色和红色来分别代表 Open, Merged 和 Declined，但同时，使用了打勾代表 Merged，打叉代表 Declined。而且 Merged 的图标用线条连接在一起（表示合并到分支），Declined 的图标线条则没有与任何东西连接。

这段经历教会了我…

• 即使过程很棘手，但也请坚持下去。如果你面向的是比较复杂的产品，或者在大型的机构中，你需要主动去在不同团队去联系到合适的同事；
• 一些看起来很小的设计往往会涉及到很多不同的人。通常是很多件小事（就像在这个案例当中，有许多交流和发散性会议）汇聚成一件大事，以最终呈现在用户面前；
• 设计一个支持无障碍的产品对很多人来说是至关重要的，小细节真的很重要。每个人都会受益，包括自认为是并非残障群体的的人士。比如电话和电动牙刷，最开始就是为残障人士而设计的。

Atlassian 里几位没有色盲的设计师和工程师对于新设计图标的看法：

“我不是色盲的，但这些图标让我一眼就能看懂。”

“这简直是宝藏。原本同样的图标，不同的颜色让我感到疑惑。我经常想，这是对应着什么分支状态？这是一个非常惊人的优化。”

所以这篇文章用来提醒大家关注细节 — — 即便是小细节也会产生巨大的影响。

• 原文：Accessible design: A story of three Jira icons | Hannah McKenzie
• 译者：李瑞东

背景

今年二月底入职了新公司，主要产品是企业级研发管理 SaaS 软件。这家公司的新员工在参与产品迭代之前需要进行相关的学习和培训：

• 第一、二周先自己学习使用公司的软件和行业名词，并模拟成销售的角色来参与一次产品演示和场景化配置的考核；
• 第三周基于自己感兴趣的主题来分析竞品和自身产品的某项特点，并作一次分享会；
• 第四周才正式开始参与产品设计，进入到迭代当中。

我是比较认同现在这一家公司的入职流程的。毕竟 SaaS 软件是会有点学习成本，自己先把各种功能、场景、配置和行业相关名词学会了之后才能更顺畅地合作。

就在我刚开始学习使用公司软件的时候，会感到有些吃力。比如：

1. 功能/流程配置。比如我想要做某项配置，但因找不到入口导致无法配置，或被某些逻辑限制导致结果与预期不符时，需要去到帮助文档里搜索相关概念，然后再对照文档里面写的步骤来实现；
2. 名词释义。有些行业内的名词我之前没接触过，或者不能够直接根据字面意思理解的时候，我需要去文档或者维基百科上查找相关的释义、使用场景和最佳实践。比如「故事点」、「用户故事」、「史诗」等；
3. 系统概念理解。我需要通过查阅文档、询问导师和自己反复尝试来去了解软件系统内的一些运行机制，比如说多种层级的权限，或者一个叫「池子」的概念…

所以在第三周的分享中我选择了主题是关于产品设计中如何帮助新用户上手使用软件。正好自己也看看其他做的好的产品是怎么做的，之前这方面的实践比较少。

概念学习

在实际进入竞品里体验之前，我先去网上学习点跟帮助系统相关的概念。我通过 NNGroup 的文章了解到帮助会分为两大类：

预防性帮助 (Proactive Help) 指的是系统在用户遇到问题之前提供帮助。常见的方式包括： Onboarding、新功能提示、上下文帮助(Contextual Help) 和向导等。

针对性帮助 (Reactive Help) 指的通过文档、视频、课程等资源来回答和解决用户的具体问题。或者为想要成为专家用户的人提供详细的文档和资源。

而「预防性帮助」，又能分为两种类型：

主动呈现 (Push Revelation)： 不考虑用户的任务而提供帮助内容。强调主动提供帮助信息而不考虑用户当前行为。这种方式会可能打断用户进行中的任务并引起用户的不适，需谨慎使用。

被动揭示 (Pull Revelation)：与用户当前行为相关的帮助。侧重于与用户当前正在进行的动作、行为和活动等有紧密关联。提供有助于用户完成当前任务的相关建议和信息。

经过梳理后，这些概念的关系图像大概是这样：

从 NNGroup 了解预防性帮助和针对性帮助的概念

。

接下来就从上述的多个手段中选取几个，结合 Jira、Asana 和 Notion 的做法来做一些观察和分析，并尝试总结出在它们身上能学到什么。

新用户旅程

新用户旅程 (Onboarding) 设计有助于引导用户使用产品，让用户发现产品的核心价值，进而推动用户留存、转化和推荐。

我分别体验了 Jira, Asana, Notion 的 Onboarding，发现这三者的流程大致相似，但基于软件本身的功能不同而有些许差异。值得一提的是，他们都做得很细致。

流程

走查了三款软件的 Onboarding 流程，并以粗颗粒度来划分步骤。

其中与比较关键的是第二步：

第二步：收集信息。收集用户的角色、工作职能、主要任务、团队规模等信息。用于获取用户的标签，以便后续进行精细化运营。同时影响到后续的配置、预设的数据和界面内提供帮助的程度。

第二步里收集到的信息会影响到创建入门项目、邀请成员和进入系统后的主界面。比如在 Notion 中如果提供了「个人使用」作为用途，则流程中不会出现「邀请成员」的模块。

千人千面

值得一提的是，Onboarding 流程中收集的用户信息，可以为后续的系统预设和默认配置提供参考。

比如在 Jira 中，系统会根据用户填写的团队类型和主要工作类型等因素，推荐对应的模板。如果用于管理软件开发团队，则推荐用敏捷项目模板；如果是管理业务团队，则推荐用项目管理模板。并引导用户使用模板创建第一个入门项目。

并且根据用户对 Jira 和敏捷方法论熟练度，决定是否在用户首次进入主界面时提供向导。如果是新手，在进入主界面时会询问是否需要跟随向导了解界面和功能；如果是有经验者，则没有向导提示。

再比如在 Asana 新用户旅程中，如果用户选择角色是「高管」，系统内新手引导卡片内的称谓和步骤，都会与「团队成员」的角色不同。

高管的引导卡片添加了「开始成为一名管理人员」的文案，而初始配置的步骤包含「创建报告」和「创建一对一会谈项目」等；而团队成员的引导卡片则是「填写个人资料」、「下载 App」和「查看第三方集成」。

或者当用户的角色是「经理」，仪表盘卡片也会与「自由职业者」不同。经理的默认仪表盘中有一个卡片是「我指派的任务」，而自由职业者则没有。

Notion 也会根据用户选择的工作类型，在邮件中更改相应的称谓。

我们能学到什么

💡 定制个性化的用户旅程。不同的用户有不同的需求和期望，为了更好地满足用户，我们可以根据收集到的信息来提供更符合其所处情境的预设、引导流程和配置等。

💡 合理利用向导来帮助用户上手软件。向导能帮助用户熟悉界面 UI 和功能，但要避免阻碍用户使用软件。所以需要根据用户对软件熟悉程度来决定是否提供向导，并保留跳过的方式。

上下文帮助

本文的最开始提到预防性帮助有两种方式，第一种是主动呈现 (Push Revelations)，比如一进入页面就出现的新功能提示，或者界面操作向导等。

而这里重点介绍的是另一种：被动揭示 (Pull Revelations)。而「被动揭示」有一种做法叫做上下文帮助 (Contextual Help)。这是指根据用户参与的特定活动，展示与此相关的帮助信息。强调要与用户当下的活动密切相关，而不是统一的推送。而具体的做法有很多种，比如：工具提示、向导、输入框提示、内嵌帮助中心等。

使用案例

Jira 的筛选器界面，在用户没有创建过筛选器时，会出现内嵌的帮助中心，呈现与筛选器相关的帮助；而当用户当前已存在筛选器，打算继续创建时，则会默认隐藏内嵌的帮助中心，用户可以手动点击右上角的问号图标打开。

相似地，Asana 的 Task 列表中，用户对任务进行多选后，也会在操作栏出现与之相关的工具提示。

同时也可以看看其他 SaaS 软件的做法，不必局限于竞品。因为这种设计理念是通用的，都是为了帮助用户更好地上手，为用户持续提供价值。比如 Slack 也在这方面下了很多功夫。

我们能学到什么

💡 帮助内容保持简洁。使帮助的内容简短并有效，并且在用户要求之前不要呈现过多细节或复杂的内容。

💡 易用且不干扰。上下文帮助可能会干扰已经熟悉界面或者不需要帮助的用户使用。所以在呈现帮助内容时，确保使用轻量的样式，并且允许用户跳过帮助。

💡 使帮助内容可以在其他地方访问。用户可能看到过一些帮助提示，但当时他们忽略了或者忘记了，这在复杂的软件里很常见。所以仍然需要提供其他方式来使用户获取到帮助内容。

模板

模板中心

用户使用 SaaS 软件通常是带着现实情境过来的，比如希望进来做任务追踪，或者是进行多项目的管理和进度追踪等。

所以我观察到这几款应用的模板生态还是比较丰富的，覆盖了多种场景。完善的模板能够帮助用户快速上手，减少学习和操作成本。

Jira 的模板中心以业务为基础，更多地关注具体的业务流程、管理流程和功能的实现。适用于企业内部、管理领域软件行业。并且有详细的模板使用说明和相关模板。

Asana 的模板按照团队内不同职能部门来划分，侧重于流程优化。并且有详细的模板使用说明。

Notion 的模板中心按照专业领域和个人兴趣分类。适用于个人、自由职业者和信息分享平台等。并且允许用户上传自己做的模板并进行收费，既能够满足用户的个性化需求，又能够为 Notion 和整个社区提供更多的价值和机遇。

本地化

值得一提的是，Notion 和 Asana 的模板中心做了比较细致的本地化处理，切换语言后会呈现更符合用户所在地区的分类和模板。

其中 Asana 的模板顺序，「每日站会」在日语和英语中，分别是首位和末位。为此我也有去了解过美国和日本的文化差异，试图去解释为何 Asana 要这么做，这是调研出来的差异：

1. 文化倾向。日本强调集体主义，注重团队合作和群体利益；美国强调个人自由，注重个人的成就和个人的价值。
2. 协作模式。日本注重面对面的交流和沟通。在组织中强调员工之间的默契和团队合作精神；而美国更加弹性化，注重个人的私人时间和团队协作效率的平衡，支持远程协作。
3. 企业文化。日本注重团队合作、持久性和精益求精，对个人规范和职业素养的要求高；美国注重灵活性和创新，注重持续快速发展和快速创造价值。

这些未必是 Asana 做这种本地化差异的理由。但是能反映出来，日本和美国这两个国家在霍夫斯泰德文化维度来看，是有明显差异的。如果之后工作中我有相关的设计机会，也会多多尝试基于两个国家文化差异，而作出不同的设计策略。

我们能学到什么

💡 模板丰富实用。模板对于 SaaS 软件的用户来说是非常重要的，它可以帮助用户快速上手并减少学习成本，并且加深客户对产品定位的印象。

💡 帮助新用户上手。不同 SaaS 软件的模板中心存在一定的差异，它们通常会按照业务场景、职能部门、专业领域和个人兴趣等各种标准进行分类。

💡 关注本地化策略。设计模板时需要考虑到不同地区、不同文化和不同工作习惯的用户的需求和习惯，并且根据实际需要进行调整和优化，以便更好地适应当地市场，吸引更多潜在客户。

帮助中心

产品文档

产品功能文档或开发者文档，是 SaaS 软件帮助中心的标配。我也有去看不同产品的功能文档，看看他们为了帮助用户更好地理解和使用，做了哪方面的努力。

比如 Asana 会标记截图中的行动点，然后在旁边写上相关的步骤操作。标记行动点是用户更容易发现目标，而分步描述则让文字更加简洁易懂。

值得一提的是，Asana 不仅仅提供产品功能文档，还按场景分类，提供多个工作流程的配置方式（最佳实践），比如会议、日历和计划等。试图去引导用户按照 Asana 所推荐的方式来去使用该软件。

其他资源

调研中发现现在的帮助中心内容丰富，除了常见和必要的产品功能文档/开发者文档之外，还有其他很多提供帮助的资源。比如视频讲解、视频课程、实践案例、社区、博客、公开课等。

Jira 通过社区来加强与用户之间的联系，比如：处理用户反馈、新功能发布的通告和邀请客户参与一些试验性的功能等等。社区内也会常驻社区领袖来响应用户的反馈。

Notion Academy 提供了详尽的视频课程，由浅入深。比如从基础的界面功能、团队管理，到使用数据库和人力资源场景下的大型团队空间配置等。

Jira 和 Asan 都会比较积极地举办线上公开课 (Webinars)。通过这种方式来提高品牌知名度、建立专业的形象，保持和用户交流，并最终促进销售。

值得一提的是，我观察到海外的产品，对于视频课程除了直接把视频传上去之外，还能够多做几件事情来提升视频课程的阅读体验，并且在国际化场景更加友好。

1. 支持 CC 字幕。帮助非视频语言母语的用户更好地理解视频内容，同时也能为听力障碍和不方便使用扬声器/耳机的用户提供便利。
2. 支持时间轴目录。帮助用户快速了解视频的主要内容，并找到自己需要的信息。与图文教程相比，视频获取信息的效率比较低，但这种做法能弥补缺陷，提高用户的学习效率。
3. 支持文字稿。帮助用户更好地跟进视频的内容，也方便他们在需要时快速查找相关的信息。并且同样能为听力障碍和不方便使用扬声器/耳机的用户提供便利。
4. 加入互动元素。提供与视频课程相关的调查、实时聊天室或小测试，能够促进学习效果并增加兴趣和参与度，提升课程质量。

我们能学到什么

💡 细致易用的用户文档。用户使用文档的场景是明确需要帮助，或者希望成为专家用户，了解产品设计背后的概念。所以文档需要足够的细致、具体和易用。比如像 Asana 帮助文档中提供了步骤图，或者 Asana 线上公开课中为视频提供了段落拆分。

💡 丰富的资源和帮助方式。不同人在解决问题和接收帮助方面都有着自己的特点和偏好。所以需要提供多样化的帮助资源，比如：文档、视频、案例拆解、线上公开课等，持续提供影响力。

💡 强调最佳实践。Jira 的帮助中心里有许多关于敏捷开发概念、实践的文章。Asana 的实践案例也在频繁加入自身对工作流的理解。在帮助中心中强调最佳实践能够帮助用户更好地使用软件和理解背后的理念。

💡 增进用户的参与感。帮助系统可以支持互动和社区功能。比如评论、分享、点赞等。为了进一步提升用户的参与度，还会支持社区、公开课等。

结语

以上就是我对公司几款竞品帮助中心调研后，总结出来能够帮助新用户上手的产品设计。整体感受是「帮助系统」这一块可以做得很大，又能做得很细。

往大了做：包含基础的文档、功能引导；进阶的课程、模板和大学，以及上升到行业影响力的线上公开课、线下 Events 和职业认证。

往细了做：Onboarding 流程规划、上下文帮助的设计、文档/视频课程的细节，模板的本地化方案等等。

所以说越做设计越感到自己个人力量的渺小，世界太大了… 但不管怎样，来到新公司我的目的是取百家之所长，扩展下之前没怎么接触到的领域。

碎碎念

文中部分名词（如：Proactive help, Reactive help, Push revelations, Push revelations…）由于我没有在中文设计圈内找到合适的翻译，于是便自己琢磨着做出了翻译，本身自己不是想「造概念」的，但总得有个名字吧。如果读者有其他更好的翻译方案欢迎交流。

另外这是我第一次尝试用到人工智能来参与博客的创作。使用到了 ChatGPT 3.5 来帮我做资料搜集、文本润色&修正、名词释义和总结提炼。比如文中「我们能学到什么」里面的小标题，有部分是我发一段文字后，ChatGPT 帮我总结的，或者我理解了很久的 Pull revelations 和 Contextual helps 的关系，也是 ChatGPT 帮我梳理的。

另外也用到了 Midjourney 来生成这篇文章的封面图背景，以及「我们能学到什么」的配图。

这两个工具的强大不必过多介绍了，只是中途一件有件小事值得记录一下。起因是我想查找 Reactive Helps 相关的内容，就去阅读了 NNGroup 上面相关的文章，以及询问 ChatGPT。令人惊讶的是 ChatGPT 给了和 NNGroup 相反的理解…

参考文档

• Onboarding Tutorials vs. Contextual Help | NNGroup
• Help and Documentation: The 10th Usability Heuristic | NNGroup
• Best Help Center Designs for SaaS [15 Examples +Tools to Build Yours] | userpilot
• 20 Help Center Designs that are Worth Stealing — GrowthDot

一部分我会记录下在重构 LRD.IM 项目中，部分核心或比较通用功能的实现过程，以及一些我花了点巧思来设计的地方。

数据源和循环遍历

我的网站中常常会有字段是能在多个地方复用的，比如作品的标题、描述等信息。

这些字段会在多个页面中使用，当文案调整时也需要同步改动，影响到所有相关的地方。所以为了达到「一改全改」的效果，改进网站迭代的效率，这里我会用到数据源和循环遍历来做（以前还真就手动一个个来改的）。

数据源
数据源像是一个专门存储数据的库，里面记载了某个模块会被用到的字段名称及其对应的值。这里面本身没有功能、交互和样式，就像一个仓库。作用就是给到具体的页面或者组件来调用。

循环遍历
有了数据源之后会需要将其逐个安放进统一的容器里面。容器的样式是一致的，布局和适配也通过 CSS 来统一处理好，只是里面的文本、配图、跳转链接等这些属于数据源的内容有差异，所以这里会用到map()来遍历数据，将数据逐一安放进容器里。

功能实现

构建数据源
举个例子，「作品」页面包含了好几个字段：

1. 公司名称
2. 公司 LOGO 图片链接
3. 公司官网网址
4. 公司相关作品
5. 作品名称
6. 作品描述
7. 作品缩略图链接
8. 作品跳转链接

这其中「公司」和「作品」是一对多的关系，一个公司可以对应有多个作品。所以这里据源的结构是：

const ProjectItemData = [
  {
    name: "公司名称",
    img: "公司 LOGO 图片链接",
    url: "公司官网网址",
    projects: [
      {
        title: "作品名称",
        desc: "作品描述",
        img: "作品缩略图链接",
        url: "作品跳转链接",
      },
    ],
  },
];
export default ProjectItemData;

应用在实际页面中

数据源在我的网站里有两种使用方式：直接引用数据源里的某一个字段，或者通过遍历循环来填充进容器里面。

直接引用字段
比如作品详情页里面的 <head> 标签，需要将作品标题，siteMetadata 里的一个字段拼接，我会直接将他们引用到页面当中。

// 导入数据：
import siteMetadata from "/data/siteMetadata";
import ProjectItemData from "/data/ProjectItemData";

// 使用数据：
const title = ProjectItemData[2].projects[0].title; // 指定获取某个字段
<title>{title} - {siteMetadata.title}</title> // 应用在页面中

// 输出:
// <title>SHOPLINE App 组件库构建 - 李瑞东 LRD.IM</title>

循环遍历，将内容逐一填进容器
LRD.IM 的首页会列出我之前任职公司时的实际项目，实际上这就可以将一组数据按顺序地填入设定好样式和交互的容器当中。

我使用 Array.prototype.map() 来实现这个循环遍历。

import ProjectItemData from "/data/ProjectItemData";  //导入数据源
<>
    {ProjectItemData.map((company) => (  //查找数据源中的一级数据
        <div>
            <Image src={company.img} />   //公司 LOGO 图片
            <Link href={company.url}> {company.name} </Link>  //公司名称，点击跳转到公司官网网址
        </div>
        <div>
            {company.projects.map((project) => (  //查找数据源中的二级数据
                <Link href={project.url}>  //作品跳转链接
                    <Image src={project.img} />  //作品缩略图
                    <h3>{project.title}</h3>  //作品名称
                    <p>{project.desc}</p>  // 作品描述
                </Link>
            ))}
        </div>
    ))}
</>

影响范围

数据源和循环遍历这个做法频繁出现在重构后的个人网站里。除了上面提到的首页作品列表，还有比如网站的 Header 导航栏、作品详情页平铺图片的模块、以及 What’s New 页面的内容等等。

如果后续某一个模块的内容需要增删改，我只要修改数据源里面的内容，操作完之后在具体页面中检查一遍就可以了。再也不用在编辑器里打开数十个 html 文件逐个修改了。也不用在一堆代码高亮后的标签内寻找内容了。

一个模块或组件对应一个数据源，然后数据也和页面分离，👍🏻。

不得不接受的局限性

这个看似完美的功能实际上也会有一个令我有点难受局限性。前文提到一句话：

有了数据源之后会需要将其逐个安放进统一的容器里面…

这种按部就班，放进「统一的容器」里的做法会丧失灵活性，比如在：一组容器里面我想要特意给某一个容器添加样式，或者某个字段的值是字符串，我想给里面的某个词语设定一个样式。这似乎不容易办到。

具体来说，在我前年写的一篇「Apple 官网里三个令我惊叹的中文排版细节」里，我学会了给标题或重要文本的最后一个词语和标点设置一个不换行的样式white-space: nowrap;来防止出现孤字，这是需要在 HTML 内对单独每一句话来设定的样式。

而通过数据源来填充文本内容，我似乎没法进行这样的操作了。所以重构后的网站，一些地方可能会出现无法避免的孤字。

后续我会继续关注这个问题，尝试找到低成本的解决办法。这并非毫无希望，起码最近有了解到 React Wrap Balancer 这个组件似乎能改善孤字的现象，后续我会继续跟进。有新进展也会在博客里更新。

当前的解决方案：关键内容/复用较少的内容会写在 JSX 中，而不使用数据源，给到最大的灵活性。而像大标题或副标题，则是使用了 word-break: keep-all; 的方式减少孤字出现的可能性（参考此处）。其他更细的情况无处理。

深色模式

重构前的 LRD.IM，网页的深色和浅色模式是只会跟随用户系统设置的，而这次做到的效果是：

1. 默认颜色主题跟随用户系统设置；
2. 允许有一个按钮来切换深色或浅色模式；
3. 手动更改过颜色主题后，访问网站内其他页面也会受到影响；
4. 页面加载、跳转时没有背景色闪烁。

深色模式在 Next.js 和 Tailwind CSS 结合使用的时候会变得无比简单。

功能实现

功能上我是跟着 Danilo Leal 博客里的这篇文章，一步一步实现适配到深色模式的。主要是使用了 next-themes 提供的能力。没什么难度和卡点。

样式支持

使用 Tailwind CSS 之后，设计深色模式的样式也变得简单很多了。只要在类名前加上dark:，比如这样：text-neutral-800 dark:text-neutral-100，dark:后面的内容就是当切换成深色模式后的样式。

而且在与媒体查询、:hover、:active 等效果配合使用时候，也可以直接叠加，不需要在 CSS 内过多的声明或嵌套。

比如一个按钮的背景色，在不同的颜色主题和状态（默认或 :hover）下色值会不同。同时我也希望在移动端设备尺寸下，不要有 :hover 改变背景色的效果。那么类名大概会是这样：

<Button
    className="
    bg-neutral-100                //浅色模式时，按钮的默认背景色
    dark:bg-neutral-900           //深色模式时，按钮的默认背景色
    sm:hover:bg-neutral-200       //视窗宽度是移动端以上时，:hover 状态的背景色
    dark:sm:hover:bg-neutral-800  //深色模式且视窗宽度是移动端以上时，:hover 状态的背景色
    ">...
</Button>

在我看来，这种做法比传统的 CSS 做法更直观，不用专门语义化一个颜色，或者在冗长的 CSS 里维护两套主题色。所以得益于使用了 Tailwind CSS，我在写样式的时候效率提升了很多。

使用外部组件/图标库

这里可以记录一个我做成了响应式适配的组件：Header。在宽度足够时会将各页面入口平铺展示；而在移动端尺寸下，会收起在一个按钮中，点击后展开一个菜单，在里面提供页面和功能的入口。

组件

实际上我是通过媒体查询视窗宽度来实现的响应式适配。Header 操作区会分成两部分，一部分是平铺的按钮，另一部分是菜单功能。即：

1. 当视窗宽度 > 移动端尺寸时，菜单功能的按钮被隐藏；
2. 而视窗宽度 ≤ 移动端尺寸时，平铺的按钮被隐藏。

<>
    <div className="hidden sm:block"> // 平铺的按钮，视窗宽度 > 移动端尺寸时出现
        <Link>作品</Link>
        <Link>博客</Link>
        <Link>关于我</Link>
    </div>
    <div className="sm:hidden"> // Headless UI 的菜单组件，视窗宽度 ≤ 移动端尺寸时出现
        <Menu> ... </Menu>  
    </div>
</>

至于展开的菜单，我是用了 Headless UI 的 Menu 组件来实现的（经过轻微改造），这里面内置了展开收起的动画，以及无障碍访问相关的特点。组件挺好使的，而且文档也很完善，提供了很多功能和描述。

重构后博客文章里的目录，我也是用类似的方法来做响应式适配的。这部分的内容在下一篇文章中呈现。

图标

虽然说在工作上我做过不少图标，也负责过图标库的管理和迭代。但在这次重构 LRD.IM 的项目中，我没有自己去设计图标，用的都是外部资源。

因为在我看来图标只要能辅助表达出意思就行了，没有必要在这上面花太多功夫。把时间和精力放在其他更有意义的地方。

网站中我主要依赖外部的图标库 React-Icons。里面包含了很多主流图标库的内容，比如：Ant Design、Boostrape、Remix 等等。

而我主要使用了 Ionicons 5 系列的图标，比较符合设计风格。用起来很简单快捷：

import { IoLink, IoList } from "react-icons/io5"; // 加载图标库

<IoLink />  //直接使用图标
<IoList className="text-xl" />  //为图标添加样式

使用框架来构建网站的好处是：能够很方便地用上各种插件和库。这是在旧版网站里不敢想象的事情。

The Joy of React 课程的收获

上一篇文章中提到在项目后期我参加了 The Joy of React 课程，在系统地学习了一些 React 的知识后对代码做了些改进，比如对图片展示组件的改进。

设计图片组件

在我的作品详情页面中，「图片」是一个会被频繁用到的媒体。而图片的呈现又有多种方式。

上图中能看到，我的图片组件会有六个属性允许配置或填写。

1. src：填入图片的路径（必须）
2. alt 文本
3. 图片尺寸：大 / 小
4. 图片滚动：允许 / 禁止
5. 点击放大：允许 / 禁止
6. 图片描述：内容 / 为空

而其中这几种属性可以互相组合，比如：

1. 大尺寸图片 + 允许滚动 + 禁止点击放大 + 有图片描述
2. 小尺寸图片 + 禁止滚动 + 允许点击放大 + 无图片描述
3. 小尺寸图片 + 允许滚动 + 禁止点击放大 + 无图片描述
4. …

所以我在设计的图片组件时，开放了这些属性，允许在页面中自由配置某一张图片的样式和功能。同时将常被用到的属性会被设定为默认值，尽量减少在页面中的代码量。得出这样的一个 API：

export default function ProjectImage({ src, alt, size, scroll, zoom, children }) {
  return (
    <>
      <figure className={scroll === true ? "scroll" : ""}>  //scroll 为 true 则添加允许图片滚动的样式
        <div className={`${size === "small" ? "max-w-2xl" : ""}`}>  //scroll 为 small 则添加限制图片容器宽度的样式
          {zoom === false ? (  //zoom 被设置为 false 时，使用不能点击放大的图片组件
            <Image  
            src={src}  //读取外部填写的图片路径
            alt={alt}  //读取外部填写的图片 alt 文本
          />
          ) : (<Zoom //zoom 被设置为 true (默认值)时，使用允许点击放大的图片组件
            src={src}
            alt={alt}
          ></Zoom>
          )}
        </div>
      </figure>
      {children && <figcaption>{children}</figcaption>}  //children 非空时，将其渲染出来
    </>
  );
}

同时又存在着一个互斥关系，比如：允许滚动的图片，禁止点击放大；禁止滚动的图片，允许点击放大。（因为当下我用到的图片放大组件对长图片的支持并没有很完美），补充相应代码：

export default function ProjectImage({ src, alt, size, scroll, zoom, children
}) {
  zoom = !scroll;
  return (
    <>...</>
  );
}

最后在页面中使用该组件时，只需要填上必填的src，如果有其他尺寸或滚动上的属性配置，也传递进去就好了。

//默认：大尺寸图片 + 禁止滚动 + 允许点击放大 + 无图片描述
<ProjectImage src="01.png" />  

//配置为：大尺寸图片 + 允许滚动 + 禁止点击放大 + 有图片描述
<ProjectImage src="02.png" scroll={true}>  
    一个文本示例。
</ProjectImage>

//配置为：小尺寸图片 + 禁止滚动 + 允许点击放大 + 有图片描述
<ProjectImage src="03.png" size="small">
    另一个文本示例。
</ProjectImage>

可以对比一下在使用组件前后，源文件的对比。代码可读性提高了许多，同时也更方便管理和迭代了。

后如果我想有什么调整或者新功能，只要改动组件就好，再也不用在编辑器里打开数十个 html 文件逐个修改了。也不用在一堆代码高亮后的标签内寻找内容了。

图片组件比较常用，后面也会根据具体用途的变动和个人能力的长进来不断优化。

预告

下一篇文章将会介绍我是如何使用 mdx-bundler 来重构整个博客功能模块，包括 mdx-remark 插件、内容生成方式、目录组件、RSS 生成等内容。以及我为了增强阅读体验所做的工作。敬请期待吧~（自说自话 🙄）

本文于 2023 年 03 月 12 日首发于 LRD.IM

我的个人网站从 2017 年底（大四上学期的期末）进行 “研发”，2018 年初部署运行，现在已经过去了 5 年。中途经过大大小小近 300 次迭代和内容更新。

从原本只是用来放置我做 Side Project 成果的内容，到后来变成我对外展示的窗口，用来展示我在实际工作中的项目，以及设计博客和翻译的文章等。LRD.IM 的页面布局、风格样式、内容、功能等等随着我的设计生涯发展有着很大变化。

互联网档案馆 Internet Archive 保留了 2019 年之后的存档。之后每一次改版我也会在该网站留下存档。不知 5 年后又会是啥样呢。🤔

唯一不变的是，它仍然是用纯粹的 HTML + CSS + JavaScript 来实现的。访问我的网站就像是打开一个文件夹，浏览器只是将我的 html 打开而已。

网站内部没有组件，没有数据源。改动一个公用的地方，如页面顶部导航栏或博客的文章添加一个模块时，我需要在编辑器里打开数十个 html 文件逐个修改。

自己一直有想着改造一波，但自己当前的水平，想做出一个现代化的个人网站还差很多。所以这个计划也就一直搁置，自己日常中最多是观察下其他优秀的个人网站及其实现方式，储备点灵感。

直到两个动机和一个条件的出现，我觉得是时候了。

动机和条件

动机：迭代频率

最开始我的博客页面只是一个列表，点击里面的文章都会跳转到 Medium 平台里面。后面我觉得这样做体验巨差，原因：

• 自己创作的内容全部都放在别的平台上面去了。这是一个令我太不舒服的感受。我的想法是可以放到其他平台内，获取一点点流量和 SEO 的优势，但自己的站点是最优先的；
• Medium 需要科学上网才能较好访问。读者的体验未必会好，从稳定性上考虑也不利于长期发展；
• Medium 一直没有进步。感觉这几年这个平台在原地踏步，或者甚至是下坡路。这是我作为长期用户的主观感受。

所以后面我将 Medium 的文章导出成 HTML 文件（平台的功能），作出相应的调整后贴回自己的网站上面，这样文章就能又回到自己那儿了。

但这个转换的过程并不简单，Medium 导出的 HTML 是带有他们的一些标签和样式的，当时我是将每一篇文章的 HTML 都筛掉没用的内容，然后 CSS 里编写了一套自己的格式文本的样式，使其适应网站的设计风格。由于步骤太多我甚至还将做法记录了下来，发布文章之前任何一步有纰漏都会出问题。

这套混乱的秩序维持了至少一年半，这期间我的每一篇文章都经过这样的处理。包括后面添加的「目录功能」、「博客功能区」等有新增或调整代码的时候，我都要在每一篇文章（40+ 篇）的对应位置里增删改。

这种手动、机械式、重复的工作不仅导致迭代网站的时间成本极高，也很容易出错。

比如某篇博客的功能区，本身应该所有页面的这块内容都应该长得一样，只是日期不同，但就是因为我将数十个 html 文件逐个修改的时候出现了纰漏，导致某些页面的样式异常。

这次重构我抛弃了 HTML，改成了用 MDX 来支持我的博客内容。之后的文章会介绍到我是如何用 mdx-bundler 来重构整个博客功能模块。以及我为了提升阅读体验所做的工作。

动机：体验问题

我对网站里面有一个非常刺眼的体验问题一直耿耿于怀。

暗色主题下刷新页面会出现闪烁
原本的做法下，亮/暗主题色的切换功能是写在 JS 文件里面。而用户在跳转页面时会重新加载一次文件，偶尔会出现令人难以接受的闪烁。

我也带着这个问题咨询了前端工程师朋友，他认为如果将网站做成 SPA，应该就能解决这个问题。

单页应用（英语：single-page application，缩写SPA）是一种网络应用程序或网站的模型，它通过动态重写当前页面来与用户交互，而非传统的从服务器重新加载整个新页面。 — — 维基百科

而且对于主题色，其实最好是能给用户手动来切换，并且记录上次更改后的结果。但这个功能要做在静态网站上，而且想到有代码更改的话又得将数十个 html 文件逐个修改，实在是没有研究的动力了。

条件：离职之后

2022 年 11 月我从欢聚离职，回到老家，暂时离开城市和朋友圈。有充足的时间给我去学习这方面的知识，以及去做相关的实践。

技术栈

这次的重构我的个人网站并不是一时兴起，平常自己也会了解相关的资讯。既然选择了行动，就已经做好跳出舒适圈的准备，接触一些以往从没有实践过的内容。

Next.js

整个 2022 年，通过 Next.js 构建的网站挤满了我的推特信息流。时不时都会看到有些设计师/开发者在推特上发布自己的个人网站。也发现许多充满设计感的网站都是通过 Next.js 来做的，比如 Linear、Pipe、Fey、Frame.io 等。

在一众先驱者的引导之下，我也去了解了下相关介绍，甚至还看了点 Next.js 初学者教程，里面大部分内容我大部分都能够 Get 到。感觉上手难度不大，又有这么多大佬级的网站做背书，于是乎，就是你了 — — Next.js!

Tailwind CSS

我选择使用 Tailwind CSS 的原因主要有两个：

第一个是这个网站做得很好看，包括它给出来的 Template，这让我有了进一步了解的兴趣；

第二个原因是这确实有效解决了在迭代原网站时让我烦恼的地方：

1. 我基本上再也不用绞尽脑汁去想某一个元素的类名（还得是英文的，时间久了想不起来哪个样式用在哪）；
2. 在实际写代码的过程中也不用经常在页面和 CSS 文件中来回切换了。现在写反馈效果、媒体查询、深色样式时很方便；
3. 最关键：我再也不用维护一个 2,000+ 行的层叠样式表了！重构后的 CSS 文件轻量了很多，因为都写进网页和组件中了。

Mdx-bundler

之前将 Medium 文章迁移过来的时候，就发现了 HTML 的做法只适合有富文本编辑器的平台。而像我这样式的多数在代码编辑器里面书写的话，可能 Markdown 更合适。

然后我是在 Tailwind CSS 的 Protocol 模版介绍当中了解到原来 MDX 是可以让 Markdown 和 Next.js 联动起来，然后也在 Josh 介绍自己的博客时。也有介绍到相关内容，于是就选择了 mdx-bundler 来实现我的博客模块。

MDX 允许我们安装各种插件来增强博客的能力。比如支持到 Github Markdown 语法的插件 remark-gfm 和代码高亮插件 Rehype Pretty Code 等。

而且还能嵌入自己编写的 React 组件，这是让人感到惊奇的能力。这意味着我的博客文章可以不仅是图文、视频和 iframe 了，还能有一些互动元素，有很大的想象空间。

过程概述

由于我属于边做边学，所以整个重构的过程并非从头到尾一次性完成的。而是一个螺旋式上升的过程。

第一步：核心功能

当时先完成核心或通用的功能部分（遇到难搞的功能先记录并跳过），然后将原站点的所有内容填充进去。
这时确保网站在本地环境中基本能正常跳转和响应点击，深色模式和响应式等适配工作需要完整做好，因为这方面是相对简单的工作。具体来说：

1. 先学会 Tailwind CSS 和 Next.js 的配合使用，设定好通用的布局和主要样式。以及调试主要页面之间的路由跳转；
2. 开始构建主要页面，学会运用数据源和循环遍历来呈现页面内容（完整的内容先不填充，确保循环能跑通，数据能正常获取）；
3. 尝试使用 mdx-bundler 来读取博客列表和渲染 Markdown 文章。这个模块特别重要，当时花了不少时间。

第二步：内容填充

这时会带着早些时候记录下来的问题和卡点，去耐心查阅并参考尝试其他开发者博客里面他们的实现方案，同时也进入 The Joy of React 课程当中系统地学习一遍 React 的基础内容。具体来说：

1. 填充所有数据源和遍历中用到的内容，如某个字段的文本、配图的 URL 等；
2. mdx-bundler 跑通之后，我用 Markdown 重写了所有的博客文章，并且每篇文章都填入相应的元数据；
3. 填充所有作品详情页里的内容。

第三步：填坑优化

有了知识储备之后，最后再回头把原有的一些卡点和问题填补上，或者优化下原本的代码。甚至会改良下组件的命名、文件夹结构等等，这些会参考到其他开发者他们所总结出来的的最佳实践。

1. 带着过程中遇到的卡点和问题，在其他开发者博客或课程中学习理论知识；
2. 解决之前的卡点和问题，完成所有功能，以及边缘场景的处理；
3. 看看原有代码有没有哪些地方可以改良；
4. 重复「学习→解决→改良」步骤，直到网站达到了我认为能够部署的标准。

解决问题的方法

做一个网站实属不容易。尤其像我一样在自己的能力之外，选择用框架来实现，过程更加是绝非一帆风顺。不止跳出了舒适圈，甚至还跳进了「痛苦圈」。

技术方面的指引我不敢乱写，倒是可以分享下在这次重构的过程中，我用到的几个解决问题的方法：

搜索引擎和编程社区

一些广泛的问题我会找 Google 来帮忙，比如我想看看别人是怎么做亮/暗模式切换的，我会搜索类似 “next.js darkmode switch”，搜索结果中可能会出现一些开发者的博客、Stack Overflow 或 Github Issue 中提出相似问题的人，这些内容是我可以拿来参考的。

ChatGPT

在去年 12 月 ChatGPT 横空出世，当时有看到很多推文有展示它的神奇功力。我甚至觉得它很多的回答比人来回答还要好，很清晰和有条理，让人感到意外。

我也利用上这股强大的力量，用 ChatGPT 来解决一些具体的问题。比如现在博客文章里面的目录，会查找页面内所有的H2 H3标签并生成为一个列表，这就是我向 ChatGPT 提出我的需求之后，它来帮我写出来的。

另外我也会让 ChatGPT 帮忙解释某段代码的意思或作用。我从搜索引擎或编程社区里获得的一些解决方案，有时候某些语句自己没看懂的时候，会需要 ChatGPT 来帮忙解释一下，好让我针对自己网站的特点作出些许改造，或者了解报错原因和解决方法。

Joy of React

即便 ChatGPT 能解决部分具体的问题，但也不是万能的。实际开发中有些特别具体的问题，始终还是要靠自己。我对 JavaScript 掌握的程度是属于半滴水（半桶水都算不上），对 React 以及里面的 JSX 语法更是完全没了解过。

简单的内容靠查阅文档 + 观察规律可以学会，比如我通过看其他人的案例，我大概知道了每个组件里面都要有一个export、return()里面只能有一个子标签、JSX 里面有一个特殊的标签是<> ... </>等等...

但稍微再具体一点的问题，比如根据某个条件来更改样式，或者甚至想直接做一个需要传递参数来改变展示方式的组件，这些特别个性化的内容想要光靠搜索引擎和 ChatGPT，效率太低了。很可能搜半天还是一头雾水，浪费光阴。

刚好在今年 1 月 24 日，前端大佬 Josh W. Comeau 发布了 The Joy of React 的教程，这是一份面向初学者的 React 教程。在里面我能系统地学到一些 React 相关的知识，或者课程中会用到的 JavaScript 的基础等。

这门课程对我的网站重构项目起了很大的帮助，学习后我弄清楚了一些 React 的运行规则，也确实做出了一些实用的组件，改进了页面的代码质量。之前一直卡住的、很具体的问题也在学习之后得到了解决。

这份 $50 左右的课程干货满满，作者也很用心地安排了每个章节会有互动性的练习，也会附带一些视频解说（有 CC 字幕和视频摘要）。后续我可能会出一篇文章来回顾下我在这个课程内学到的内容，记录下这段激情澎湃的青葱岁月。

请教专业人士

好吧，如果有些问题确实难搞，自己用尽所有的方法都没法解决，同时也在这个问题上耗费了很长时间的时候，我会咨询一些前端工程师朋友。

工作几年我一直和前端工程师的关系都也还行，所以有时候问到些问题他们也乐意帮我解答（还因为我的问题在他们眼里其实非常基础…）。

除了现实中认识的朋友以外，其实也可以咨询网络上的一些开发者。如果一个开发者将他的经验分享出来后，其他人使用过程中遇到问题，大部分都乐意帮忙解决的。

未完待续…

这一篇文章记录了重构我的个人网站 LRD.IM 时的经历，计划后面会有多几篇文章来记录具体我做到某个模块时的一些过程，或者说重构之后一些我认为比较有意思的改良等等，算是给这次重构计划一个交代。

本文于 2023 年 02 月 21 日首发于 LRD.IM

我的个人网站 LRD.IM 从 2018 年元旦发布至今，已经持续维护 4 年了。从最开始根据一个网站模板替换图文，到现在全面的「自主研发」，这是我最骄傲的一款作品。接下来要开始尝试将我的博客内容输出成 RSS 源。

这篇博客不谈设计。写一点自己对互联网的初印象，将博客做成 RSS 源的原因，以及使用 RSSHub 将自己网站生成订阅源的过程。

吹吹水：我的互联网回忆录

对早期互联网的印象

家里 2005 年配置了台电脑，依稀记得那会儿互联网的潮流正好是从门户网站转换到「社会性网络」。

Discuz!、贴吧、QQ空间、开心网等等，都是 Web 2.0 的代表作，我「当年」也有高度参与到这些生态里面。那时候的互联网鼓励人们创造内容，强调互动和内容本身。而不像现在基于所谓的「算法」一直在投喂内容，网站上充斥着营销号、广告、对立、（甚至审查🤫）…

我记得以前网络上的内容是挺有趣的，因为都是自发的内容，感觉很真实。而现在在网上看到「有趣」的内容，却总感觉像是某个 MCN 机构生产出来的，所有内容都有目的，一直在包装、孵化，指向最后的变现…

所以正好我这位在 Web 2.0 时代背景下成长的网民，正好也有掌握了一些专业知识，于是乎就捣鼓出属于我的个人网站 LRD.IM，以及目前为止积累了 40 多篇的设计博客。一方面是想通过这些来积累自己的专业知识，另一方面是更想在互联网上留下自己的（且属于自己）的一些痕迹。

对 RSS 的执念

以前在 WordPress 搭建的博客、新闻资讯等网站总会有一个 RSS 订阅渠道，最初还没有了解过是什么意思，只是记住了有这个很不起眼的橙色的彩虹条纹的图标。

直到在大学了解到了一些信息获取来源方式和分类之后，才真正了解到 RSS 这个东西。很神奇的是它将内容进行重新格式化输出，将内容和从页面中分离出来，供读者在自己喜欢的第三方阅读器里接收新内容并阅读。

我还是挺认同这个概念的，即使它是 20 年前的产物。

分离原本的网页，意味着读者可以根据自己喜好在第三方阅读器上进行阅读，甚至自己捣鼓一个阅读器，而并非局限在原本网页管理者的设计中。

而第三方阅读器通常都会有新内容通知、已读未读标记、分类、标签等功能，这意味着读者能够拥有自己的一套信息获取方式，而不需要受到算法的介入，并能及时获得新内容的推送。

正好由于今年我的设计博客还上了不少公众号、周报的推荐，我察觉到拥有一个自己的内容推送服务迫在眉睫，而 RSS 订阅、邮件订阅都能满足这个需求，正好我就先将 RSS 订阅服务做起来先。

综上所述，我认同 RSS 的中立、纯粹、无算法介入，以及需要获取一个推送功能。所以，这时的我作为互联网内容生产者，是时候为自己的博客搭建一个 RSS 服务了！

实打实：将自己的网站生成 RSS 订阅源

预期

首先阐述下我的预期效果：

• 抓取到 Blog 页面里的所有博客，并能检测到内容变动（包括增删改）；
• 将抓取的内容生成为 RSS 要求的格式，比如 XML；
• 更新内容时，在第三方阅读器中确保至少的时效性（不会延迟太久）和内容准确度（顺序不会错乱）；
• 订阅链接用回自己的域名。

尝试一：第三方生成服务

于是乎我首先也试了几个做法，第一个是寄托于第三方的 RSS 生成服务。比如 Feed43、Feedburner、RSS.app。当时我是期望这些第三方服务能够满足上述的预期效果，自动抓取我发布的新博客生成为 RSS 文件。它们确实也做到了，但会各自有一些硬伤。

• Feed43：更新快，准确。但是免费版里生成的 Feed 里面会带有它们品牌的宣传，且国内访问速度一般；
• Feedburner：更新速度一般，准确。但是被墙了，国内无法正常访问。
• RSS.app：更新快，准确。但是只能抓取前几条内容，想要保留所有内容需付费升级账号。是否被墙倒是没试过。

试了一遍论坛/讨论组内大伙儿推荐的 RSS 生成服务提供商，没有完美地达到我的期望，每个都是差一点，只能靠自己了。

尝试二：手动制作静态文件

眼见外部服务不好使，于是乎我跑去看了看 RSS 的语法规范，尝试用最笨的方法：按照语法自己手动编写一份 XML 文档出来，给到读者去订阅。

大费周章按 RSS 语法规范写完了 XML，传了两份用作测试，一份传在自己的阿里云轻应用服务器上，另一份传到了阿里云 OSS 里。之后用第三方阅读器订阅 RSS 链接。

结果在阅读器里看到顺序错乱，时间异常，更新非常迟缓。刚开始我还以为这个笨方法能行得通，只是做起来比较麻烦，没想到仍然有这么多缺点。

最后一试：用 RSSHub 将自己网站生成为 RSS 源

了解 RSSHub
前两种方法试过都不能满足我的要求之后，我实在找不到一个好的思路或方向去实现，唯有在 V2EX 上发了个帖子请教下其他人。虽然帖子只有两个人回复，但足够启发我去解决问题了。

一楼回复建议我给 RSSHub 提个申请，让其他人写个规则来抓取我的网站，然后合并到 RSSHub 项目里，用该链接作为 RSS 的订阅链接。

后面我去了解了下 RSSHub，原来这是一个开源的 RSS 订阅源生成器，编写好规则（项目内称为脚本）后就能将内容按照 RSS 的语法生成一份订阅源，之后都可以用生成出来的链接在第三方阅读器上订阅和浏览。同时可以部署在自己的服务器里面，也能直接用 RSSHub 项目内别人预先编写好的规则，两者的效果是一样的。

粗浅了解下 RSSHub 的能力，以及也看了用该服务生成出来的订阅链接，功能上是能解决我的问题，但是时效性、准确度这些得自己部署完才能知道。

二楼回复认为静态的 XML 文件作为订阅源，会存在着不受我控制的缓存机制。于是乎我更坚定地认为应该尝试使用 RSSHub 的服务，毕竟这是动态生成，不是一个憨憨的静态文件。

安装 RSSHub
登录到服务器，由于我用的网站在阿里云轻服务器上搭建的，所以直接在网页里就能远程登录，其他服务器也能 ssh 登录后依次输入指令安装并运行 RSSHub。

git clone https://github.com/DIYgod/RSSHub.git
cd RSSHub
npm install
npm start

成功安装并运行后，在浏览器访问 1200 端口应该能看到如下页面。

回到终端，设置 RSSHub 服务常驻（断开 ssh 链接后仍然保持服务）；以及开机自启。

# 设置常驻
npm install pm2 -g
pm2 start lib/index.js

# 设置开机自启
pm2 save
pm2 startup

这时可以访问几个 RSSHub 项目自带的路由，探索下其他有趣的 RSS 源。然后开始编写自己的脚本路由。

编写脚本路由
这一部分我的思路是参考文档的指引，并且在 RSSHub 项目内找到已有的脚本路由，找一份与自己网页结构类似的脚本，照葫芦画瓢捣鼓一份出来。

按文档的说法，/lib/router.js 里面记载了所有路由，即指明通过域名访问而指向的脚本。我先在里面创建一个路由，让其链接到之后创建的脚本。

# 添加路由
router.get('/feed', lazyloadRouteHandler('./routes/lrdim/blogs'));

其中 /feed 意思是我希望通过域名/feed 能够访问到我的 RSS 源，即 lrd.im/feed。后面的 ./routes/lrdim/blogs 意思是用前面的链接访问时，是链接到 /routes/lrdim/blogs.js 这个文件，用里面的规则生成 RSS 源。

然后到 /lib/routes 里面创建 lrdim 这个文件夹，并在里面创建 blog.js 这个文件，我们的抓取规则要写在里面。

由于我的网站是静态的 HTML 页面，所以我按照文档里的第二种方法，按照元素的标签和样式来抓取里面的数据。并且当时有参考了一个网页结构同样很简单的 RSSHub 内置源：十年之约。具体做法不在这详细说明了，主要按文档规范走就没啥问题，cheerio 语法也很直观容易理解。

保存后过几分钟，已经能在 lrd.im:1200/feed 中访问生成的 RSS 源了。此时需检查下名称、描述、标题、摘要、日期等有没有问题。

注意：日期必须按照格式编写，不能出现非法内容。否则这条 item 不会出现在结果中。我是写成了 YYYY-MM-DD。

调整渲染模版
由于刚刚通过设置 RSSHub 脚本获取到的数据，会经过 rss.art 模版处理后再成为 RSS 订阅源，所以我们需要打开 /lib/views/rss.art 对渲染模版作出相应的调整，比如预设 <webMaster> 不符合预期，调整为我自己的邮箱。

设置代理
至此，我的 RSS 订阅源已经生成完毕，内容、格式等符合要求，剩下的只有域名还不大对劲。

截至到上面的步骤，我的 RSS 订阅源扔人家需要通过端口来访问：lrd.im:1200/feed。这个肯定是不能作为最终产物的，谁会把端口直接暴露出来，太丢人了。于是乎需要配置最后一步：设置代理。

我的服务器里安装了 nginx，打开 nginx/conf/nginx.conf 后配置代理，将 lrd.im/feed 指向 1200 端口的页面。

location /feed {
  proxy_pass http://127.0.0.1:1200;
}

此时测试 lrd.im/feed，已经能正常访问经 RSSHub 生成的订阅源。

验收
拿订阅链接去各主流阅读器中试验，尝试搜索、添加此链接，并尝试增删改被抓取的网页内容，检查到确实能够及时更新，且不会信息错乱。

大功告成！奉上我的设计博客正式的 RSS 订阅链接：https://lrd.im/feed

将该链接复制到 RSS 阅读器上就能够及时获取我的最新设计博客了。阅读器的话看个人喜好，目前我觉得 Inoreader 和 Reeder 的体验都不错。

做多啲：在网站中曝光 RSS 订阅功能

费了这么大周章捣鼓的新功能，起码在我的网站里多多曝光才是。所以我顺手做了三件事。

支持 RSSHub Radar

RSSHub 有一个浏览器插件叫 RSSHub Radar，用于探测网站上提供的 RSS，让读者能在浏览器的插件位置直接就能订阅，而不必在网页上费劲去找 RSS 订阅按钮。

支持该功能也不怎么复杂，我在所有页面的 <head> 处都添加了一条订阅地址，就能够被 RSSHub Radar 识别到。

博客页新功能提示

既然是我的博客内容的 RSS 源，那理所当然地应该在 lrd.im/blog.html 里添加一个稍微醒目一点的 Banner，提示到当前已经支持 RSS 啦！

此处参考了 Instagram 和 Apple 的样式，高亮若干秒之后开始减弱对比，使其融入到页面中。用了 CSS 的 keyframe 来做。

博客详情页功能组

从 Google Analytics 处跟踪到的数据，挺多流量是来自直接的博客详情页，而不是先从列表页跳转到详情页。所以也为了增加在详情页的曝光，我在「作者信息」一行右侧新添加了几个按钮，分别是：复制文章链接、RSS 订阅、联系小东。

原本「复制文章链接」这个功能我是做成响应式设计，只在移动端尺寸下才能看到，但还是根据 GA 数据反馈，造访我的博客的流量中有至少 75% 是来自桌面端，所以我将这个功能开放了。

「RSS 订阅」功能点击后能直接跳转到 lrd.im/feed，后续的订阅操作懂得都懂。每篇文章都提供这个入口，极大提高曝光量。

「联系小东」的功能是点击后出现我的微信二维码。我的设计博客通常会输出我的观点和看法，而我的网站里面又没有评论的功能，所以我捣鼓了一个微信二维码上去，读者如果有东西想和我交流就能直接加我好友一起交流。

这些功能没做成悬停在左右两侧，原因是我不太想在读者阅读时有其他干扰项。

哦对了，还顺便 Close 了一个，也是目前唯一一个 Issue。

总结

给博客生成 RSS 订阅源这事虽然一直惦记了有大半年，但实际开始到最终呈现，历时一周左右，都是用下班时间和周末探索的。

又到了给自己挖坑的时间：后面关于博客订阅这块，我会做的几件事：

• 想办法将自己的 RSS 源链接提交到 RSSHub 项目下的博客分类；
• 研究主流的 RSS 阅读器抓取文章首图的规则。现在抓取的首图并非每次都符合我的预期，可能本身我的博客详情页构造需要作些许调整；
• 探索开拓邮箱订阅功能的必要性。目前 Medium 能够用邮箱订阅我的最新博客动态，在想是否需要用到 Revue 或竹白之类的自己捣鼓一个邮件订阅服务，内嵌到个人网站里面去。顾虑是担心这种平台的文本编辑器功能是否够完善，以及和 Medium 功能重复了。

完成了自己的一项执念，如释重负，舒坦开朗。但心里仍然藏了另一项执念，我惦记了有至少一两年了，仍待推进…

参考文档

• 参与我们
• 为任意网站创建 RSSHub 路由的思路 | Maron的自留地
• 利用 Feed43，将任意网页制作成 RSS 订阅源 | 一日一技 - 少数派
• proxy_pass url 反向代理的坑 | Nginx 入门教程

前言：公司前段时间新来了不少交互设计师， Leader 邀请我做一次网页布局相关的分享会，来帮助以往比较少界面设计经验的交互设计师能够更好地完成设计方案产出和交付。现在我将文稿记录在这里。

布局是处理内容和视窗或容器的关系。通过创建清晰的视觉模式来帮助建立层次结构并传达重要的内容。通过这次分享，你将会了解到：

• 广义上的四种网页布局做法；
• 响应式布局和自适应布局的区别；
• SHOPLINE 主站后台用到的四种典型布局及其特点；
• 被归纳出来的 3 种响应式布局适配思路；
• 交付清晰的布局适配方案的方法；
• 新的适配方法：容器查询 Container Queries 概念介绍及场景探索。

（这份文稿可能比较长，读者不妨挑取感兴趣的内容查看即可✌️）

布局方式

固定布局

以一个固定的宽度来布局，视窗宽度变化不会改变内容的展示方式。可以理解为“不做适配”。一般在复杂的网页后台会使用这种布局方式，因为适配一个复杂后台成本较高，就会用成本最低的固定布局。

流式布局

通过设置元素所占比例来使内容适应视窗。与固定布局的明显区别是这时内容已经能根据宽度来调整适配，以更好地展示内容。这种布局典型的代表作便是我们常说到的 “栅格系统”。

响应式布局

响应式布局其实就是我们平常所说的 “适配”。页面的布局和元素会随着浏览器视窗的变化而重新排列。实现上会利用流式布局和断点适配等做法，将一套代码适用在所有屏幕分辨率。

响应式布局下，页面内的元素需要能够调整大小和重新排列，所以在专注于内容（如新闻、博客）而不是功能的网站（如 SaaS）上实施响应式设计通常更容易。复杂的数据或交互可能很难在拥有高度的灵活的同时保持清晰性和功能性。

一股清流是咱们的竞品 Shopify，将复杂的电商独立站后台也做到了响应式布局。这一点哪怕是 JIRA、Salesforce 等其他国外大公司的应用也没做到的，所以 Shopify 在设计上有很多值得我们学习的地方。

自适应布局

特点是会为不同类型的设备而专门做一套设计，实现上会用多套代码来适应多种设备。通常会由服务端来根据设备类型而选择要展示的页面布局。

比如 SheIn 官网的链接是 https://us.shein.com，用手机设备访问该链接时，会被重定向至 https://m.shein.com/us，以展示专门针对手机端用户的网页。

这个做法在 C 端网站上使用比较多，因为使用场景不同，电脑端和移动端的产品运营策略会有明显不同，设计上的侧重点、功能都会有较大差异。除了电商网站以外，常见的比如新闻资讯、视频直播等产品也会这样做。

区分响应式布局和自适应布局的方法

比较简单的方法是在打开网页后改变手动改变浏览器宽度：

• 响应式布局：页面布局会实时做出适当的调整以确保内容完整展示；
• 自适应布局：页面没有适应到浏览器宽度，需要重新加载页面后才会更新布局。

当然也有些站点比较注重用户体验，自适应、响应式布局均有实现。所以这类网页可以确保在任何设备和任何尺寸的视窗下都能较好地展示内容。

SHOPLINE 主站的经典布局方式

在实际工作中不难发现有几种布局方式是特别常用的，而且也会有既定的一套适配方法，这一节内容是对此的相关描述。

基础布局

基础的将内容平铺出来，注意有三种宽度做法，对应不同的场景。

满宽度：承载更多同层级的信息
这种布局拥有最多的宽度，所以适合在信息量较大（表头或筛选操作较多）的宽列表和复杂表格中使用。

中等宽度：综合型页面
最常用的做法，适用于综合型页面，比如复杂程度适中的表格、概览页、详情页等。

窄宽度：专注单个任务
页面本身的内容较简洁时，如简单报表和表单，会用到该布局。用户可以专注于单个任务之中。

主次布局：突出重点任务

这种布局常用在后台里复杂/内容较多的编辑页面中，其特点是分成主要和次要的两列，能够突出重点任务。

将重点任务或必填项放在主要的列，而次要/低频/非必填/摘要等内容则放在次要的列里面。

注释布局：快速导航到特定模块

将内容分为多个不同的模块，模块之间的关系并非环环相扣或很密切。所以这种布局便于用户快速定位到某个特定的模块，并且能承载一部分的描述文本，会常用在设置页面当中。

编辑布局：预览

用于有实时预览需求的编辑场景，左列进行的改动会实时反馈在右列预览界面中。

响应式布局的适配思路

Figma 中的画板宽度是固定的，而实际情况中浏览器的视窗会随用户拖动而改变，我们在做响应式适配时可以参考以下 3 种思路。

掌握适配思路的重要性：
适配思路提供了足够多的方法设计方法，帮助设计师应对各种无法被枚举的场景。

思路一：调整大小

动态调整 UI 元素的大小使其适应容器或视窗。常用在图片、步骤条或其他系统控件当中。

实现方式1
宽度缩放。即高度不变，只是元素的宽度作弹性变化，此时内容可能会被裁剪，或者挤压同一行的其他元素。常用在输入框、进度条、下拉菜单等系统控件中。

实现方式2
等比缩放，或按某个比例缩放元素，常用在图片或视频播放器等媒体元素上。

TIPS: 图片、视频适应容器时，会有三种适配方式：

• Cover：内容等比缩放填满容器四条边，可能会裁剪部分；
• Contain：内容等比缩放以填满容器的宽或高，可能会露出部分背景；
• Scale-down：在原图和 Contain 之间取一个尺寸更小的结果。

思路二：重新放置

更改 UI 元素的位置和放置方式，以换取更大的横向空间用于内容的展示。

实现方式1
将排列规则设置为内容放不下而自动换行。

实现方式2
另一种方式则是通过设置断点进行布局更改。

思路三：隐藏元素

基于屏幕空间来显示或隐藏 UI 元素。将原本在同一行内的元素折叠收起，通过一些交互动作来获取完整信息（如点击、Hover、快捷键等）。

实现方式1
在内容超出容器时，折叠在视窗外的内容。通常用在内容数量或所占宽度不固定时的一种适配方式。

实现方式2
视窗宽度到达某个断点时折叠。在这种方式下内容宽度不会影响是否折叠，所以适合用在内容固定的场景。判断到出最佳断点时机后才触发折叠。

交付布局适配方案

在实际网页中还原响应式布局的适配时，前端会用到的主要是两种方式：

• 给内容设定相应的适配方式，会用到 Flex 布局。
• 通过断点来改变布局，则是用到媒体查询；

这里不会从前端角度展开来说这两种方式的特点，而是会介绍在做设计时如何交付布局适配方案。

交付内容适配方案

内容适配通常指的是在一些卡片或容器里面的内容、文本、控件等的适配方式。实践中我会专门在旁边加一个画板用来描述内容的适配方式。通常是先写容器的适配，再写文本的适配，因为通常文本总是会被容器所包裹着。

顺便再列举一些我常用的内容适配方式吧。由于我们业务的特点是需要支持国际化适配，所以很多地方都是需要用到内容宽度，而不是固定宽度。

交付断点适配方案

断点适配指的是我想在视窗宽度小于多少或大于多少时，布局作出怎样的变化。如果基础的设计稿是用 1920 宽度的画板来完成，那么我会在标注在视窗宽度小于某个值时时，希望页面的布局会如何变化。

这一部分是偏向标注一些较大的布局改动。比如卡片的列数、一行的内容个数等等，这些适配是需要前端利用媒体查询来做屏幕断点适配的。

新的适配方式

容器查询（Container Queries）能够让我们实现基于容器尺寸的响应式适配。

开始写这篇文稿时是九月初，那时候这个规则仍然在测试中。而刚好现在从 Chrome 106、Safari 16 开始，已经正式支持了。所以咱们有必要去了解容器查询的能力以及去畅享潜在的使用场景。

什么是容器查询

以往我们用媒体查询来实现自适应布局。让 CSS 探测浏览器的视窗宽度，大于或少于某个像素时作出相应的样式变化。

而容器查询允许我们探测一个容器的尺寸（比如某个卡片宽度、导航栏宽度等），基于此来做样式变化。

畅想适用场景

小型布局
容器查询的特点使得容器在做样式的自适应适配时可以更准确和灵活。比如在多列布局时，针对某一列的宽度来做更多的适配动作。

文本适配
由于可以探测容器或元素的宽度，或许在展示指标的时候能派上用场，即根据容器的不同宽度来调整字体大小、字重等。

这种事情在以往可能会需要用到 JavaScript 或其他方式实现，现在纯靠 CSS 就能实现了。

尤其是现在有了容器查询后，由于样式变化是基于原本的模块，而不是浏览器视窗的，我们或许甚至可以抽离出来，将这种适配方式做成组件化，会更灵活。

内嵌 iframe
iframe 嵌进网页之后，视窗宽度其实指的是 iframe 容器的宽度，而不是常规的浏览器宽度。如果此时 iframe 内的页面沿用常规的断点尺寸，那么效果会产生些许偏差。

因为 iframe 容器 始终是会比浏览器宽度要小。就好比 iframe 内网页断点设置是小于 1200px 时布局变更，那么实际上会在浏览器视窗比 1200px 大的时候，就已经发生了布局变更。

这时如果利用上容器查询的特点，或许就能确保布局变化始终在预期之内，不会受到 iframe 容器本身宽度而干扰。

总结

撰写这份文稿之前也有采访过几位交互设计师，针对他们的痛点也专门准备了相应的内容，希望能对他们有帮助。

都说分享会的最大受益人是分享者本人，确实这次在整理相关知识的过程中也有不少新的收获，对我来说在探索自适应和响应式布局的区别、尝试抽象归纳出尽可能多的适配方法、容器查询等等这些内容的时候我也有收获到不少东西。

参考

• Adaptive vs. Responsive Design
• iShadeed Lab - CSS Container Queries
• Page layouts
• 介绍2022最期待且已正式支持的CSS container容器查询 " 张鑫旭-鑫空间-鑫生活

动机

在我接手 App 这波需求迭代的时候，发现一个很常见的问题却没有在设计规范里提到过（其实原本也没啥设计规范…）。那就是：表单的校验时机。

工作中我发现每个保存到数据库的表单都会有至少一个校验规则，最常见的是字数，其他的有类似格式（邮箱、数量）、上下限（价格、库存数）等。而表单的校验时机通常是在三种方式内选择：

1. 输入中校验；
2. 失焦后校验；
3. 提交时校验。

由于接手时并没有规范或者指引帮助我如何判断使用哪种，工期紧张也没有足够时间去探索，我只能拍脑袋地大部分都采取了「失焦后校验」的方法。

后面我发现这其中的差异还是挺耐人寻味的，有必要探索三者之间的各自优劣势和适用场景，于是乎就有了这篇文章。

三种校验时机的差异

输入中校验

效果：输入过程中（即文本有更改时）校验并反馈报错文案。
优点：实时反馈，出错后立即提示。
缺点：容易误判。即未完成输入就提示出错。

适用场景：
1. 纯前端能满足校验需求时；
2. 校验规则较严苛时，如一个表单多条校验规则，或中途某个错误字符直接影响到表单提交时。

修正错误的成本：低 ★
在手机的的「键盘控件」内重新键入内容即可完成修正。

失焦后校验

效果：失去焦点后校验并反馈报错文案。
优点：输入过程中无干扰，在输入完成后再反馈报错文案。
缺点：失焦后才知道结果，修正成本高。

适用场景：
1. 纯前端能满足校验需求时；
2. 用户对输入框内容格式有预期时，如邮箱、手机号等。

修正错误的成本：高 ★★
需要先「失焦」，再回到原本的输入框「重新聚焦」，并通过「键盘控件」修正。

提交时检验

效果：提交表单时校验并反馈报错文案，通常会伴随着使用 Toast 提示。
优点：后端校验时，不影响性能&体验。
缺点：报错反馈很不及时。

适用场景：
1. 大部分需要后端校验的表单。

修正错误的成本：较高 ★★★
需要先「提交表单」，再「找到」出错的的输入框，并「重新聚焦」原本的输入框，通过「键盘控件」修正。

至此，上面列出了三种校验方式的各自优劣势，对比后不难得出结论。

结论

推荐优先使用「输入中校验」的规则。

原因：
1. 反馈最及时；
2. 修正错误的成本最低；
3. 对研发工作量和 App 性能无影响（前端校验时）。

理论支撑：

“理想情况下，所有验证都应该是内联的…”
“…在字段完成后立即修复错误对用户的交互成本最低…”

—— 来自 Nielsen Norman Group 的《如何反馈表单中的错误：10 条设计指南》

通过这次的对比，我决定了之后都将「输入中校验」作为主要的校验方式，当然这种方式也有一些不适用的场景，此时就需要换一种校验方式。举例一些常见的不适合用「输入中校验」的表单：

1. 容易误判的表单，如校验邮箱、电话、网址的格式时；
2. 设置了数量下限时，如公司业务里的 B2B 商品设置了起批量时；
3. 需要后端校验时，如需查重或对比数量上下限时。

其他感悟

对需要后端检验的表单态度

因为涉及到后端检验，意味着需要网络，那就会出现加载中/超时/加载失败/加载成功 的情况，所以这种表单一般是失焦后或提交时检验，这对输入体验会相对友好一些。

但也有例外，比如 Twitter 账号在重命名时，就使用的是输入中校验。可能是因为 Twitter 用户量庞大，特别容易重名。提交后检验反而效率更低。

输入前的体验设计

常言道好的体验设计能减少用户出错，在表单输入之前，实际上我们也可以用多种方式明示暗示文本框的填写规则。

一、输入框长度

输入框长度能过暗示文本框的预期填入内容。比如在填地址和邮编时，通常地址我们会预留比较宽的输入框给用户填写，而邮编则可以相应缩减，因为这两个类型的字段，预期填写的文本长度是有明显不同的。

参考资料：整齐划一？不如错落有致。| Ant Design 4.0 系列分享

二、实时字数显示

在输入框旁边实时展示当前字数和上限是也是比较常见的做法。
优点：避免出错；让用户对表单的规则有一个预期。
缺点：页面出现过多此类提示会使页面臃肿，反而会增加视觉&认知负荷。

所以我对这个做法的态度是：每个表单都会有文字输入的上限，超过上限时也一定会禁止提交、出现提示。但是否将字数提示常驻展示，取决于「用户对长度是否有预期」。

比如在一些备注、描述、说明等大段文字里，用户可能会输入到大段文本，但又对这些输入框的上限没有预期，那我这里判断到是需要出现实时字数提示的。而像比如填写姓名、添加标签这种，字数上限只是一个兜底的判断逻辑，不需要特意暴露出来。

另外可以根据存量数据来决定是否展示实时字数提示。比如让后端同事帮忙导出在数据库里的数据，能知道用户在这个输入框里一般会填写多少个字，如果大部分情况都是接近字数上限的，意味着用户在这个输入框会输入较多的文本，此时就需要展示当前字数上限，甚至或者调整校验规则。这是我在上一家公司（千聊）里做过的事情。

三、占位符（Placeholder）

无论是 NNGROUP 还是 Shopify UX，都对占位符文本持有比较谨慎的态度，甚至会用到 Harmful、Avoid 等贬义词。他们主要批判的是用占位符代替标签的做法，我们在使用时避免这种用法就好了。

实际上占位符和标签共同使用时没什么毛病，占位符确实能起到一定的补充作用，用来提示要输入内容的类型和名称，只是不要用来展示重要内容和代替掉标签就好了。合理使用也是减少用户出错的方式之一。

四、常驻帮助文本（Help text）

帮助文本可以视为占位符的进阶版，具体效果在输入框附近常驻一段简短、必要的说明内容，帮助商家了解输入框所要求的格式，或输入后的内容会怎么处理。甚至还可以链接到 FAQ，有丰富的用法。

一条原则

在文本有上限的输入框里，我们会面临一个选择是：超过字数后是否允许输入？

我在这里的建议是允许继续输入，同时会出现报错的反馈，告知规则。因为翻查了很多 UX 资料，都建议在设计中要避免「打断了用户行为」。下面放出两种方法的优劣对比，各位看官理性抉择：

超上限后允许继续输入
效果：输入的文本超过该文本框校验规则上限时，出现报错反馈，同时也可以继续输入文本。
优点：反馈及时，原因清晰。
缺点：🤔…

到达上限后禁止输入
效果：输入的文本到达该文本框校验规则的上限时，禁止输入更多的文字了。
优点：🤔…
缺点：没有反馈，不知道错误原因。

这么看下来，就体验而言是「超出上限后允许继续输入」要好很多。而且这种方法还照顾到一个场景是：允许用户在输入中发现超出长度后，把当前的单词输入完整后再去删减其他内容。

当然毫无疑问，到达上限后直接不允许输入是对设计和研发来说最省力的做法。这种做法下不用反馈，也就不需要做反馈时机的决策、反馈的文案及多语言、文本的适配、反馈后的布局适配…

我有一段经历是项目工期巨紧张，规范也没相关的指引。当时有很多比制定文本输入规则还重要的事情需要处理，于是乎我就都一拍脑袋用了「达上限后禁止输入」的方法。

后面与其他方式对比发现这种做法应该是体验比较差的做法了。像现在我把规范做法加进 App 设计的指引里面之后，就大多数情况下都会使用「允许继续输入，在输入中反馈」的方式实现。

结语

以上内容就是目前来说我对文本框校验规则的一些认识，包含了各种校验时机的对比，输入前的体验设计，以及不打断用户操作的原则。

这次的总结是我挺久之前就想干的事情了，因为平常工作中一直遇到这种问题，也没有一个明确的设计指引能够参考，现在自己写下来这篇笔记之后，之后的设计方案会考虑得更周全，说服力也更强了（希望是吧）…

同时再浅挖一个坑：之后要探索下表单提交按钮相关知识，比如说什么时候要禁用按钮，什么时候是允许点击但报错等等，这个应该还要复杂一点…

参考资料

• How to Report Errors in Forms: 10 Design Guidelines
• 整齐划一？不如错落有致。| Ant Design 4.0 系列分享
• Placeholders in Form Fields Are Harmful
• Text fields

原文：How to push the limits of a design system · Shopify UX

作者：José Torre

译者：李瑞东

翻译小帮手：李泽嘉 @urcharles7（公司的交互 Intern）

为了跟上需求，设计系统需要不断发展。讽刺的是，设计系统的进化似乎有点像先有鸡还是先有蛋的问题。

如果不知道产品业务需要什么，专门负责设计系统迭代的团队就无法进一步发展。另一方面，大多数业务设计团队只在系统的现有规范和组件内完成工作，这不利于进一步推动系统的发展。这样看上去像是僵住了，大家都在停滞不前。

我们 Polaris 团队（译者注：Polaris 是 Shopify 的设计系统）想打破这种僵局，所以采取了行动……

跨越鸿沟

为了防止 Polaris 变得失去创造力，我们必须更接近产品。因此，我们开始了一项名为 PolarisLab 的计划。在几周的时间里，围绕一个特定的主题，与产品团队发起并参与了一系列工作坊和会议。目标很简单，就是要设计系统团队与产品团队紧密合作，以便：

1. 帮助团队找到解决问题的最佳方案；
2. 找到设计系统不断发展迭代的方法。

我们的首先聚焦在 Layout 组件上。因为我们开始注意到越来越多的页面似乎不是专门为解决一个问题设计的。相反，页面的设计来自设定好的多个模板之中（以页面布局组件的形式）。这些模板是相当通用的，但并不总是解决一个单一问题的最佳方案。

过度使用这样的模板可能会使页面看起来在视觉上一致，但会让用户感觉到没有重点和枯燥乏味。

刻板地遵循设计系统提供的模板，使得会出现让内容来适应页面布局，而不是内容主导布局。这使得浏览一个页面变得困难，需要用户花费大量的精力去弄清楚需要的内容在哪里，以及下一步该做什么。

我们还注意到，由于我们的 Layout 组件过于死板，导致团队经常脱离 Polaris 来做一些细微的布局调整，这就导致了代码层面工作量的增加。

我们已经明确了想要解决问题的，甚至已经有了行动的代号，但我们缺少最重要的部分——团队。

寻找团队

我们希望找到那些有兴趣与我们的团队合作改进 Layout 的团队，而且是热衷于发展 Polaris 设计系统的团队。幸运的是，公司里有很多这类型团队。

我们联系到了 7 个不同的团队，在了解到他们的问题空间和最近的工作排期后，我们决定与做 B2B 客户业务的团队合作，因为他们满足了所有条件：

1. 能够有效地解决问题 ✅
2. 该案例有可能对其他团队产生影响和启发 ✅
3. 能够在紧迫的截止日期前交付 ✅
4. 对开始工作超级兴奋 ✅

不久后我们明确了项目的目标，并开始了合作。我们设定的工作流程并不复杂：

第一步：了解问题

第二步：发散和探索

第三步：收拢和校准

第四步：重复第二步和第三步，直到满意为止

第五步：推进实现方案！

了解问题

通过一系列的 Workshop 及相关活动，我们对这个问题有了更好的了解。

我们首先要求团队做一个现状收集。简单地把一系列的截图和设计放在 FigJam 上，然后让我们去了解业务设计师当时遇到问题，以及他们做的解决方案。

我们都发现了这个 B2B 客户页面大多是聚合了企业客户有关的所有内容，但它在帮助商家快速了解这个特定客户方面做得并不出色。内容缺乏清晰的层次，所以最终效果不理想。

为了开始了解这个问题，并更好地了解页面里什么最重要。我们写下了这个页面里用户所有可能想要完成的工作。然后我们反复调整排序，以确定优先级和重要程度。这是我们最终得出的的结论：

1. 观察购买行为；
2. 手动为客户下订单；
3. 快速访问到地点和联系人；
4. 评估不同地点之间的销售情况；
5. 针对不同地区更改服务条款；
6. 查看操作日志。

通过小组讨论后，我们都认可了这个优先级排序。然后我们又尝试代入商家的身份去假设他们的目的，以确保我们目标一致，达成共识。然后投票选出了一个最接近目标的假设，那就是：

“如果显示的信息集中在一个页面上，商家将能够更方便地完成任务。我们可以通过完成一项特定任务所花费的时间来衡量。”

上述这些工作并不意味着产生实际的可交付的方案，而是让每个人都能够：

1. 更了解业务背景，让每个人都在对这个案例有相同的认识；
2. 开始对内容进行更细致的的优先级排序。因为我们不能仅通过移动元素来实现更有目的性的布局。我们需要从信息层开始，并在此基础上进行构建。

为了让大家更进一步，接下来是用草图来构思问题可能的解决方案。这里的目标不一定是找到解决方案，而是为今后的探索定下了基调。

我们鼓励每个人参与到 Workshop 的同事都尝试去画点草图，不管你是工程师还是设计师。有些人在 Figma 上画，但大多数人只是抓起一张纸和一支笔，一旦完成，就拍张照片，然后贴进 FigJam。

通过让同事们自由地画草图，不受设计工具或 Figma 组件库的限制，我们更有可能创造性地解决这个问题，而不一定要遵循预先存在的模板。

在画了一会儿草图后，每个人都分享了他们的想法，我们发现了一些有趣的事情。在画草图的时候，人们开始把客户在页面里可能想要完成的工作作为一个整体来考虑，而不是把注意力放在个别内容上，然后按照模板把它们组合在一起。

这是一个好的开始，因为商家会体验到整个页面，我们就应该这样去做设计。

在每个人分享之后，我们讨论并投票选出了最有希望的想法，这将是后续工作的基础。

发散和收拢

由于大部分探索是设计先行的，我们后续还通过几次包含一名产品经理和几名工程师的 Workshop 来协调和讨论。我们在会议前花了一些时间完善方案，拿到会议上讨论并一起看看有没有可以做得更好的地方。

Workshop 之后，设计师们根据讨论的结果继续细化方案。我们想跳出设计系统的界限，但最终解决方案必须符合 Polaris 风格，这是一个很难去达到平衡的事情。对于我们引入的任何新元素，我们必须再三斟酌，要了解它是否能融入 Shopify 里面，并且可以复用到其他团队里。

当我们探索信息的不同组织方式时，我们意识到拥有一个完善的 Grid 设计基础准则是相当重要的，它可以确保不同页面之间有一定程度的一致性，即使信息的组织方式不同。

我们不仅是把页面作为一个整体来看，为了建立层次结构，我们还必须深入去找到更好地利用颜色、空间和文字排版的方法。我们通过有策略地运用颜色，突破字体规范探索更大的字号，来给最重要的元素增加了视觉权重。使它们与其他元素形成鲜明对比，并吸引人们的眼球。

我们还减少了页面中卡片的数量，更多地依靠空间来分组和分离信息。

随着我们的方案逐渐成熟，我们开始与产品和研发部门讨论方案。最终我们经过讨论和方案对齐后，找到了一个多方都认可的解决方案。

通过重新设计，我们使商家能够更轻易地快速了解一个 B2B 客户。

与其简单的在网页上堆砌信息，指望着商家费尽力气去获取想要的信息，我们干脆重新梳理了一遍网页的内容。我们强调重要的信息，弱化只需要低频获取的信息。最终，让获取重要的事情变得简单，同时保留获取其他所有信息的触点。

作出妥协

然而方案的推进并没有那么美好。我在开始时提到过 Deadline 迫在眉睫，我们只能将解决方案分步交付。

在推行某个方案时，很少有不需要做出一些妥协的，特别是当 Deadline 很紧迫时。这是产品开发过程中很常见的现象，但这并不意味着要在设计质量上做出妥协。

而为了能够做到这一点，你需要了解技术的限制是什么及其原因。

这正是 B2B 团队所做的。例如，在页面中引入新的数据指标和数据洞察是很难的，但他们没有放弃这个想法，而是争取引入任何可以实现的东西，因为他们知道这对商家来说是非常有用的，可以在未来迭代和改进它。

创建可扩展的解决方案

与此同时，我们已经开始在 Polaris 团队中探索新的 Layout 设计准则。在整个协作过程中，我们了解到我们的原本布局组件限制太多，所以我们构建了一个 Grid 布局组件，让我们更容易地构建自定义布局，同时不会脱离设计系统。

团队想要创新，但设计时需要有一定的规则来约束，有时候甚至要依据设计系统已提供的模板。

这次合作让我看到，我们并不缺乏创新的动力和能力，缺乏的是一个目标。当你不知道该做成什么样子时，通常都会呆在舒适圈内，这是会让人上瘾的。

让系统团队积极探索新方式和与他们合作，能够得到新的做法。但这只是一次性的，不可扩展的。所以我们需要找到方法将这种做法纳入到设计系统中，让其他业务和团队的设计师也能复用。

Grid 布局组件是处理「设计创新」和「遵循规范」之间平衡的的一个很好的例子 — — 能够让设计师在 Polaris 内创新。

从技术上讲，团队可以不用 Polaris 来实现任何东西，但这导致了不一致性、不规范的体验设计和许多冗余的代码。这使系统更难维护、更新和扩展。

Polaris 是一个工具。我们利用它来发挥我们的优势，但我们不能忘记维护和发展它。就好比如果一把刀变钝了，你不需要去买一把新的，而是要把它磨利。

这次合作很有趣，同时也很有影响力。因为我们在产品和系统上做了改进。

我们不仅一起发布了一个新的布局，而且我们还确立了从整体上改进设计系统的方法。看到这项工作被刊登在 Shopify Editions 上是特别荣幸的。我真想快点看到 B2B 业务实现完整的设计方案之后的效果，以及其他团队使用我们建立的 Grid 布局组件。

如何开始？

如果像 B2B 团队一样，你想推动你的设计系统向前发展，我可以推荐两种方法中的一种。

选项 A：与设计系统团队合作

如果你正在研究一个问题，希望能突破原有的界限，并看到影响整个产品的设计模式的可能性，请考虑与你的设计系统团队联系。

设计系统团队会想要极力避免出现单一的解决方案，但他们很可能倾向于如何让设计系统更好用。特别是这件事对整个公司内的其他团队有可能存在的好处时。

为了证明这一点，我可以告诉你，我已经与另一个团队合作去解决另一个问题。我希望像这样的合作越来越多，因为这种合作确实能给产品和团队带来很多好处。

可惜的是，我知道一个设计团队未必能和所有人合作。但这不应该阻止你创新，还有另一种方法…

选项 B：动员你的团队

其实在与产品团队合作时，我们设计系统团队的主要工作是启发和支持。

这也是我分享这个研究案例的原因。向你展示我们做了什么，我们是如何做的，以及为什么这样做。希望这能启发你，同时也给出了一些可以复用的方法。

要记住的关键一点是，在孤岛上创新真的很难，所以寻找与你有同样热情的合作伙伴。如果你需要快速尝试，不妨用我创建的模板去实际尝试一下前文描述到的 Workshop。

当你完成后，别忘了为设计系统「赋能」噢！