系统设计
系统性地思考而非片段式的优化
2018.08.17
工作时总结了一些东西,记录下来分享给大家。

为什么需要系统设计
系统设计在很多公司和团队里都仅仅被当成一个次重要的项目,甚至还有很多设计师并不理解什么是系统设计,为什么要花时间来做这件有些枯燥的事。他们更倾向于做“创意方案“,急着发布产品,一切都希望等产品上线后的数据来”优化“。快速发布产品并通过收集数据进行优化并没有错,只是这种方式的功效在近些年被逐渐放大,成为了产品质量和服务被质疑时的一个经典借口。市场很残酷,用户更残酷,如果一个产品的前期设计很糟糕,挑剔的用户可能会立刻卸载,这样也就收集不到什么后期数据,只能默默等产品死掉了。
前期就建立起考究实用的设计语言是很必要的,系统性的设计会赋予产品未来快速成长的能力,帮助我们管理从四面八方来的嘈杂需求,保证体验的统一性,进而辅助产品成功。系统设计的好处在产品线较多的公司里最容易体现出来,因为多产品线意味着多应用、多设备、多屏幕尺寸、多品牌甚至多设计师,如何从重复的工作里节约时间提升团队效率进而提升公司效率,必须依赖系统设计。例如我当前所在的设计团队人数就超过了50,如何管理50多个设计师来最终拿到“一个产品”,这本身就是一个难题。设计师的想象力和创造力都很丰富,加上团队会有一定的成员流动,如果不去设定界限,每个人都有自己独特的设计风格和想法,设计就乱了套。况且产品的整体设计过程中并不只有设计师,还有很多其他人员和因素在影响,像是客户、老板、市场运营、产品经理、项目排期、开发、测试…… 每个人都会从自己的立场出发,对产品设计进行要求,提供见解,不同的声音杂乱地拼凑在一起,如果不好好管理,只会产出一个四不像。
数字型产品的特性也决定它的设计过程更需要系统性考量,和实体产品不同,代码会不断进化,软件是需要长期维护的。从开始就做好架构,会为后期维护节省大量时间。而且数字型产品设计限制较少,一个问题可以有许多种不同的解决方案,解决方案的过度多样性会带来体验的不统一。

如何做系统设计
了解系统设计的重要性后,决定要去做了,那如何开始呢?召集团队里最强的几个设计师关起门来大干一场?错了,系统设计是一个比较具体的项目,做项目需要打通链路、统计资源、安排时间。
打通链路指的是什么?系统设计并不是单纯的设计项目,它需要全公司的支持。因为很多系统设计是在已有产品后才开始,这就意味着你整理的这套设计语言是在给所有人增加工作量。大家除了日常工作,还要实现这套新的设计,光是项目经理拉排期就够好好思考一阵子:什么时间有哪些人可以加入这个项目,新的版本什么时候发布,从哪些产品线开始做起,到什么时间前要达到什么样的一个程度才能保证某个时间点整套设计语言可以落地,怎么做对外宣传…… 而且并非每个人都会理解你所做的这件事带来的好处,公司内有形形色色的人,有人还会觉得麻烦去反对你。如果反对的声音仅来自设计团队,而你又刚好是团队负责人,那还好,但如果是开发团队或者公司上层并不愿意支持你,这件事情就会做的很累或者无从开始。你要打通链路,找到支持你想法的人,最好是开发的负责人,这样你们可以一起总结系统设计会为公司带来的好处汇报给高层来争取资源配合。所以说在中大型公司工作最大的挑战就是如何改掉单枪匹马的工作方式,学会协作和沟通。没有什么项目是一个人完成的,产品的创造过程中必然会有开发人员来和设计师配合,市场和产品给出要求和输入,测试人员给出反馈,资源和时间不够时还会有其他资源调配支持…… 除了专业能力外,沟通最为重要。良好的沟通会提升你的工作效率,也为你带来更多的资源,一个能清楚解释设计原因的设计师显然比一个说不出话来的设计师感觉更靠得住,更能快速说服执行团队。
得到了公司高层的支持后,资源和排期的安排都相对轻松。这个时候就可以开始思考设计原则了,因产品功能不同设计原则也会不同。像我现在设计车载产品,首要的就是安全、清晰,说白了就是字要大,界面元素要好找,别让用户开着车想听个音乐半天却都找不到播放图标,想看歌名半天也看不清,语音交互要做好,硬按键操作要灵活,界面反馈要明显。
确定了大的设计原则后,下一步是罗列工作内容的范围目录,进到具体的设计里。在这不多说怎么定目录了,因为每个团队需要的范围不同,可以通过参考市面上的设计系统还有内部会议讨论得来。当时我用来参考的设计系统罗列给大家:
Apple Design Guidelines:https://developer.apple.com/design/
Atlassian Design:https://atlassian.design
U.S. Web Design: https://standards.usa.gov
VMWare Clarity Design: https://vmware.github.io/clarity/​​​​​​​

整个系统设计中最为“实在”量也最大的一块就是控件设计。当时我们是先把系统里的全部页面都收集起来并打印出来,去统计有多少个控件在使用。统计完成后再根据设计原则和实际使用场景做减法,删除多余的控件,重设计相关页面,对剩下的控件进行细节定义。要重视重新设计相关页面的这个步骤,因为你面对的可能是某个执拗的设计师,他/她作为这个页面的原始设计者会对你的决定提出很多质疑,如何说服对方来保持设计原则的统一是需要沟通技巧的。控件的细节定义主要包含该控件的基础交互行为、界面位置、搭配使用方式、类型、视觉样式、动效,这些可以参考市面上的设计原则,也可以适当添加些独特的东西,例如我会明确标明客户可定制化的范围,谨防因太过随意而引起设计惨案。
在做项目的时候要记得,设计是要服务于人的,系统设计也是,除了服务于产品外,它也服务于公司内部的设计师、开发人员、产品人员、外部客户…… 产出物要考虑到每个人的需求点。系统设计实质是在设计一门语言,语言有着复杂的学习成本,如果设计的不清楚,学习成本大,项目就算做完了,也是失败的。必须要明晰易懂,在控件设计上做精简,在语气文案上做提炼。
文案也是系统设计中的重要一项。你可能读了很多文章看到这个新词 “UX Writing”被反复提起,其实每个设计团队都应该配有自己专门的文案人员,但目前大多数国内团队里文字这件事是由市场或者设计师自己负责的。内容是剥去视觉界面后,用户最有感触的部分。恰当地通过文字来对用户进行激励和警示,是体验设计的重要一环,你做的系统设计里至少要定义出基础原则、语气语调、内容写作架构、单位用法、多语言规则和特殊场景。如果再做大一点,就是内容策略,包含品牌定位、发布渠道安排、搜索引擎优化…… 这个时候文案已经不够了,需要雇Content Strategist。
这些大的原则都定义完成后,就会进入下一步:视觉、动效、声音的原则定义和设计,并输出相关的资源库。这三项的困难程度是视觉 < 动效 < 音效,视觉的难点在于设计质感;动效的难点在于如何不炫技;声音的难点在于好的声音设计师非常少。如果你的产品不是游戏或者车载产品,声音可以暂且放放,因为场景会相对简单。
这三块一般都有专门的设计师,你作为系统设计的负责人更多地是和他们协作来保证整体性和原则性。找一个专门的会议室坐在一起工作,快速碰头新的进展,也别忘记保持一定频率的开发沟通,所有的控件最后都是代码,要充分明确开发界限,避免无法落实的情况。
设计完成进入开发时,就可以开始梳理设计库了, 建库软件的使用就取决于你们的方便了,Sketch或者Adobe。最好是直接和开发一起把库代码化拿出来使用,随改随新。同时要建一个网站或者使用公司内部Wiki,把整套设计语言放到上面,确保全公司都能看到。记得多开几次分享会,让更多的人了解系统设计,把过程中的困难和段子给大家也讲讲,提升下设计部在你们公司的专业感观。还能收集其他人对的反馈,以备后续的长期维护和升级。

总结
上面主要讲做系统设计时的过程和经验,并没有针对某一个设计项深入展开,像是怎么做视觉语言,一个是因为展开的话要写太多字,另一个是因为想到大家肯定读过视觉动效教学文章也腻了。怎么实际在公司内部做一套设计语言的经验分享应该不多,国内团队真正自成体系的设计语言看来看去也就是Ant Design,大多数说起系统设计的文章和知乎回答也是多给出关联链接的方式,左手甩你一本《Atomic Design》,右手丢你两个设计规范链接,然后聊起了美感与妥协,或者会更多关注在如何建立视觉规范和Sketch库上,讲实操的不多,完全不说立项时的痛苦和在推进落地时碰到的困难。系统设计的项目,比起设计上的难点,更多的是沟通和推进落地的不易。前期的基础建立和后期的维护节奏很重要,因此想做系统设计需要一个非常稳定的团队,关键人员不可以频繁更换,主设计这个角色更是异常重要。设计语言体现了一个团队乃至一家公司的专业性,系统性地思考而非片段式的优化,还有很多事可学,很多事可做。