惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

W
WeLiveSecurity
博客园 - 【当耐特】
Microsoft Azure Blog
Microsoft Azure Blog
WordPress大学
WordPress大学
Stack Overflow Blog
Stack Overflow Blog
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
IT之家
IT之家
Cloudbric
Cloudbric
The Register - Security
The Register - Security
小众软件
小众软件
PCI Perspectives
PCI Perspectives
G
Google Developers Blog
AI
AI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Google DeepMind News
Google DeepMind News
Google DeepMind News
Google DeepMind News
宝玉的分享
宝玉的分享
Recent Commits to openclaw:main
Recent Commits to openclaw:main
量子位
TaoSecurity Blog
TaoSecurity Blog
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
F
Full Disclosure
N
Netflix TechBlog - Medium
博客园_首页
Last Week in AI
Last Week in AI
A
Arctic Wolf
B
Blog RSS Feed
J
Java Code Geeks
C
Cybersecurity and Infrastructure Security Agency CISA
I
InfoQ
aimingoo的专栏
aimingoo的专栏
云风的 BLOG
云风的 BLOG
NISL@THU
NISL@THU
MyScale Blog
MyScale Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Jina AI
Jina AI
有赞技术团队
有赞技术团队
S
Schneier on Security
L
Lohrmann on Cybersecurity
P
Privacy & Cybersecurity Law Blog
T
Threat Research - Cisco Blogs
P
Palo Alto Networks Blog
S
Security @ Cisco Blogs
Security Archives - TechRepublic
Security Archives - TechRepublic
Security Latest
Security Latest
Vercel News
Vercel News
博客园 - 司徒正美
Webroot Blog
Webroot Blog
Hacker News: Ask HN
Hacker News: Ask HN
A
About on SuperTechFans

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
庞杂中建立秩序 | 设计系统的优化升级
百度MEUX · 2023-10-14 · via 人人都是产品经理

设计系统的建设者如果想有效地规划设计资产,提升组件的应用率,可以怎么做?这篇文章里,作者结合实际案例,分享了建设成熟的设计系统的经验策略,即“通过场景演绎的方法重构资产,为其建立秩序,提升内在一致性”。一起来看看,或许会对你有所启发。

前言

伴随行业发展,越来越多企业在复杂业务场景中引入设计系统,对于建设一套成熟的设计系统,需要考虑三大模块:生产、消费、监测。本文结合百度搜索设计系统近期针对【生产和消费】环节的升级改版,分享其中的经验总结,即:通过场景化重构资产,为其建立秩序,提升内在一致性,并提升资产消费体验。

文中介绍的方法,不仅可以帮助设计系统的建设者有效规划设计资产,同时可帮助业务设计师在日常项目中对组件高效应用和合理创新。

一、项目背景

百度搜索在移动时代到来初期,通过划分垂类团队,深耕垂类特性,以极致体验满足不同垂类下用户对内容精细化消费的诉求。这一阶段设计资产的特点为:

  1. 组件资产与业务强绑定,业务独立维护。
  2. 业务创新频繁,组件样式新增多、合并少。
  3. 设计系统内在逻辑不健全,主要为各业务组件的快速录入封装。

这种设计系统建设方式是一种样式归纳性思维:通过在初期快速归纳收集,满足业务高速发展的需要。

但伴随业务发展成熟,各垂类团队横向协作愈加频繁,对组件复用提效与保持产品体验一致性的诉求越发明显,这种建设思维便会暴露出它的劣势。

  • 资产通用性不足,体验难打平:业务各自维护资产,横向场景兼顾不全面,资产横向复用的标准不明确,体验差异难抹除。
  • 资产冗余且庞大,维护成本高:设计系统中存在很多样式略有不同,体验又无差异的组件,在业务升级和设计改版时成本高且容易出现遗漏。
  • 资产缺乏逻辑性,约束性不足:资产与设计意图的映射关系模糊,在相似的用户需求和场景设计中,给设计师的设计指导力度不足。

而这些最终的结果会导致设计系统越来越不规范,易用性大大降低,不匹配业务成熟期的诉求。

因此在设计系统建设上,需要更高效的建设逻辑,以提高资产的易维护性与可拓展性,保证在业务成熟期可以更高效赋能团队协作,增强产品体验一致性。

二、项目方案

1. 明确目标

基于百度搜索设计系统现状,其核心问题是资产规范性不足,而资产主要由“组件”和“规范”两部分组成,设计师和工程师通过调用组件或阅读规范,实现对设计系统的消费。因此我们理解一个业务级的设计系统,能够赋能业务的方式需满足:

  1. 具有完备的设计资产:规范定义明确,组件变体健全。
  2. 提供高效的消费体验:消费途径丰富,消费路径简短。
  3. 具有良性的迭代模型:中台与业务同频,业务组件优化可实现资产的沉淀回流。

其中能够实现业务赋能最大化的前提,是有完备的资产作为基础。因此将设计系统的迭代发展,划分了三个阶段:

  1. 统一化:夯实基础,重构设计资产底层建设逻辑,明确资产适用场景,提升可拓展性与易维护性。
  2. 工程化:整合资产代码,提升资产消费效率,并在设计中台与业务之间建立资产迭代的良性循环。
  3. 工具化:探索设计系统工具化的形态,及AI大模型结合的机会,丰富消费途径,实现在业务交付的不同阶段下全方位提效。

那么在“统一化”阶段,我们给出了目标:提升资产的规范性与易用性。

2. 目标拆解

面对设计交付链路上,遇到诸多杂乱的问题,应当如何去给出合理的解决方案呢?

首先可以基于现状,从“资产生产 → 资产消费” 的链路出发对目标进行拆解。

三、设计动作

1. 重构底层逻辑,转变视角

先来看一个设计系统工作中常遇到的问题,以下几个组件从样式上非常接近,那么在组件归类上是否应该归为同一个组件呢?

那以下两个组件从形态上差异明显,那他们又是否为一个组件呢?

1)过往:样式归纳思维

在回答上面的两个问题之前,不妨先来看看如果按之前的“样式归纳”的视角进行分析,在资产建设中会发生什么?

我们发现样式归纳性思维,是通过对已知的组件资产,进行共性和差异性罗列,然后求同存异,将共性较多的设计稿归纳为某一类组件;并分别定义其组件能力和使用场景。

这种建设方式可以在上图直观感受到,在初期的确可以帮助业务线快速建设出设计系统,实现单一业务内的复用,但当各业务均发展成熟时,这种设计系统却无法满足跨业务复用的情况,且缺乏内在逻辑的归纳思维,也无法对持续发散的业务创新形成有效收拢,这时便需要我们转变视角。

2)转变:场景化演绎思维

在业务变化快的情况下,归纳性思维的核心缺陷在于资产源头不稳固。因此需探索一种源头相对稳定的设计发起点,这可以通过追溯用户行为进行解决。

人类发展至今,环境和媒介不断变化,但是人类可实施的行为动作并没有太多变化。同时在日常产出时,我们的设计意图基本是围绕如何让用户在某场景下用某种行为达成目标来开展的,之后这些产出物又被封装为可复用的组件。由此可以倒推,将组件的本质抽炼为:帮助用户在特定行为场景下,通过某个组件,以某种方式,达成目的。

而组件交互与样式的变化,底层所承载的设计意图都是为了在这个特定的场景下,优化用户的行为,提升场景体验。

这里所提到的行为场景,可帮助我们跳脱出业务场景,将设计资产剥离业务影响因素,回归到简单直接的行为动作之中。

当了解组件的本质,便可以将复杂多样的组件,映射到自己产品、业务线的几个宏观用户行为场景之中,再以此“场景”为基础,层层延展,从“更好的达成用户目标” 出发来演绎不同组件的变体。

我们可以试试以这种思维去重新思考本章节开头提出的两个问题:

很清楚的理解,这些不同业务中的组件,是为了服务于用户的哪一种行为场景,而他们从样式上来说是否相似,仅仅是服务于业务场景的表现形式。由此便可以将各类资产划分到不同的组件类型中,并得到MVP版的设计资产及其延伸变体。

这种“场景演绎”的视角是一种根本思维,由内向外发散,通过本质推导组件可以满足用户什么场景的诉求。这种场景视角,可帮我们在建设设计系统时,提升通用性,降低维护成本。

2. 演绎推理变体,建立秩序

在上一小节,讲解了什么是场景演绎思维,那么在实际工作中,还会思考两个问题:

  1. 应当依照何种原则和方法去推理变体?
  2. 每一个组件理论上可以衍生各种变体,那么在构建设计系统时,应当满足到何种程度?

1)推理变体的方法

如上文讲到,我们拆解行为场景的目标,是为了满足子场景下更好的体验,建设合理的组件变体。此处以Tab组件的部分场景拆解为例,通过三步,来讲解组件场景演绎的方法。

第一步:先明确最基础的行为场景,以及达成目标的最基础方式;例如当了解Tab组件的本质是为了帮助用户达成“切换内容”的场景目标时,就可以通过细化主行为场景,演绎在各细分场景下,如何以更好的体验优化用户的行为,从而得到相应的变体。

第二步:演绎变体,衍生行为场景,优化达成方式;可以从对象、空间、时间等维度分别去细化行为发生的场景,然后从提操作体验、提认知体验、提情感化体验等维度去优化达成方式。

第三步:获得变体与适用场景,秩序建立:通过这样的场景拆解与演绎,一个完整的组件便建立完成,对每一种变体的适用场景,也有了清晰的认知。由此可以通过抽象业务场景的特征,然后给各业务开发者与设计师,提供合理的使用建议。

同时,以这种演绎的方式建设组件后,每一类组件的能力定位更加明确,资产的建设会变得更加精简,不易冗余。而我们对每类组件在搜索场域下可具备的能力与发展方向,也可以有一个脉络清晰的预判。

不同的组件在场景拆解的维度上也会有所差异,但维度上需秉持从宽泛到具体、从广义到具象的层层递进式拆解,拆解越详细,所得变体也会越全面。

当我们将所有设计资产中,都按这种方式进行重构归类后,便可以得到一张有秩序有建议的设计系统全局场景演绎规划图。它可帮助清晰地预判设计系统的缺失,从而更好地规划设计工作。

由以上方式可获得任何一个资产的建设发展图,那么关于此资产在当前阶段需要满足到哪种程度,则可以从业务需要与建设成本去综合考虑,从而保持设计系统在不同阶段,都可以资源利用最大化。

3. 贴合消费场景,提升易用

在重构资产的同时,也需要考虑消费场景的易用性,而规范文档是现阶段消费资产的主要方式之一。因此也对文档的内容做了优化整合,并为设计系统后续内容工程化打下基础。

第一步:资产层级扁平化;将组件从行为场景上,按更细的颗粒度进行分组呈现,同时建立目录导览页,平铺所有组件的跳转链接,以更加扁平的姿态提升组件触达效率。

第二步:文档结构统一化;考虑之前的文档由不同设计师撰写,在撰写习惯与表达用语上有所差异,会增加开发者阅读时的理解成本。因此我们将组件文档结构与话术进行了统一,将组件按变体类型,进行统一分类,再分别讲解其对应的交互与样式参数,从而进一步提升消费时组件变体的触达效率,以及减少不相关信息的干扰。

第三步:内容场景化;将文档按组件变体分类完成后,同时在文档开篇,以及每个变体下,建议了适用场景,以提升开发者的使用准确率

四、项目结果

在今年上半年,通过转变设计思维,运用本文行为场景演绎的方式,使设计系统变得:

  1. 每类设计资产边界清晰、适用场景明确,重复冗余概率低。
  2. 设计系统内在逻辑统一,易维护,具备可拓展性与易规划性。
  3. 设计系统可变得更加具有确定性,减少业务的动态易变所带来的影响。
  4. 保证服务的产品的体验一致性,降低用户使用成本。

同时通过优化消费场景,帮助开发者更易理解,提高资产生成与资产消费的匹配程度。从整体度量效果上来看,组件变体的在保证可覆盖历史场景的情况下,实现了精简化;通过演绎变体,优化文档结构,也提升了开发者对于设计系统消费的整体满意度以及对规范合理性的感知。

另外为提升设计系统对业务的实用性和可用性,我们配合多次的团队宣贯,帮助开发者建立共识,保证后续协作效率。

五、实践方法总结

本文着重介绍的场景演绎方法本质是一种场景化的设计思维,其核心在于抽象场景特征,通过抽象的场景特征实现设计资产与业务场景之间的关联匹配。

其中对于资产建设者而言,是正向通过拆解行为场景获得场景特征,从而更好匹配业务场景;而对于资产消费者,是逆向通过提炼业务场景,进而匹配行为场景,发现资产变体的不足,从而完善设计系统。

由此可见这种方法,不仅适用于系统级组件级的推演,也可以用于日常业务需求的创新与业务组件提炼中。

由于每个组件的本质是服务于单一的行为场景,因此在日常需求中,需要设计师先对用户流程进行梳理。

在需求的若干个业务场景中,对每一个业务场景,做最优的行为路径设计,再通过提炼每个行为路径下,涉及到的行为场景及其场景特征,去匹配现有设计资产:

  1. 如改版需求,可以判断已应用的组件变体是否很好的帮助用户达成了目标,从而依托业务场景思考更适用的组件变体。
  2. 如新需求,可以判断现有的场景特征,是否可以匹配已有的设计资产,以及已有的设计资产是否可以被进一步优化。

六、设计系统后续展望

本文分享了如何通过【场景演绎】的方法重构资产,为其建立秩序,提升内在一致性;当然从整个设计系统的长期建设层面来看,当前对资产的系统化重构与文档结构化的建设只是开始,绝非终点,在真实的协作流程中仍然会面临两大问题:

1. 设计中台与业务沉淀如何保持同频

业务设计师在真正的资产消费链路中往往具有很强业务诉求,需要对部分资产基于业务进行定制,甚至需要建立独立品牌风格。这些不可避免的会导致业务设计师需要独立维护一套子级设计资产,同时下游的前端也需要基于业务对资产进行二次开发。

这容易导致业务场景的变更无法及时同步设计中台;同时通用资产的迭代更新也无法快速覆盖到业务场景中,导致对业务赋能效果打折扣,这些长期而言不利于设计系统健康迭代。

2. 原有资产消费路径不便捷

虽然在本次升级中优化了规范文档的阅读体验,但其实它仅仅是整个资产消费链路中的一小部分。整体看设计师仍然需要在规范文档、Sketch组件UIkit与需求设计稿之前反复横跳切换;同时在交付过程中,也无法将设计资产同前端开发者建立共同语言的链接,从而不利于设计系统对业务落地的深度提效。

要解决这两个问题,需要推动设计系统工程化、提升资产消费链路灵活性,这其中的关键则是:

  1. 在上游建立中台与业务之间同源可扩展的Design Token。
  2. 在下游提供可串联设计与研发资产消费的工具分发平台,及提升协作沟通效率的信息中转站。

近期已经按照以上思路开始了“设计系统工程化与工具化”的升级改造,这部分内容后续有机会也会和大家见面分享。

作者:MEUX

原文标题:百度搜索设计系统丨庞杂中建立秩序

来源公众号:百度MEUX(ID:baidumeux),百度移动生态用户体验设计中心,负责百度移动生态体系的用户/商业产品的全链路体验设计。

本文由人人都是产品经理合作媒体 @百度MEUX 授权发布,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。