Be For Web - Design System http://www.beforweb.com/taxonomy/term/235 en 组件库物语 - Sketch Hack 之浮动居中 http://www.beforweb.com/node/1006 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/logo-icon-sketch-wireframekit-beforweb.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>要到圣诞了。买了一套巴赫的圣诞清唱剧黑胶套装送给自己做礼物,希望可以快些拿到。说起来真想试试直播呢,譬如就让唱片或老磁带在那边旋转发声。</p> <p>我说吧,2018真的就剩下这么几天了;近来看到有朋友认真地写了年度总结,突然发现自己竟然完全没有心情做复盘,很是惭愧。超戏剧性的一年,有坑有雷,也有着近在咫尺可期许的理想;有丰盛的产出,也有空洞的日夜;岂能不做总结呢。看心情吧。</p> <!--break--><p><img alt="" src="/sites/default/files/images/201812/IMG_1135.jpg" style="width: 450px; height: 450px;" /></p> <p class="figure-caption">漫咖啡也喜气洋洋了起来</p> <p>说正事儿呢。继续组件库物语,对之前<a href="http://beforweb.com/node/1003" target="_blank">新上架的社交类 Sketch 组件库&ldquo;Social&rdquo;</a>进行复盘。在之前的两篇当中,我们聊到了:</p> <ul> <li> <a href="http://beforweb.com/node/1004" target="_blank">定义目标,以小为始</a>:关于早期规划、目标分析,以及&ldquo;自下而上&rdquo;的起步技巧。</li> <li> <a href="http://beforweb.com/node/1005" target="_blank">通用性与易用性的权衡</a>:如何在组件的复杂度与易用性之间寻求平衡。</li> </ul> <p>今天聊一点有意思的细节实现技巧吧。这个小 hack 我个人常会用到,最初获取于 Medium 上的一些相关讨论(近两年来也在随着 Sketch 的升级而迭代,最新的链接附于文末)。</p> <h3> 关于浮动居中</h3> <p>我们都知道,将多个元素排列成单行,打包 Symbol 之后,位于文本右侧的元素会随着文本实际长度的变化而自动移位(实测元素间距在20px之内时,此机制有效),如下图所示:</p> <p><img alt="" src="/sites/default/files/images/201812/text.png" style="width: 600px; height: 185px;" /></p> <p>这是很有用的机制,可以有效提升 Symbol 的灵活性。而在实际当中,我们时常要解决另一类需求,即&ldquo;图形在左,文本在右,整体自动居中&rdquo;,例如包含图标与文本的按钮,或是包含头像与用户名的导航栏等等。以 WireframeKit &ldquo;Social&rdquo;当中的元素为例:</p> <p><img alt="" src="/sites/default/files/images/201812/button.png" style="width: 200px; height: 40px;" /></p> <p class="figure-caption">&ldquo;关注&rdquo;按钮</p> <p><img alt="" src="/sites/default/files/images/201812/navbar.png" style="width: 375px; height: 88px;" /></p> <p class="figure-caption">用户信息导航栏</p> <p>对于这类文本元素位于右侧的情况,Sketch 原本的浮动机制无法直接实现图形元素随着文本长度的变化自动移位。这时,我们需要在原本机制的基础之上运用一点 hack,才能确保内容整体在文本变化之后仍能自动保持浮动居中:</p> <p><img alt="" src="/sites/default/files/images/201812/buttonL.png" style="width: 200px; height: 40px;" /></p> <p><img alt="" src="/sites/default/files/images/201812/navbarL.png" style="width: 375px; height: 88px;" /></p> <p>Hack 的本质,是对于工具原生能力的运用技巧,而无需借助任何第三方插件。</p> <h3> 如何实现</h3> <p>我们以按钮为例进行演示。</p> <p><strong>1. </strong>创建按钮,包括背景形状、文本及图标。此时先将图标置于文本右侧:</p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_22_52.png" style="width: 230px; height: 79px;" /></p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_26_46.png" /></p> <p>确保将文本元素的对齐模式(Alignment)设置为&ldquo;Auto&rdquo;和&ldquo;Centered&rdquo;:</p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_31_43.png" style="width: 543px; height: 146px;" /></p> <p><strong>2. </strong>将图标与文本结组(Group),并在右侧面板中将该组整体的旋转角度设置为180&deg;:</p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_28_57.png" style="width: 342px; height: 90px;" /></p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_33_25.png" style="width: 541px; height: 134px;" /></p> <p class="figure-caption">倒过来了哦</p> <p>3. 再分别将图标与文本的旋转角度各自设置为180&deg;;此时外观已经符合我们的需求:</p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_34_24.png" style="width: 545px; height: 130px;" /></p> <p>4. 按照下列规则,分别对内容组、文本及图标的 Resizing 模式进行设置:</p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_38_10.png" style="width: 524px; height: 99px;" /></p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_39_47.png" style="width: 530px; height: 168px;" /></p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_40_43.png" style="width: 537px; height: 170px;" /></p> <p><strong>5. </strong>将内容组(&ldquo;Label With Icon&rdquo;)打包为 Symbol,将其横向拉伸至与按钮同宽,并将其 Resizing 模式按照下图所示进行设置:</p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_44_05.png" style="width: 342px; height: 90px;" /></p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_47_18.png" style="width: 600px; height: 146px;" /></p> <p><strong>6. </strong>将按钮整体打包为 Symbol:</p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_48_30.png" style="width: 463px; height: 162px;" /></p> <p>搞定。尝试不同的文本长度看看:</p> <p><img alt="" src="/sites/default/files/images/201812/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-12-20%20%E4%B8%8B%E5%8D%8811_50_00.png" style="width: 469px; height: 406px;" /></p> <p>大致这样,希望可以在实战中帮到你。用途很多,譬如按钮、标签、用户信息、文本框占位符等等都可能用到。</p> <p>Medium 参考:<a href="https://medium.com/sketch-app-sources/sketch-hacks-make-a-resizable-button-with-icon-label-totally-native-edition-6a1ff5b48e0e">Sketch hacks: Make a Resizable button with Icon &amp; Label, totally native edition</a></p> <p>还没有使用过 WireframeKit &ldquo;Social&rdquo;的朋友不妨稍作了解:</p> <h4> WireframeKit 获取方式</h4> <p>WireframeKit for Sketch 是付费组件库系列,目前仅在 Beforweb 微店提供:</p> <ul> <li> <strong>Social</strong>:129元 ,附赠:</p> <p>&nbsp;</p> <p>&nbsp;</p> <ul> <li> C7210版《设计体系》全书译文(PDF)。</li> <li> Sketch 常用中文数据源。</li> </ul> </li> <li> <strong>iOS 12</strong>:99元</li> <li> <strong>Social + iOS 12 超值套装</strong>:仅需199元</li> </ul> <p>请通过以下小程序码访问微店获取(系统通常随机附送1至88元不等的红包)。付费后,你将得到下载链接及密码。</p> <p><img alt="" src="/sites/default/files/images/201808/WechatIMG57.jpeg" style="width: 300px; height: 300px;border:none;" /></p> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/38" typeof="skos:Concept" property="rdfs:label skos:prefLabel">线框原型</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/164" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Sketch</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/227" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Sketch组件库</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/226" typeof="skos:Concept" property="rdfs:label skos:prefLabel">WireframeKit</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/234" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计体系</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/235" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Design System</a></li></ul> Fri, 21 Dec 2018 12:29:06 +0000 C7210 1006 at http://www.beforweb.com http://www.beforweb.com/node/1006#comments 组件库物语 - 通用性与易用性的权衡 http://www.beforweb.com/node/1005 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/logo-icon-sketch-wireframekit-beforweb.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>周日晚间,&ldquo;猎户星座&rdquo;,全家便利店的美式咖啡,酝酿着困倦与新一周的未知,初冬的天气却毫不冷静。&ldquo;有时你乘起风,有时你沉没,有时午夜有彩虹&rdquo;。</p> <p>一周前上架了新的 Sketch 组件库,也就是聚焦于社交类产品设计需求的 WireframeKit &ldquo;Social&rdquo;,同时也开始以这样的形式进行总结,包括思路、原则、工作方法、细节技巧等等;复盘于己,分享于人。</p> <!--break--><p><a href="http://beforweb.com/node/1003" target="_blank"><img alt="" src="/sites/default/files/images/201811/%E5%85%AC%E4%BC%97%E5%8F%B7%E4%B8%8E%E5%A4%B4%E6%9D%A1.png" style="width: 600px; height: 338px;" /></a></p> <p class="figure-caption">&ldquo;Social&rdquo;库附赠《设计体系》全书译文,<a href="http://beforweb.com/node/1003" target="_blank">了解详情</a> &rsaquo;</p> <p>在上一篇&ldquo;<a href="http://beforweb.com/node/1004" target="_blank">组件库物语 - 定义目标,以小为始</a>&rdquo;当中,我简单介绍了&ldquo;Social&rdquo;库的项目启动过程,包括早期规划、目标分析,以及&ldquo;自下而上&rdquo;的起步技巧等等;今天来聊一些细节实现当中的权衡问题。我个人在每一次的库相关项目中总会遇到类似的问题,相信对各位来说也不会太陌生。</p> <h3> 通用性与易用性的权衡</h3> <p>先对这两个概念进行定义,避免含义宽泛造成误解。在本文范围中:</p> <ul> <li> <strong>通用性</strong>:指组件库提供的元素(图标、按钮、组件、模块等)对于设计需求的适应能力,即能否以较少的元素实现较为多样的产出形式。</li> <li> <strong>易用性</strong>:指组件库对于使用者的友好程度,即能否帮助设计师以较少的认知与操作成本来调用和定制组件。</li> </ul> <p>具体到 Sketch 的实践层面,我们通常会将若干元素打包为 Symbol,构成一个可供复用的组件。其中,&ldquo;通用性&rdquo;与&ldquo;易用性&rdquo;体现在:</p> <ul> <li> Symbol 内部元素的可控性越低,其用途就越单一,对于使用者来说也更易于认知和记忆。但要满足复杂的设计需求,所需 Symbols 的数量就更大,整体架构的复杂度更高,库的制作和维护成本也更高。</li> <li> Symbol 内部元素的可控性越高,其用途就越广泛,需要配合&ldquo;Overrides&rdquo;面板控制的嵌套及样式关系就越为复杂,因此使用者对其用途的理解与记忆成本就越高,每次根据特定需求进行调整定制的复杂度也越高。而相应的,由于 Symbols 的高度整合,库的整体规模会相对较低,架构相对简单。</li> </ul> <p>以上两种状况,<strong>任何一个极端都不利于构建高效实用的组件库</strong>,制作者需要针对每一个图标、按钮、组件、模块,考虑如何实现通用性和易用性的平衡。</p> <p>以&ldquo;Social&rdquo;库当中的一些实现方式为例,来简单描述下这种平衡。</p> <h4> 图标</h4> <p>如下图所示,&ldquo;Social&rdquo;库提供了40个常用的功能性图标,并以此为基础扩展出了不同形状样式的共计48个&ldquo;Category&rdquo;类图标(用于金刚位或消息列表等等):</p> <p><img alt="" src="/sites/default/files/images/201812/Icons.png" style="width: 450px; height: 682px;border: none;" /></p> <p>从实现方法上,后两类图标显然无需定义 24x2 共计48个 Symbol;将基础图标 Symbol 与背景样式 Symbol 进行嵌套,打包成一个 Symbol 即可解决问题。这个 Symbol 具有高度的通用性,使用者可以通过&ldquo;Overrides&rdquo;控制其图标样式与背景种类。但从使用角度,这种方式不利于一目了然地识别和记忆,不利于使用者在第一时间了解有哪些同类元素可供调用,需要依靠猜测及&ldquo;Overrides&rdquo;进行复杂的控制。分别定义成48个图标之后,<strong>无论使用者打开源文件进行参考,还是直接作为 Library 调用,都可以清晰地看到全部可用元素</strong>。</p> <p>同时,这48个图标并不代表所有的可能性,你仍然可以通过 Sketch 52 提供的Symbols 样式定制功能实现更多的规格。</p> <h4> 按钮</h4> <p>&ldquo;Social&rdquo;库提供的行动类按钮包括以下3类,5种风格共计15个:</p> <p><img alt="" src="/sites/default/files/images/201812/Buttons.png" style="width: 450px; height: 394px;border:none;" /></p> <p>除了左侧带有图标的按钮之外(这类按钮的自适应性需要用到一些有意思的 hack 来实现,单独找一篇聊),其他几种风格,包括圆角矩形或胶囊状,以及实色、Ghost 样式等等,从技术角度同样可以藉由一个 Symbol 实现,并通过&ldquo;Overrides&rdquo;控制实际风格。但同样,<strong>作为组件库,相比于技术逻辑是否极致,易于发现、识别并快速调用才是最为优先的</strong>。</p> <h4> Feed Header</h4> <p>&ldquo;Social&rdquo;库提供了8个 Feed Header 组件,用于构建信息流卡片当中的用户信息。</p> <p><img alt="" src="/sites/default/files/images/201812/Header.png" style="width: 450px; height: 715px;border:none;" /></p> <p>如果加以整合,这8个 Symbols 完全可以压缩成两个,甚至是一个;在调用时通过&ldquo;Overrides&rdquo;控制内部元素的呈现或隐藏。然而在那样的情况下,从&ldquo;需要调用&rdquo;到&ldquo;完成调用&rdquo;这个过程已然需要使用者付出大量的认知成本,需要反复调整元素的布局与呈现关系,才能调试出可能符合自己需求的组件。</p> <h4> 结语</h4> <p>综上所述,对于&ldquo;Social&rdquo;库来说,我更希望使用者在调用其元素时,<strong>可以一目了然地发现所有选项,并能快速完成选择和调用</strong>;而非提供一系列极致整合的&ldquo;通用&rdquo;组件,使你不得不预先进行猜测、判断,并通过大量的定制工作才能达到目标。</p> <p>当然,这种平衡性原则也和库本身的性质有关。如上一篇物语所说,&ldquo;Social&rdquo;库的目标本就包含&ldquo;减轻甚至免除受众改造组件的成本,实现更快的使用速度&rdquo;,因此会使天平更倾向于&ldquo;易用性&rdquo;的一侧,而非高度整合的&ldquo;通用性&rdquo;。如果你需要制作的库更在于体量的控制或是需要体现前端开发方面的实现逻辑,那么对天平倾向性进行相应地调整也是有必要的。</p> <h4> WireframeKit 获取方式</h4> <p>WireframeKit for Sketch 是付费组件库系列,目前仅在 Beforweb 微店提供:</p> <ul> <li> <strong>Social</strong>:129元 ,附赠:</p> <p>&nbsp;</p> <p>&nbsp;</p> <ul> <li> C7210版《设计体系》全书译文(PDF)。</li> <li> Sketch 常用中文数据源。</li> </ul> </li> <li> <strong>iOS 12</strong>:99元</li> <li> <strong>Social + iOS 12 超值套装</strong>:仅需199元</li> </ul> <p>请通过以下小程序码访问微店获取(系统通常随机附送1至88元不等的红包)。付费后,你将得到下载链接及密码。</p> <p><img alt="" src="/sites/default/files/images/201808/WechatIMG57.jpeg" style="width: 300px; height: 300px;border:none;" /></p> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/38" typeof="skos:Concept" property="rdfs:label skos:prefLabel">线框原型</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/164" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Sketch</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/227" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Sketch组件库</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/226" typeof="skos:Concept" property="rdfs:label skos:prefLabel">WireframeKit</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/234" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计体系</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/235" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Design System</a></li></ul> Tue, 04 Dec 2018 09:35:44 +0000 C7210 1005 at http://www.beforweb.com http://www.beforweb.com/node/1005#comments 组件库物语 - 定义目标,以小为始 http://www.beforweb.com/node/1004 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/logo-icon-sketch-wireframekit-beforweb.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>Hello 各位周五好,一周又要过去了;眼看着一年也只剩下最后一个月了。</p> <p>本周上架了 WireframeKit for Sketch 系列的第三款组件库,&ldquo;Social&rdquo;。库如其名,聚焦于主流的社交类设计模式;和之前的系统库或概念库不同,这次完全基于市面上的真实产品,提炼了大量典型元素打造而成。</p> <!--break--><p><a href="http://beforweb.com/node/1003" target="_blank"><img alt="" src="/sites/default/files/images/201811/%E5%85%AC%E4%BC%97%E5%8F%B7%E4%B8%8E%E5%A4%B4%E6%9D%A1.png" style="width: 600px; height: 338px;" /></a></p> <p class="figure-caption">&ldquo;Social&rdquo;库附赠《设计体系》全书译文,<a href="http://beforweb.com/node/1003" target="_blank">了解详情</a> &rsaquo;</p> <p>很开心&ldquo;Social&rdquo;得到了新老朋友们的欢迎,验证了这个方向的库确实有真实需求,毕竟相比于 iOS 库来说,封装性和实用性高了很多,&ldquo;拿来就用&rdquo;才是最好。</p> <h3> 关于&ldquo;组件库物语&rdquo;</h3> <p>在制作&ldquo;Social&rdquo;库的过程中,我个人也收获到很多经验和感想;期间零零散散做着记录,包括思路、原则、工作方法、细节技巧等等,留到现在稍作归纳,一点点分享给各位。</p> <p>希望每次的内容能尽量简短精要,写起来不会有太多负担,读起来也可以有快速收获。</p> <p>这便是&ldquo;组件库物语&rdquo;。怪怪的名字,想不到更好的了,随它去。</p> <h3> 定义目标,以小为始</h3> <p>其实在很久之前就有了关于制作&ldquo;Social&rdquo;库的想法。在 iOS 库上架后不久,便开始进行非正式的规划工作,只是工作和个人要务一件接一件,期间又试验性地制作了一款&ldquo;Impart&rdquo;库,翻译了 Design Systems 全书,等等;直到近一两个月才开始着手。</p> <p>最初那些&ldquo;非正式的规划工作&rdquo;目标并不清晰,方向比较泛泛,一会想复制一个 Facebook 出来,一会觉得 Ins 可能会更好,或是聚焦在聊天工具上也不坏?往复许久也没想清这个库<strong>究竟用来做什么</strong>;相比于之前的 iOS 库,又该实现怎样的<strong>特定价值</strong>。</p> <p><img alt="" src="/sites/default/files/images/201811/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-11-30%20%E4%B8%8B%E5%8D%883_41_05.png" style="width: 600px; height: 363px;border:none;" /></p> <p class="figure-caption">聚焦于系统框架的 <a href="http://beforweb.com/node/994" target="_blank">iOS 库</a></p> <p>这种不清晰带来的副作用,就是在我自己的头脑中形成了&ldquo;这个库非常庞大非常难做&rdquo;的预判,进而潜移默化地造成了行动上的抵触 - 每有愿望开启这个项目时,便不由自主地找到另一件&ldquo;更优先更紧急&rdquo;的事项来逃避开。</p> <p>想想看,无论工作还是生活中,如此的心理状态和行为模式恐怕并不少见。</p> <p>今年秋天,在公众号完成了《设计体系》的全书译文之后,一方面希望借着翻译工作的余热,将期间学到的一些思路方法运用到实际当中,做些什么出来;另一方面,WireframeKit 系列也确实该上新了。综合这两方面原因,终于决定正式开动&ldquo;Social&rdquo;库。</p> <h4> 目标与范围</h4> <p>在缺失目标的状态下无法实际推动项目;既然决定正式启动,第一步还是要将目标定义清晰。WireframeKit 系列的受众是包括我个人在内的产品/交互设计师,用户价值体现在能否<strong>帮助受众快速实现中/高保真线框原型</strong>。&ldquo;快速&rdquo;的概念本身又包含多个层次:过去的 iOS 库提供了全面、灵活的系统级组件框架,便于快速根据实际需求进行改造和复用;而诸如&ldquo;Social&rdquo;这样聚焦于特定产品领域的库,则应该<strong>通过对典型模式的封装,进一步减轻甚至免除改造组件的成本</strong>,实现更快的使用速度。</p> <p>而对于我们这些设计师来说,日常相关项目中最为需要的,仍是我们身边的市场当中那些<strong>最为主流的、久经验证的社交类产品所提供的典型设计模式</strong>。因此,基于这些我们所熟知的真实产品进行提炼就成为必然。</p> <p>省略掉繁琐的细节分析,大致的目标梳理思路便是如此。</p> <p><img alt="" src="/sites/default/files/images/201811/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-11-30%20%E4%B8%8B%E5%8D%883_46_23.png" style="width: 600px; height: 363px;border:none;" /></p> <p class="figure-caption">&ldquo;Social&rdquo;库提供的社交类界面范例</p> <h4> 以小为始,进入巡航</h4> <p>厘清目标和项目范围,对于行动的认知便不像之前那样宽泛和沉重了。两点关键行动:</p> <ol> <li> <strong>收集、分析相关产品,提炼设计模式</strong>。也就是通常所说的&ldquo;清查&rdquo;工作;相关思路和方法在《设计体系》一书中也有比较详细的介绍。</li> <li> <strong>组件库的实际制作</strong>。最为漫长的过程,需要在每一次的执行过程中保持细心和聚焦的心智状态,并且考验毅力。</li> </ol> <p>在清查工作期间,我每一次只给自己设定一个&ldquo;小目标&rdquo;,譬如今天完成对微博所有关键页面的截图和汇总,然后休息,并给自己一个大大的赞;明天完成知乎,同样的工作量和自我正向回馈;如此往复。<strong>当你把一件在认知当中较为庞大的事项这样细分到便于执行的颗粒度,事情就会变得非常容易推进</strong>。</p> <p><img alt="" src="/sites/default/files/images/201811/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-11-30%20%E4%B8%8B%E5%8D%883_42_33.png" style="width: 600px; height: 363px;border:none;" /></p> <p class="figure-caption">界面清查</p> <p>这里为各位介绍一个非常好用的移动端截屏工具,Picsew。自动拼接及相关的自动化功能都非常有效和易用。</p> <p>同理,对于最为关键的实际制作过程,依然要进行充分地拆解。先不花太多时间考虑框架整体层面的架构,而是从最容易入手的方面做起,譬如今天完成几个图标,明天完成一两个导航栏,接下来是信息流当中用户信息组件的制作,等等。有心力时便多做几个小物件,累了就放下。<strong>首先让自己动起来,从&ldquo;抵触&rdquo;进入&ldquo;开动&rdquo;,保持较小的、较容易完成的工作量,直到自己开始上瘾,如此逐渐进入巡航状态,整个项目会自然而然地进入正轨</strong>。</p> <p>当然,在进入巡航状态之后,怎样依靠正确的方法及毅力进行维系和修正则成为了关键;这又是另外的话题了。</p> <h4> 结语</h4> <p>关于定义目标和以小为始,大体便是如此;无论是组件库的规划和制作,还是实际产品,无不是同样的道理。有时我们需要自上而下进行规划和执行,有时则需要自下而上地首先找到节奏,进入状态,再进行修正及全局把控。</p> <p>或许更像是随笔,而非细节指南。随它去,最重要的部分都在这里了。</p> <p>下次物语聊些什么呢。再从之前的记录当中选选看好了。希望这样的内容可以为各位的相关工作带来一些参考。</p> <h4> WireframeKit 获取方式</h4> <p>WireframeKit for Sketch 是付费组件库系列,目前仅在 Beforweb 微店提供:</p> <ul> <li> <strong>Social</strong>:129元 ,附赠:</p> <p>&nbsp;</p> <p>&nbsp;</p> <ul> <li> C7210版《设计体系》全书译文(PDF)。</li> <li> Sketch 常用中文数据源。</li> </ul> </li> <li> <strong>iOS 12</strong>:99元</li> <li> <strong>Social + iOS 12 超值套装</strong>:仅需199元</li> </ul> <p>请通过以下小程序码访问微店获取(系统通常随机附送1至88元不等的红包)。付费后,你将得到下载链接及密码。</p> <p><img alt="" src="/sites/default/files/images/201808/WechatIMG57.jpeg" style="width: 300px; height: 300px;border:none;" /></p> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li><li class=" taxonomy-term-reference-1"><a href="/point" typeof="skos:Concept" property="rdfs:label skos:prefLabel">观点</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/38" typeof="skos:Concept" property="rdfs:label skos:prefLabel">线框原型</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/226" typeof="skos:Concept" property="rdfs:label skos:prefLabel">WireframeKit</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/227" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Sketch组件库</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/164" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Sketch</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/234" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计体系</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/235" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Design System</a></li></ul> Fri, 30 Nov 2018 12:01:00 +0000 C7210 1004 at http://www.beforweb.com http://www.beforweb.com/node/1004#comments Sketch终于带来Library样式调用 http://www.beforweb.com/node/974 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/logo-icon-sketch-app-new.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>一早收到订阅邮件(是的,古早又现代的阅读习惯,详见&ldquo;<a href="http://beforweb.com/node/973" target="_blank">设计文章那么多,读不过来怎么办?</a>&rdquo;),见到很简单的一则关于Sketch 51 Beta版本的消息:</p> <blockquote><p><strong>New in Sketch 51</strong></p> <p>Library Styles - Text Styles and Layer Styles defined in Libraries are now available in all documents, just like Symbols are.</p> </blockquote> <p>我们在Libraries当中定义的文字与图层样式,终于可以像Symbols一样被全局统一调用了。超感动。</p> <!--break--><p><img alt="" src="/sites/default/files/images/201806/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-06-26%20%E4%B8%8B%E5%8D%885_26_41.png" style="width: 600px; height: 340px;" /></p> <p>Library也终于可以成为真正意义上的&ldquo;Single Source of Truth&rdquo;了,而无需你再通过蹩脚的方式获取样式定义,譬如复制粘贴或是使用插件提取。</p> <p>Btw我个人近来在用&ldquo;Sketch Style Libraries&rdquo;这款插件来提取Libraries中的样式定义,还可以做反向同步整合。</p> <p><img alt="" src="/sites/default/files/images/201806/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202018-06-26%20%E4%B8%8B%E5%8D%885_40_01.png" style="width: 600px; height: 414px;" /></p> <p>前一周还在痛心疾首呢,YY着什么时候能够原生实现Library大一统;今天就看到出现在最新的Beta当中,于是感到这一周还不坏。</p> <p>有兴趣提前试用的朋友可<a href="https://www.sketchapp.com/beta/">移步Sketch官网</a>下载贝塔版本。</p> <p>还舒克版本呢。</p> <p><img alt="" src="/sites/default/files/images/s/QR-Support-C.JPG" style="width: 450px; height: 450px; border: none;" /></p> <p><img alt="" src="/sites/default/files/images/s/Banner-PS-BFW-3x.png" style="width: 450px; height: 116px; border: none;" /></p> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/news" typeof="skos:Concept" property="rdfs:label skos:prefLabel">时讯</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/115" typeof="skos:Concept" property="rdfs:label skos:prefLabel">视觉设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/164" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Sketch</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/235" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Design System</a></li><li class=" taxonomy-term-reference-7" rel="dc:subject"><a href="/taxonomy/term/234" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计体系</a></li></ul> Tue, 26 Jun 2018 12:07:13 +0000 C7210 974 at http://www.beforweb.com http://www.beforweb.com/node/974#comments 如何规避Design System架构设计中的逻辑陷阱 http://www.beforweb.com/node/970 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/icon-logo-design-system.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>各位好。自从尝试录音之后,再写字就会有一种和从前不一样的感觉 - 要表达的东西像是更加口语化,要脱口而出的样子;但通过键盘落到文字上时,口吻又被另一个自己所占领,像是一直以来的文字人格。</p> <p>周六的夜聊(<a href="http://www.ximalaya.com/keji/15418333/92030497">关于黑胶、文青与Design System的架构设计</a>)似乎是到目前为止我个人感到最舒适的一期录音。没什么事先规划,也没有急迫的正经事要讲,只是聊天说话的样子,伴着1938年爵士乐现场的黑胶唱片与Jim Beam。</p> <p>既然从一开始这个文字版的博客就是自娱自乐为主,换了内容载体也没必要为任何事情而变化吧。那我自便了。尽量不去想太多&ldquo;你们&rdquo;,而回过头来更多关注&ldquo;我&rdquo;自己。我随意,大家也随意。</p> <p>上周说到了&ldquo;<a href="http://beforweb.com/node/969" target="_blank">像做产品一样对Design System进行前期规划</a>&rdquo;,包括目标、原则、范围与架构,这四个方面。本周在最关键的部分深入推进一步,聊聊&ldquo;架构&rdquo;当中的一些问题。</p> <!--break--><p>需要再次说明,这些内容多数来自于我日常的工作日志,更像随笔,且仅代表我个人在面对特定的产品/项目/团队时所用到的工作思路和方法;事情只有特定的最优解,而非唯一答案;希望为各位带来一定的参考价值。</p> <h3> 组件库与设计规范</h3> <p>记得之前看到一篇文章,比喻得非常漂亮 - 仅就相对狭义的、以组件库与设计规范为主要组成部分的Design System而言,你可以将其想象成宜家家具 - 组件库是以零件形态呈现的家具产品,而设计规范便是指导你完成组装的说明手册。</p> <p>两者的功用及关联性就是这样一目了然;两者的架构设计在很大程度上具有共通性。大体上,组件库与设计规范的架构体系在颗粒度较小的层面通常可以做到一致;但设计规范也会有其特定的目标及作用范围,当涉及到&ldquo;设计模式&rdquo;等层面,颗粒度往往会超过组件库所能承担的范围,此时也无需追求全面一致。</p> <h3> &ldquo;原子化设计&rdquo;不错</h3> <p>有过相关经验的朋友或许都知道,组件库初期的架构设计工作是最消耗时间与心力的过程,特别是对于大中型&ldquo;成熟&rdquo;产品而言,太多的功能流程及相应的组成页面,太多的不一致性问题 - 以怎样的规则去梳理可复用的组件,以怎样的颗粒度去划分组件层级,怎样确保划分方式具有足够的灵活性与实用性 - 推进过程往往是慎之又慎、举步维艰的,每一个步骤都严格以上一个步骤为基础。</p> <p>对于组件的颗粒度划分,目前最经典的理论是&ldquo;原子化设计(Atomic Design)&rdquo;,我们之前在一些文章当中也有介绍;可大致理解为:</p> <ul> <li> <strong>原子</strong>:最基础的、不可分割的设计要素,宜家家具的零件单元,一块乐高积木,等等。通常包括颜色、文字、栅格体系等样式风格要素,以及图标、按钮、文本输入框、切换等功能性的界面基础要素。</li> <li> <strong>分子</strong>:由原子组成的、具备独立功能性的最小可复用单元,例如一个包含了文本输入框、占位符文字及按钮等元素的搜索栏,或是一个包含了用户头像、用户名、用户评论内容及点赞按钮的列表单元(Table View Cell)等等。</li> <li> <strong>有机体</strong>:由单一/多种类型的分子组成的信息/功能性模块。</li> </ul> <p><img alt="" src="/sites/default/files/images/201806/atomic-design.jpg" style="width: 600px; height: 375px;" /></p> <p>至于&ldquo;模板&rdquo;和&ldquo;页面&rdquo;,个人看来对于组件库架构设计的意义不大;或可从&ldquo;视图&rdquo;的角度理解&ldquo;模板&rdquo;,这个再议。</p> <h3> 但会出现很多问题</h3> <p>然而在很多时候,<strong>当你准备以原子化设计的思路规划整个组件库的架构时,往往会发现实际状况绝非如此层次分明、符合逻辑</strong>;原子级别的要素大体还好,一旦进行到&ldquo;分子&rdquo;和&ldquo;有机体&rdquo;的层面,时常感到难以判断和区分。</p> <p>梳理架构的第一步通常是UI清查,这是一项枯燥和冗长的工作,你需要将现有的典型页面(截图或设计源文件)整合在一起,提炼出各类典型元素,进行相对松散的归类,判断组件库的大致架构;期间可能遇到的典型问题包括:</p> <ul> <li> 对于一些模棱两可的元素,应该按照相似的样式进行归类,还是按照功能做区分?譬如样式上均属于&ldquo;标签(Tag)&rdquo;的元素,从功能角度,某些是真正意义上的属性标签,某些则是选项列表的组成部分;这时是否应该将它们归为一类?</li> <li> 多数涉及&ldquo;内容&rdquo;的产品,内容类的&ldquo;分子&rdquo;或&ldquo;有机体&rdquo;占据着很大的组成部分,且自身的组成元素往往会根据不同的页面环境而有着大大小小的不同,包括商户、商品、评论、内容Feed等。对于这些内容,是否有必要封装成可复用的组件,封装之后是否反而会影响实际设计时的灵活性?它们与其他&ldquo;功能性&rdquo;的组件在逻辑上有怎样的不同?</li> <li> 除了主色盘及基本样式以外,产品当中往往会四处出现用途比较单一或边缘的配色、文字及图形样式,这些样式是否有必要进行严格的定义?如果定义,如何避免样式库与组件库的过度复杂;如果不定义,如何确保这些&ldquo;非主流&rdquo;元素在未来设计过程中的一致性?</li> </ul> <h3> 问题的根源</h3> <p>个人认为,通过原子化设计的思路进行UI清查和架构设计时遇到的一系列问题,<strong>其根本原因在于,&ldquo;原子化设计&rdquo;本身更像是一种开发思路,它是事物构成的基本规律与方式,但未必适于&ldquo;认知&rdquo;和&ldquo;使用&rdquo;层面的心智模型</strong>。</p> <p><img alt="" src="/sites/default/files/images/201806/mental-model.png" style="width: 565px; height: 318px;" /></p> <p>你可以遵循严格意义上的原子化设计思路去到Sketch当中逐层进行样式定义与Symbols嵌套,但最终的产出未必是对设计师实际有用的组件库。</p> <p>如前所述的一系列问题、矛盾,<strong>本质上是用户(设计师)的心智模型与产品(组件库)的实现逻辑之间的冲突</strong>。当你自身是设计师,同时又是组件库/设计体系的制作人员时,你会不经意间在&ldquo;设计师&rdquo;与&ldquo;产品开发人员&rdquo;这两个角色之间交织互换而不自知。</p> <h3> 一些原则</h3> <p>对于组件库/设计体系这样复杂的事物而言,<strong>任何单一的逻辑与标准都未必行得通;最终还是要从我们在上一篇当中聊过的&ldquo;目标&rdquo;和&ldquo;原则&rdquo;出发,结合用户的认知模型与产品自身的实现逻辑,找到相对折中的方式进行推进</strong>。</p> <p>对于实际&ldquo;用户&rdquo;,即设计师而言,组件库/设计体系的目标在于解决表现层面设计工作中的痛点,提高执行效率与产出的标准化。围绕着这样的目标,我给自己制定了几点原则;每当在组件库架构规划中遇到问题和矛盾时,通常可以参考这些原则,以实际结果为导向进行判断,避免陷入逻辑陷阱:</p> <h4> 原则一</h4> <p>对于组件库架构设计与库文件的制作方式,在大方向上要符合原子化设计思路,即颗粒度从小到大,从简单到复杂;特别是在Sketch Library文件的实际制作过程中,<strong>从技术角度严格遵守层级思路是必需而非better to have</strong>。原子化设计的思维方向无错,解决问题的关键在于结合使用者的心智模型,即原则二。</p> <h4> 原则二</h4> <p>难以确定组件颗粒度/复用性/在架构中所处的类别时,避免陷入过于严格的逻辑思维模式,而要<strong>考虑设计师的实际所需,考虑设计师在组装界面时的直觉与思维模式,考虑设计师在典型的需求中预期得到哪些零件,他们/我们对这些零件通常是如何归类的,哪些属性是他们/我们需要频繁订制的,哪些是很少/不会触及到的</strong>。对于使用Sketch进行界面设计的团队,组件库最终的产出将体现在一个个Symbol和Shared Style当中,而非设计规范中描述的设计模式或是开发侧的代码包;<strong>这些Symbol和样式能否被设计师快速发现、理解和调用,才是最重要的</strong>,无论它们在实现逻辑上是否符合这样或那样的设计思想理论;其他都是浮云,<strong>实践是检验真理的唯一标准</strong>。</p> <h4> 原则三</h4> <p>充分分析和参考现有的任何设计规范/标准,运用你的基础开发常识(如有)去理解开发侧的代码组件架构;所有这些文档都能在一定程度上映射出产品的信息与功能架构。此外,相比于埋头在繁冗的UI清查工作当中难以自拔、纠结逻辑,不如多花些时间与一线设计师进行沟通,了解他们/我们当前是否有着组件化的、非正规但有效的解决方案。<strong>将所有这些&ldquo;现有&rdquo;的应对方案进行汇总,再沿着原子化设计的大方向,结合自己的UI清查,逐渐梳理出一套即在一定程度上符合逻辑,又充分适用于实际需求的组件库架构框架</strong>。</p> <p><img alt="" src="/sites/default/files/images/s/QR-Support-C.JPG" style="border: none; width: 450px; height: 450px;" /></p> <p><img alt="" src="/sites/default/files/images/s/Banner-PS-BFW-3x.png" style="border: none; width: 450px; height: 116px;" /></p> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li><li class=" taxonomy-term-reference-1"><a href="/point" typeof="skos:Concept" property="rdfs:label skos:prefLabel">观点</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/115" typeof="skos:Concept" property="rdfs:label skos:prefLabel">视觉设计</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/234" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计体系</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/243" typeof="skos:Concept" property="rdfs:label skos:prefLabel">组件库</a></li><li class=" taxonomy-term-reference-7" rel="dc:subject"><a href="/taxonomy/term/235" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Design System</a></li></ul> Sun, 03 Jun 2018 13:03:04 +0000 C7210 970 at http://www.beforweb.com http://www.beforweb.com/node/970#comments 像做产品一样对Design System进行前期规划 http://www.beforweb.com/node/969 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/icon-logo-design-system.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>难得周六。一点儿也不难得,每周都会有。昨天任性的暴雨过后整个天地还是灰色的,倒是凉快些。我近半年来听的中文歌比过去十几年加起来都要多的样子。</p> <p>说起来,自己回听了一下昨晚发的&ldquo;<a href="http://www.ximalaya.com/keji/15418333/90686063">夜聊-终于有背景音乐了</a>&rdquo;,感到处理方式还是有些生疏和暴力;音量、距离一类,接下来会尝试优化。对,所以接下来的播客当中还是会用人肉DJ的方式举着手机对着麦做BGM哦。</p> <p>昨天有提到关于Design System的话题,今天趁热做掉。简单聊聊好了,因为近来的工作主要聚焦在这方面,且又是几乎从零开始的状态,所以这次想要至少通过这样非正式的方式做做记录。</p> <!--break--><p>另外之前在<a href="http://www.ximalaya.com/keji/15418333/88532996">关于设计的小故事的夜聊</a>中也有提到关于写起东西容易收不住的状况;目下又是如此&ldquo;简单聊聊&rdquo;的状况;希望真的可以做到言简意赅。这篇应该也会发布语音版,譬如&ldquo;有声尬聊版&rdquo;一类;看心情。</p> <p>关于Design System,个人以为仍难以进行最精准的概念定义 - 包括产品类型、阶段、规模,团队构成、文化,甚至连同整个公司/组织在产品侧的策略也可以包含进来,都会对所谓&ldquo;设计体系&rdquo;的存在目的与方式产生决定性的影响。</p> <p>因此我所能聊到的,也仅是当前我在自己所面对的特定工作情境中的状况;某些方面或许具备普适性,而另外一些方面或许只能提供特定角度的参考,这样。</p> <h3> 像做产品一样</h3> <p>何为&ldquo;像做产品一样&rdquo;?这里特指《用户体验要素》这本书所定义的最为经典的产品设计思维模型,即是将&ldquo;设计&rdquo;流程分为五个层面,从最为本质和抽象的核心出发依次向上梳理至User Interface表现层面;大致包括:</p> <ul> <li> <strong>目标层</strong>:定义多方面目标,所谓&ldquo;多方面&rdquo;即是指公司业务目标、产品设计目标及用户目标;围绕&ldquo;产品&rdquo;这一&ldquo;实体&rdquo;,对各方面的痛点、诉求进行辨识与整合。</li> <li> <strong>范围层</strong>:基于目标定义,界定产品信息/功能范围,判别最为必要与核心的要素/有利于目标实现的要素/概念相关但与当前目标实现无关的要素。</li> <li> <strong>结构层</strong>:在明确界定的信息/功能范围当中,梳理信息/功能架构,定义流程。</li> <li> <strong>框架层</strong>:将信息架构与功能流程具像化,即通过相对低保真的形式对界面流程关系及界面信息层级进行组织呈现。</li> <li> <strong>表现层</strong>:细化界面表现形式,结合品牌特质与情感化要素对界面进行高保真呈现。</li> </ul> <p><img alt="" src="/sites/default/files/images/201805-1/Screen-Shot-2016-08-24-at-8_57_32-AM.png" style="width: 600px;" /></p> <p class="figure-caption">图片来自crowdfavorite.com</p> <p>话说回来,无论工作还是生活中,诸多事务都会体现着类似的逻辑框架,即依次明确为什么要做(Why)、做什么(What)、如何做(How)。以我们在产品设计工作中最为硬核的&ldquo;思维框架&rdquo;来打造产品设计工作中最为硬核的&ldquo;工具框架&rdquo;,这事儿自然而然,符合逻辑。</p> <h3> Design System的前期规划</h3> <p>前期规划主要遵循五层思维模型的前三个层面,即对&ldquo;目标&rdquo;、&ldquo;范围&rdquo;、&ldquo;结构&rdquo;进行定义。需要再次说明,相关经验仅与特定产品/团队状况相关;思路供参考。</p> <h4> Design System的目标</h4> <p>Design System,顾名思义,是体系化的工作,需要短期内集约重要/大量的资源进行构建,并保持长期的维护/进化工作。对于这种量级的事项,必须顾全多方面的目标,在前期充分达成共识,才能尽可能争取资源,并形成长期合力。目标所涉及的对象或可包括:</p> <p><strong>设计师</strong></p> <p>设计师是Design System最直接的&ldquo;用户&rdquo;,能否解决设计师工作中的实际痛点,这也是Design System最为关键的价值之一。目标或可包括帮助现有设计师规范工作流程,使工具、方法、产出更加标准化,提高执行效率,进而提升设计思考的工作比例,等等;此外对于新进设计师快速进入标准化工作状态的作用也要考虑到。</p> <p><strong>设计团队</strong></p> <p>在解决直接&ldquo;用户&rdquo;的痛点的同时,Design System更要在设计团队层面进行赋能,例如提升设计团队在公司内/外的专业度与影响力等等。</p> <p><strong>产品</strong></p> <p>Design System所解决的问题最终将体现在实际产品的体验当中,譬如提升产品/产品家族在交互、视觉表现、品牌识别等层面的一致性,提升产品体验与公司品牌形象等等;无法上升到产品/业务层面的解决方案都只是空中楼阁。</p> <h4> Design System的范围</h4> <p>界定Design System的作用域,譬如:</p> <ul> <li> 产品:针对单一产品,还是需要横跨整个产品家族;仅针对线上产品,还是需要包含线下服务链当中的每一个用户/客户触点。</li> <li> 面向人员:仅面设计师(交互/视觉/创意/物料/空间/全链路),还是需要涵盖产品经理、工程师等上下游相关职能。</li> </ul> <h4> Design System的结构</h4> <p>基于作用域范围的界定,梳理Design System的信息架构。之前的相关文章当中也有过介绍;通常意义上的设计体系大致包括以下最为典型的组成部分:</p> <p><strong>基础要素</strong></p> <ul> <li> 颜色(Color)</li> <li> 文字(Typography)</li> <li> 样式(Style)</li> <li> 栅格(Grid)</li> <li> ...</li> </ul> <p><strong>设计模式</strong></p> <ul> <li> 组件(Component)</li> <li> 模块(Module)</li> <li> 动效/动画(Transition/Animation)</li> <li> ...</li> </ul> <p><strong>设计规范</strong></p> <ul> <li> 全局</li> <li> 价值主张</li> <li> 设计原则</li> <li> 品牌规范</li> <li> ...</li> </ul> <p><strong>元素</strong></p> <ul> <li> 功能定义</li> <li> 类型/状态</li> <li> 应用原则</li> <li> 应用示例</li> <li> ...</li> </ul> <p>同时对于更为广义的&ldquo;设计工作标准化&rdquo;而言,或可进一步包括流程与方法规范、工具规范、素材与产出形式规范等等。</p> <p>此外,对于&ldquo;基础要素&rdquo;和&ldquo;设计模式&rdquo;这两部分来说,采用层级更为复杂、同时也更具灵活性和工程性的&ldquo;Atomic Design&rdquo;作为架构设计思路也是非常推荐的;你可以将以上的架构示例理解为抽象层面的逻辑梳理,而非针对最终的产出形式而严格区分。</p> <p>到此为止就是今天想要聊的全部,关于如何通过产品设计思路对Design System进行前期规划;而接下来更为细化的规划/执行方式,包括工具方法等等,我或会根据实际工作中的推进状况再做进一步的介绍和分享。</p> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li><li class=" taxonomy-term-reference-1"><a href="/point" typeof="skos:Concept" property="rdfs:label skos:prefLabel">观点</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/115" typeof="skos:Concept" property="rdfs:label skos:prefLabel">视觉设计</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/234" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计体系</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/235" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Design System</a></li></ul> Mon, 28 May 2018 15:52:55 +0000 C7210 969 at http://www.beforweb.com http://www.beforweb.com/node/969#comments 《Design Systems》精华摘译(一)关于本书 http://www.beforweb.com/node/963 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/icon-logo-design-system.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>我试试看做这件事,但并不大确定。连&ldquo;摘译&rdquo;这个词本身的含义也是昨晚查了一下才确认基本符合自己的意图。摘译,先摘后译,区别于&ldquo;全译&rdquo;与&ldquo;节译&rdquo;,取文之精华而(相对)快速译成。&ldquo;精华&rdquo;的标准或许会有主观之嫌;同样不确定。</p> <p>原本计划全书翻译出版,却因版权相关问题耽搁而一直无法落实;这种情况下以任何形式全译并发布内容都有不妥,于是我们先做类似摘译或读书笔记的形式好了。</p> <p>大体原则,是依照完整的章节顺序,选取精华段落,或段落中的精华语句组织成文;以快速传达原文核心思想为首要目标,而不在形式上严格遵循原文词句。突然隐隐感到这是比全译更加费脑力的差事,不知为什么;试试看先。</p> <!--break--><p>第一期,前言与简介。下面进入译文。</p> <p><img alt="" src="/sites/default/files/images/201805-1/stephan-boom-800-opt.jpg" style="width: 600px; height: 450px;" /></p> <h3> 关于本书</h3> <p>随着互联网的飞速发展及产品复杂度的提升,以&ldquo;页&rdquo;为单元来思考界面设计的方式变得越发不可行,我们需要更加系统化的思维方式。</p> <p>设计体系不一而同,有些团队可以以此为基础构建出众的产品体验,并不断进行优化迭代;而有些则渐渐搁置,疏于维护,流于形式。</p> <p>良好的设计体系有哪些特质?那些优秀的团队是如何打造和使用设计体系的?大量的观察、研究与思考促使我完成此书。</p> <h3> 本书面向的读者</h3> <p>本书旨在帮助中小型产品设计团队更好地将设计体系思维融入工作当中。团队中的交互、视觉设计师及前端开发人员均能从中受益。</p> <h3> 本书的研究范围</h3> <p>本书不会深入到设计体系以外的其他主题当中,譬如信息架构、内容策略或用研等方面。同样,这也不是一本技术书籍,不提供任何范例代码,虽然其中一部分内容与前端开发实践相关。</p> <p>这是一本关于设计的书,但不会讨论&ldquo;设计一款怎样的产品&rdquo;或&ldquo;如何设计一款产品&rdquo;。本书所探讨的是如何以更加体系化的方式推动设计流程,以及如何围绕特定的产品目标及团队特质来构建设计体系。</p> <h3> 本书的内容</h3> <h4> 第一部分:设计体系的基础构成</h4> <p>介绍设计体系的基础构成,包括设计模式与实践方法。</p> <ul> <li> <strong>设计模式</strong>(Design Patterns),可复用的界面组成要素,包括:</p> <ul> <li> <strong>功能性设计模式</strong>:按钮、文本框...</li> <li> <strong>感知性设计模式</strong>:配色、字体&hellip;</li> </ul> </li> <li> <strong>实践方法</strong>(Shared Practice),关于如何定义设计原则,创建组件库,以及如何管理设计模式,包括创建、提炼、分享及使用设计模式。</li> </ul> <h4> 第二部分:如何创建设计体系</h4> <p>关于创建和维护设计体系的具体步骤与方法:</p> <ol> <li> 体系规划</li> <li> 界面清查</li> <li> 模式库创建</li> <li> 文档编写</li> <li> 体系迭代与维护</li> </ol> <h3> 术语定义</h3> <h4> &ldquo;模式&rdquo;或&ldquo;设计模式&rdquo;</h4> <p>用于指代任何可复用的界面组成要素,包括按钮、文本框、配色、字体,以及可复用的交互行为与功能流程等等。</p> <h4> &ldquo;功能性设计模式&rdquo;或&ldquo;模块&rdquo;</h4> <p>界面的实体组成要素,例如按钮、页头、表单元素、菜单等等。</p> <h4> &ldquo;感知性设计模式&rdquo;或&ldquo;风格&rdquo;</h4> <p>界面的非实体组成要素,涉及外观、品牌及情感化元素。</p> <h4> &ldquo;模式语言&rdquo;或&ldquo;设计语言&rdquo;</h4> <p>组成产品界面的一系列内在关联的设计模式,包含功能性模式与感知性模式,以及针对特定平台与产品领域的设计模式。</p> <h4> &ldquo;设计体系&rdquo;或&ldquo;体系&rdquo;</h4> <p>我们很难对这个概念进行精准定义;本书将其定义为&ldquo;以数字化产品设计为核心的一系列标准化的设计模式与实践方法&rdquo;。</p> <h4> &ldquo;模式库&rdquo;与&ldquo;设计规范&rdquo;</h4> <p>用于收集、提炼、使用和共享设计模式。</p> <h3> 设计体系洞悉</h3> <p>本书基于真实产品设计而著,包括我所在公司的产品以及五个大家耳熟能详的产品及团队;我对他们进行了为期18个月的访谈和研究。</p> <ul> <li> <strong>FutureLearn</strong>:在线教育平台,我所在的团队;我参与了设计体系从无到有的构建。</li> <li> <strong>Airbnb</strong>:他们的交互设计师为我提供了大量关于Airbnb设计语言体系(DLS)的详细信息,关于如何精准定义和使用设计模式,具体的实践方法与工具等等,包括一些挑战和问题。</li> <li> <strong>Atlassian</strong>:他们有独立的设计体系团队,同时也为所有人开放了相关权限,推动体系的进化迭代。</li> <li> <strong>Eurostar</strong>:本书撰写的过程中,他们的团队正在创建第一套模式库,并遇到了一些典型问题,包括优先级的规划以及如何鼓励团队共同贡献;一年后,他们也有了独立的设计体系团队。</li> <li> <strong>Sipgate</strong>:他们的第一套模式库建立于2015年,之后经历了一次重新构建,旨在统一各子产品之间的设计模式。</li> <li> <strong>TED</strong>:他们以一种相对简单的在线文档的形式维护着一套设计规范。</li> </ul> <h3> 本书的目录架构</h3> <h4> 第一部分</h4> <ol> <li> 设计体系</li> <li> 设计原则</li> <li> 功能性设计模式</li> <li> 感知性设计模式</li> <li> 设计语言</li> </ol> <h4> 第二部分</h4> <ol> <li> 设计体系的范围界定</li> <li> 规划与可行性</li> <li> 功能性设计模式的系统化</li> <li> 感知性设计模式的系统化</li> <li> 模式库</li> </ol> <p><span style="color:#a9a9a9;">英文原文:http://designsystemsbook.com,作者:Alla Kholmatova,译者:C7210</span></p> <p><span style="color:#a9a9a9;"><img alt="" src="/sites/default/files/images/s/QR-C(1).png" style="width: 450px; height: 450px;" /></span></p> <p><span style="color:#a9a9a9;"><img alt="" src="/sites/default/files/images/s/Banner-PS-BFW-3x.png" style="width: 450px; height: 116px;" /></span></p> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/115" typeof="skos:Concept" property="rdfs:label skos:prefLabel">视觉设计</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/234" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计体系</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/235" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Design System</a></li><li class=" taxonomy-term-reference-7" rel="dc:subject"><a href="/taxonomy/term/16" typeof="skos:Concept" property="rdfs:label skos:prefLabel">原创翻译</a></li></ul> Tue, 08 May 2018 12:43:23 +0000 C7210 963 at http://www.beforweb.com http://www.beforweb.com/node/963#comments Design System - 以小为始,持久进化 http://www.beforweb.com/node/962 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/icon-s-logo-flat-minimum-design-ui-ux-user-interface-web-app.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>忽冷忽热的春季,善变着又有些讨巧,耳边的音乐里也有着光与风,就像坐在漫咖啡(继续感谢各位支援的美式)二楼窗旁。灯光昏黄着华丽着,足够亮到可以读书便可。</p> <p>许巍说自己是高晓松的粉儿,于是唱了《生活不止眼前的苟且》。&ldquo;你赤手空拳来到人世间,为找到那片海不顾一切&rdquo;,多好。</p> <p>今天的译文于我个人而言完全是用来换脑子的,抽空将自己从书中抽离,这样。抽离这个词是这么用的么?感觉像是pia飞一类。</p> <p>原文&ldquo;The Minimum Viable Design System&rdquo;,将设计体系与&ldquo;最小化可用产品&rdquo;进行了类比,强调其永无止境的、动态迭代的特性;作者Marcin Treder,在线原型设计工具UXPin的CEO,写过蛮多Design System方面的文章,有机会会分享给各位更多。下面进入译文。</p> <!--break--><p><img alt="" src="/sites/default/files/images/201804-2/minimum-viable-design-system-01.png" style="width: 600px; height: 386px;" /></p> <p>过去几周里,我在一些设计聚会当中谈到关于设计体系的话题;分享的过程很愉快,会后的交流也使我学到很多东西。</p> <p>其中,有一个问题我被问到多次;这个问题在我们团队内部也时常会被提起:</p> <blockquote><p>构建设计体系需要花费多少时间?</p> </blockquote> <p>问题本身无所谓对错,我很乐于回答。然而每一次,我都感到一个更深层的问题被引发出来:人们仍然对&ldquo;设计体系&rdquo;这个概念有所误解,似乎仍在将其混同于传统的&ldquo;设计规范&rdquo;。</p> <h3> 僵尸一般的设计规范</h3> <p>曾几何时,某个设计团队或前端开发团队中的某个不幸的员工被推选出来,负责将那些经过团队验证的设计方式记录成文档,包括配色、字体、UI模式与代码段,等等。</p> <p>听起来很像设计体系?确实,但并不是。</p> <p>传统的设计规范制订工作旨在输出一套完整的&ldquo;成品&rdquo;。然而每一次,这个&ldquo;成品&rdquo;在真正完成之前就已经过时了,最终便成为僵尸一般半死不活的存在。</p> <p>原因何在?很简单,互联网产品的迭代速度太快了,变化是一种常态。设计师们试图将每一条规则编入文档,而同时,规则本身却在不断改变和进化。这件事本身就像西西弗斯神话一样。</p> <p>这项工作所带来的挑战致使业界开始重新思考如何通过更合理的方式去维护设计与代码的一致性,于是&ldquo;设计体系&rdquo;的概念出现在我们面前。</p> <h3> &ldquo;设计体系&rdquo;是一种动态的流程</h3> <p>与强调成品产出的设计规范有所不同,设计体系更具动态性,也就是更在于流程本身。</p> <p>相比于指派某个设计师去创建一份静态文档,&ldquo;设计体系&rdquo;需要我们规划一套更加合理的工作流程,以产品体验的不断优化为目标,随时对设计工作当中产生的关键信息进行整理与维护。</p> <p>设计体系团队需要关注的不是&ldquo;成品&rdquo;的交付日期,而是如何持之以恒地、渐进式地改善产品设计一致性等方面的问题,以及如何提升产品迭代的效率,使之能够越发快速地在市场当中进化和成长。</p> <h3> 通过合理的流程抑制复杂度的攀升</h3> <p>与任何封闭化的体系一样,数字化产品的熵值也会持续提升,除非我们进行有意识的控制。产品的每一个新功能,团队的每一名新成员,组织架构中每一个新的管理层...所有这些因素,最终都会导致产品复杂度的提升,即熵值的增大。</p> <p>唯有持续的规划与管理才能抑制不断攀升的熵值。对于设计体系团队而言,关键问题不在于一份规范化的静态输出,而在于持续合理化的工作流程,在于如何协调所有的设计、开发、产品及其他相关团队,以产品体验的持续提升为目标而协同作业。</p> <p><img alt="" src="/sites/default/files/images/201804-2/minimum-viable-design-system-02.jpg" style="width: 600px; height: 447px;" /></p> <h3> 永无止境的MVP(Minimum Viable Product)</h3> <p>&ldquo;构建设计体系需要花费多少时间&rdquo;,这类问题包含一种隐含的假设,即&ldquo;设计体系有一个&lsquo;完成&rsquo;的时间点&rdquo;。经过前文的分析,我们知道了这一假设并不成立。&ldquo;设计体系&rdquo;是一种动态流程,它应该随时致力于设计工作的规范与优化,而其本身的构建过程则永无止境。</p> <p>从这个角度讲,设计体系就像某种持续性的MVP。一旦规范化的流程被建立起来并投入使用,设计体系就达到了&ldquo;最小化可用&rdquo;状态。接下来,随着产品的迭代,设计体系也会持续更新,但永远无法达到&ldquo;终极&rdquo;状态。随着业务需求的变化及产品复杂度的提升,设计体系也将永无止境的进化。</p> <h3> 以小为始,快步迭代</h3> <p>设计体系的存在,起始于团队意识到设计一致性的问题已经严重到需要通过新的工作流程加以解决的时刻。</p> <p>随着第一条设计约定的初步达成与实际运用,产品设计的复杂度就已经开始得到抑制。与传统的、大而&ldquo;完整&rdquo;的设计规范不同,动态的设计体系从诞生的一刻起就可以立刻形成价值。即便起初只对5种主要配色的命名进行约定并投入实用,至少在这一点上,设计工作流程也得到了改善。</p> <p>我个人甚至愿意相信,即便一个设计体系只包含一种配色的定义,只要能在团队内部达成共识、投入运用并保持迭代,也会比一套所谓的设计规范更有实用性和时效性。一个即刻有效的配色定义可以立刻降低设计熵值,而一套静态的设计规范从来都是过时的、无法得到执行的。</p> <p>所以,各位大可不必担心&ldquo;构建设计体系需要花费多少时间&rdquo;这样的问题 - 请接受&ldquo;设计体系是动态流程&rdquo;的现实,以小为始,快步迭代;我们将要与&ldquo;混乱&rdquo;、&ldquo;复杂&rdquo;进行持久战,其中的每一个小战场都至关重要。</p> <p>好运!</p> <p><span style="color:#a9a9a9;">英文原文:https://heydesigner.com/blog/minimum-viable-design-system/,作者:Marcin Treder,译者:C7210</span></p> <p><img alt="" src="/sites/default/files/images/s/QR-C(1).png" style="width: 450px; height: 450px;" /></p> <p><img alt="" src="/sites/default/files/images/s/Banner-PS-BFW-3x.png" style="width: 450px; height: 116px;" /></p> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li><li class=" taxonomy-term-reference-1"><a href="/point" typeof="skos:Concept" property="rdfs:label skos:prefLabel">观点</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/115" typeof="skos:Concept" property="rdfs:label skos:prefLabel">视觉设计</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/234" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计体系</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/235" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Design System</a></li><li class=" taxonomy-term-reference-7" rel="dc:subject"><a href="/taxonomy/term/16" typeof="skos:Concept" property="rdfs:label skos:prefLabel">原创翻译</a></li></ul> Sun, 22 Apr 2018 07:35:21 +0000 C7210 962 at http://www.beforweb.com http://www.beforweb.com/node/962#comments Design Systems 读书笔记 http://www.beforweb.com/node/960 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/icon-logo-ux-product-design-notebook-diary.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><div class="entry-intro"> <p>编者按:C问各位周五安,又是新的周末即将来到;这样讲起来会不会显得周末更加值得期待?藏在编者按里弱弱地讲几句就退下,格外珍惜这时光;微笑。即将到来的不止周末,更是四月;因人而异,但回头看过去的十几年,较大的变故通常发生在四月,从已知跨越到未知的时日充斥着不安与兴奋,如今这般,且行且欣赏。</p> <p>今天继续为各位介绍新的合作作者,来自爱奇艺的高级交互设计师Hesivell,带来一篇Beforweb过去不曾有的内容形式 - 读书笔记 - 关于设计体系,并配有涂鸦笔记风格的手绘插图;强烈推荐。&nbsp; - C7210</p> </div> <p>不知道大家还记得么,前几个月,Beforweb曾经推荐过一本书,SmashingMagazine 的 Design Systems。</p> <p>我也是这本书的读者之一,此时此刻在BFW聊这本书,似乎非常应景。</p> <p>这个体系像是渗透在产品中的一种语言,让产品人员、设计师、程序员用同一种语言交流,提升协作效率;又像是一个自动化智能化的工具,让整个团队进行自循环,尽量减少人工维护。</p> <!--break--><p><img alt="" src="/sites/default/files/images/201804-1/IMG_0105.PNG" style="width: 450px;" /></p> <p>类比起来,有点像是阿里的中台。无论如何也是很前沿的一个方向。</p> <h3> 12/25&nbsp; 什么是design system</h3> <p><img alt="" src="/sites/default/files/images/201804-1/1.jpeg" style="width: 600px;" /></p> <p>Design Systems 这本书的主线,讲的是一个叫做&ldquo;设计体系&rdquo;(design system)的工具。顾名思义,就是把整个产品&ldquo;体系化&rdquo;。</p> <p>对于产品中比较成熟的那些模块(比如社区的feed卡片格式),统一进行组件化,设计层面和开发层面统一命名共享资源,应用到业务线的后续迭代。这部分成熟模块就可以在产品中自循环,无需设计师后续维护了。</p> <p>而设计师的人工精力被解放出来,主要用于新功能的开发,新脑洞的爆炸,和产品方向的探索。</p> <h3> 12/26&nbsp; 有规律的产品</h3> <p><img alt="" src="/sites/default/files/images/201804-1/2.jpeg" style="width: 600px;" /></p> <p>其实我觉得每一款产品都有自己的规律。</p> <p>当你从系统层面俯视一个产品,就像站在高楼顶上俯视建筑结构一样。</p> <p>这时候可以看到在地面上看不到的一些规律。</p> <p>&mdash;&mdash;如果产品中每个模块的信息量、动效、颜色、轻重、语调,都在一开始被赋予了使用场景和理由,后面只要从中选取或者做必要的补充,就会在秩序和效率上有很大提升。</p> <h3> 12/27&nbsp; 原来产品的&ldquo;气质&rdquo;也是可以用系统化的方法去打造的</h3> <p><img alt="" src="/sites/default/files/images/201804-1/3.jpeg" style="width: 600px;" /></p> <p>如果任意提取一个页面,去掉LOGO和其它产品信息,那么你能认出这是个什么产品么?</p> <p>&mdash;&mdash;产品应该有一个清晰的&ldquo;人设&rdquo;才能给用户留下深刻的印象,要么风格鲜明,要么平易近人,总之设计要做得极致一些,才不会淹没在竞品群里。</p> <p>不过看了这本书我才知道,产品的气质这种抽象不可触摸的东西,也是可以通过系统化理性的方式来打造的。</p> <p>一种方法是自上而下定义品牌关键词,再融入具体样式;</p> <p>另一种方法是自下而上,梳理产品现有的与品牌关联的元素,比如配色、图标、版式,找出那些明显和品牌定位脱节的样式,梳理,精确化品牌调性。<br /> 两种方法当然也可以结合,双向打通。</p> <h3> 01/02&nbsp; &ldquo;万变不离其宗&rdquo;</h3> <h4> Patterns evolve,behaviors remain</h4> <p><img alt="" src="/sites/default/files/images/201804-1/4.jpeg" style="width: 600px;" /></p> <p>有人说在设计之初就要定义好产品的基本组件样式,但也有人担心说一开始限制太多会影响后续的迭代发展,或者产品迭代了之后样式也会有比较大的改动,反而会增加不必要的工作量。这也是我之前一直觉得矛盾的地方。</p> <p>这本书中的观点是,尽管随着时间的推移,基本组件的样式、组合方式、交互模式都会有所变化,但它们想要支持或者促进的&ldquo;用户行为&rdquo;是不变的。就比如无论用手机拍照,还是相机,都是为了支持拍照的行为。</p> <p>所以在最初应该列出产品中核心的用户行为,并基于它们来对样式进行定义和分组,就会有主线可循。</p> <p>另外:一个用户行为可以对应多个解决方案和样式。</p> <h3> 01/05&nbsp; 几种不同的变体可以归为统一样式</h3> <p><img alt="" src="/sites/default/files/images/201804-1/5.jpeg" style="width: 600px; height: 371px;" /></p> <p>类似的样式变体可以归为同一种样式,方便管理。</p> <p>例如book item,有用在发现页的,也有用在推荐位的。这时候它们的组成成分可能会有些不同。相同的部分,就是book item 通用的基本组成元素,例如标题;不同的部分,就是切合使用场景的元素,例如推荐位的推荐语,或发现页的标签。</p> <h3> 01/24&nbsp; 命名、共享和活用</h3> <p><img alt="" src="/sites/default/files/images/201804-1/6.jpeg" style="width: 600px;" /></p> <h4> 为什么要给组件命名?</h4> <p>主要是为了集体共享、方便识别和运用。比如在Sketch里,命名一个设计模块叫&ldquo;视频card-评论&rdquo;,那么对应的开发代码库里,这段代码也要叫&ldquo;视频card-评论&rdquo;,这样就保证设计师和程序员之间用一样的语言沟通,消灭代沟。</p> <p>就像语言一样,其中的词汇,需要流传和使用,才能不断强化;但如果词汇本身比较艰深晦涩那就不容易流传开来。因此命名简单明确,才能保证之后的使用方便。</p> <h4> 那么为什么要共享?</h4> <p>还是比作语言,普鲁士语和我大清朝的满文消失了就是因为知道它们的人太少了。同理,如果团队里大多数人都不知道设计体系的用法,那么设计体系还有什么意义呢。</p> <p>所以要让设计体系成为日常工具活用起来,提升效率,共享是最关键的。</p> <h3> 01/31&nbsp; 关于这个读书笔记系列</h3> <p><img alt="" src="/sites/default/files/images/201804-1/7.jpeg" style="width: 600px; height: 274px;" /></p> <p>随着阅读进度的深入,我发现我对design system的理解也越来越不一样。</p> <p>本书分为两个部分,特别是读到两部分过渡的时候,感触非常深。</p> <p>前面我还停留在浅层次或者相对泛的&ldquo;产品要系统化&rdquo;这种概念,然而确实,回顾这过程中记下来的每个点,比如产品要明确气质,比如拆分模块要以行为目的为导向,比如设计体系的重点不在构建而在使用&hellip;&hellip;每一次,我都会用这些新的观点审视我之前的思路,或者反思哪里是不足,哪里需要修补;每一次,对于我来说都像恍然大悟,都是一个新的小起点。</p> <h3> 03/29&nbsp; 就是今天</h3> <p>产品设计成体系之后,设计师会不会失业?</p> <p><img alt="" src="/sites/default/files/images/201804-1/8.jpg" style="width: 600px;" /></p> <p class="figure-caption">图源:Salmorejo Studio<br /> 献给宇宙 / 以及茫然未可知而又充满了机遇的未来 / 以及猫控主页君C7210</p> <p>最后整理这一系列笔记的时候,在最初的介绍部分,我想到design system有点类似阿里的中台。而传说中,中台就是&ldquo;一个可能会让设计师失业的系统&rdquo;,因为大部分的设计流程到后面都可以集成化、模块化、自动产出。</p> <p>那么,哪些设计师会随着设计的自动化趋势而失业呢?哪些又完全不会?我想这应该是我们所有设计师应该一直持续思考的问题。</p> <p>我相信,这是一个开放式结局。</p> <p>&nbsp;</p> <p class="rtecenter" style="text-align: center;"><img alt="" src="/sites/default/files/images/s/Avatar-Hes-1.png" style="width: 140px; height: 140px;" /></p> <p class="rtecenter" style="text-align: center;"><strong>Hesivell</strong></p> <p class="rtecenter" style="text-align: center;">&lceil; 不爱跟码农谈心喝酒的设计师不是好段子手 &rfloor;</p> <p>&nbsp;</p> <p><img alt="" src="/sites/default/files/images/s/%E8%B5%9E%E8%B5%8F%E7%A0%81.jpeg" style="width: 450px; height: 450px;" /></p> <p><img alt="" src="/sites/default/files/images/s/Banner-PS-BFW-3x.png" style="width: 450px; height: 116px;" /></p> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li><li class=" taxonomy-term-reference-1"><a href="/point" typeof="skos:Concept" property="rdfs:label skos:prefLabel">观点</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/234" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计体系</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/235" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Design System</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/244" typeof="skos:Concept" property="rdfs:label skos:prefLabel">读书笔记</a></li></ul> Sun, 01 Apr 2018 08:02:10 +0000 C7210 960 at http://www.beforweb.com http://www.beforweb.com/node/960#comments 使用Sketch Libraries构建组件库/设计体系 http://www.beforweb.com/node/943 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/logo-icon-sketch-app-new.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>昨天降了温,一下子从不温不火的暖湿秋天变成了冬日的样子。</p> <p>眼看着一年距离结束已不遥远,偶尔翻看年初立下的一些目标,多数已有完成,略感慰藉。这种所谓慰藉之后不久,通常会买些什么大件的东西来犒劳自己一类。多巴胺无时无刻不在寻找着机会为宿主制造一些对于奖励的渴望罢了。</p> <p>会播放John Coltrane的咖啡店都是好咖啡店。我若开一间自己的咖啡店,怕是会终日放着JC不停歇;与村上春树的原则完全相反。我想我可能付不起足够的薪水去请有名的乐队来表演;不如请一些老伙计过来吧,只要为他们提供足够的啤酒。</p> <p>本期是一篇很长的译文,<a href="https://blog.usejournal.com/using-sketch-libraries-to-build-a-better-ui-design-system-part-1-26f5660f3c98">Using Sketch Libraries to build better design systems</a>,从理论方法到实践演示,一应俱全;耗掉了两个周末的时间终于完成,期间原文还有过一次更新。其中的流程思路和我在做<a href="http://beforweb.com/node/901" target="_blank">WireframeKit For iOS(线框稿风格Sketch组件库)</a>以及现在团队内部的组件库时所用的大致相同,个人比较推荐。</p> <!--break--><p>另外说,Sketch 48 Beta已经开始提供Colors Management方面的功能,又是一次体系化角度的重要更新。</p> <p>下面进入译文。</p> <div class="entry-intro"> <p>注意:Libraries功能仅在最新的Sketch 47当中提供。</p> </div> <blockquote><p>所谓&ldquo;设计&rdquo;,就是在一系列约束条件下构建解决方案的过程。</p> </blockquote> <p>- Adam Morse</p> <p>从某种程度上讲,设计体系(Design System)便是这样的一种约束 - 诸如配色、图标、按钮等一系列设计语言要素共同构成了标准化的体系,为设计决策提供着指引。</p> <p>遵从于这样的标准化体系,设计流程能够得到有效加速;同时,设计模式的复用性与一致性也将得到提升,产品设计方案整体更具扩展性,更易于维护。</p> <p>然而在现实当中,创建和维护标准化设计体系的方式却多种多样。Sketch是我们在设计工作当中的利器,可以帮助我们简化设计体系的创建流程,但其自身在各方面存在的问题也是无法忽视的。</p> <h3> 问题所在</h3> <p>在Sketch 47为我们带来Libraries之前,Symbols一直是Sketch当中最为重要的功能之一,同时也是构建设计体系的关键能力。Symbols用于创建可复用的界面元素,有助于维护设计方案的一致性。然而一直以来,这一机制的作用范围仅限于文档内部,除非借助第三方插件的帮助,否则Symbols无法在不同的文件之间保持同步。</p> <h4> 这为什么是问题?</h4> <p>对于小项目来说,这没什么大不了。你可以将全部设计方案,甚至包括高保真原型、流程图一类都塞到一个文件当中,Sketch处理起来也不会产生什么问题。</p> <p>然而,情况会随着项目规模的扩大而有所不同。出于性能效率或协作方面的考虑,我们通常需要将项目打散到不同的Sketch文件当中;这时,Symbols同步共用方面的问题就会暴露出来。</p> <p>我们的团队有三个产品用到了同一套Symbols,这里的挑战就在于如何确保Symbols在不同项目之间的同步性。这三个产品都是很大的项目,各自的源文件都包含上百个画板(Artboard),因此难以通过单一Sketch文件来承载,否则文件将变得非常庞大。</p> <p><img alt="" src="/sites/default/files/images/201711-2/01-sketch-libraries-design-system.png" style="width: 600px; height: 372px;" /></p> <p class="figure-caption">一个Sketch文件承载了整个组件库</p> <h4> 从前的处理方式</h4> <p>我们曾经使用一套Sketch模板(Template)来集中放置所有的Symbols,这种方式参考了<a href="https://blog.marvelapp.com/creating-maintaining-marvel-style-guide-sketch/">原型制作工具Marvel官方的设计规范</a>创建方法。在此基础上,我们进行了一定程度的扩展,例如在不同的Sketch文件当中通过Craft插件统一调用Symbols模板文件。</p> <p><img alt="" src="/sites/default/files/images/201711-2/02-sketch-libraries-design-system.gif" style="width: 600px;" /></p> <p class="figure-caption">使用Craft插件构建组件库</p> <p>事实上,我个人并不推荐这种方式。文件尺寸的确得到了控制,Symbols的来源也得到了统一。但问题在于,一旦模板当中的Symbols发生变化,对于那些已经插入到不同文档当中的Symbols,我们无法进行同步性的更新。</p> <p>Symbols功能的本质目标是使项目更易于创造和维护。然而,强大的复用能力只是其中的一个方面;对于那些已经被插入到不同文档当中的Symbols,你根本无法进行统一管理与更新。</p> <p>幸运的是,Sketch 47为我们带来了Libraries功能。</p> <h3> 解决方案</h3> <p>Libraries功能可以帮助我们创建独立的、能够被多个文件统一调用的Symbols库。这种机制已经有些类似于前端开发者们所熟悉的Sass了。不仅如此,你还可以对Libraries进行嵌套。</p> <p>大体上讲,如今你可以将不同类型的Symbols分别存放在不同的Sketch文件当中各自作为独立的Library,譬如配色定义、图标、按钮、表单元素等等;其他项目文件则可以统一调用这些源文件当中的Symbols。当你修改了Libraries源文件,相关的变化也会同步更新到所有的项目文件当中。</p> <p>这种统一管理和调用的机制可以为工作带来诸多益处,包括:</p> <ul> <li> 减小文件尺寸</li> <li> 增强Sketch的性能表现</li> <li> 提升界面元素的统一性</li> <li> 提升项目整体的可维护性</li> </ul> <p>Sketch官方团队是这样诠释Libraries功能的:</p> <blockquote><p>一个Library本质上就是一个普通的Sketch文件,其中的Symbols可以被其他Sketch文件调用。如果你编辑了Library当中的Symbols,那么调用了该Library的其他Sketch文件便会收到更新通知,你可以对变更进行预览、对比和确认,使这些Sketch文件所调用的Symbols自动更新至最新版本。</p> </blockquote> <p>- <a href="http://beforweb.com/node/938" target="_blank">Sketch 47 Libraries功能图文详解</a></p> <h3> 使用Sketch Libraries创建组件库</h3> <p>在本文接下来的部分当中,我将展示如何使用Sketch Libraries功能创建UI组件库。不过在此之前,我们还需要明确一些思路与原则。</p> <h4> 像开发人员一样思考</h4> <p>打造设计体系的过程中,设计师们要试着像开发人员一样思考。</p> <p><strong>D.R.Y - Don&rsquo;t repeat yourself</strong></p> <p>组件库的基本概念就是逐层创建可复用的UI元素,保持文件的轻量化以及设计方案的一致性。</p> <p><strong>从&ldquo;原始元素&rdquo;入手</strong></p> <p>我们所创建的任何一个组件都是由若干&ldquo;属性&rdquo;组成的。这些属性就是设计体系当中最为&ldquo;原始化&rdquo;的元素。开发人员会在代码当中为这些属性创造各自的变量,以提升代码的复用性;对于设计师来说也是同理,我们可以为各种原始化UI元素创建Libraries,以便逐层构筑更高级别的组件。</p> <p><strong>原子化设计理论</strong></p> <p>为了确保组件库的扩展性,我将Brad Frost提出的原子化设计理论(Atomic Design)作为指导。这套理论简单易行,很容易理解。</p> <p><img alt="" src="/sites/default/files/images/201711-2/03-sketch-libraries-design-system.png" style="width: 600px;" /></p> <p>简而言之,原子化设计的灵感来自于现实世界当中的分子结构。UI当中颗粒度最小的元素,即&ldquo;原子&rdquo;,组成了颗粒度较大的控件,即&ldquo;分子&rdquo;;而诸多分子又组成了更加复杂的组件与模块,即&ldquo;有机体&rdquo;。</p> <h4> 将不同类型的Symbols放在各自的Library文件中</h4> <p>当然,如果你愿意,你仍然可以将所有组件都放置在同一个Library文件当中;而我的建议(也是我们现在的做法)则是为每种类型的Symbols各自创建一个独立的Library文档。</p> <p>类似于开发人员使用Sass partials的方式,调用多个Libraries文档可以使我们的设计体系更为优雅,更易维护。经过合理拆分的Libraries文档将更有利于被不同的项目调用;在需要的时候,也可以更加方便地进行扩展。</p> <p>参照&ldquo;原始元素&rdquo;的思路,我们将从最为基础和核心的UI元素入手,包括颜色、图标等等,这些元素将在整个设计体系范围内被使用到;所有&ldquo;原子&rdquo;、&ldquo;分子&rdquo;、&ldquo;有机体&rdquo;级别的UI元素也正是由这些原始元素所构成的。</p> <p>我们首先要对全局所用到的各类颜色进行定义。</p> <h3> 第一步:创建新的Sketch文档,用于颜色定义</h3> <p>对于团队项目,我会在Sketch文件名当中统一添加&ldquo;AIN&rdquo;作为前缀,例如&ldquo;AIN-colors&rdquo;等等,以便与其他项目进行区分。当然,命名方式和习惯因人而异,如果你和我一样需要处理很多不同的项目,通过前缀进行区分的方式或许值得考虑。</p> <p><img alt="" src="/sites/default/files/images/201711-2/04-sketch-libraries-design-system.png" style="width: 600px;" /></p> <p>我会为设计体系当中的每一种颜色生成一个Shared Style,并按照不同的作用进行分类,包括&ldquo;brand&rdquo;、&ldquo;greyscale&rdquo;、&ldquo;UI&rdquo;等等;具体的分类方式就是在Shared Style命名当中通过&ldquo;/&rdquo;符号表示层级结构,Sketch会识别到该符号,并自动生成相应的架构。</p> <p><img alt="" src="/sites/default/files/images/201711-2/05-sketch-libraries-design-system.png" style="width: 600px;" /></p> <p>接下来,我会为每一种颜色制作一个Symbol,并使用Symbol Organizer插件在Symbols页面当中对它们进行组织 - 在层级化命名方式的辅助下,Symbols页面将自动呈现出清晰的架构体系。</p> <p><img alt="" src="/sites/default/files/images/201711-2/06-sketch-libraries-design-system.png" style="width: 600px;" /></p> <h3> 第二步:将颜色定义文档添加到Libraries体系</h3> <p>完成了颜色定义之后,我们需要将这份Sketch文档添加到Libraries体系当中。设计体系当中所有原子级元素的定义都需要这一步骤。</p> <p>在顶部菜单栏选择&ldquo;Sketch &rsaquo; Preferences&rdquo;,然后进入&ldquo;Libraries&rdquo;选项卡,点击&ldquo;Add Library&rdquo;按钮,选择我们在上一步里创建的Sketch文档。</p> <p><img alt="" src="/sites/default/files/images/201711-2/07-sketch-libraries-design-system.png" style="width: 600px; height: 564px;" /></p> <p>如图所示,我将AIN-colors文档添加到了Libraries体系当中,这样我就可以在任何其他Sketch文件里对其进行调用了;这便是Libraries功能的强大之处。</p> <p>怎样使用这些颜色Symbols呢?在接下来创建图标Library的过程中,我将进行演示。</p> <h3> 第三步:创建新的Sketch文档,用于图标定义</h3> <p>类似于我们在第一步当中的做法,这一次我们对图标进行定义。新文档名为&ldquo;AIN-icons&rdquo;,与之前的&ldquo;AIN-colors&rdquo;文档保存在相同的路径中;之后所有原子级UI元素的Libraries文档也都将被保存在这里。</p> <p><img alt="" src="/sites/default/files/images/201711-2/08-sketch-libraries-design-system.png" style="width: 600px; height: 373px;" /></p> <p>每个图标都被放置在相同规格的24x24像素的画板当中,下面铺着24x24像素的透明图层以确保规格统一。然后我会从AIN-colors Library当中选择恰当的颜色Symbol插入到图标画板当中,覆盖在图标图层之上,并将其尺寸调整为24x24像素。</p> <p>接下来,将图标设置为蒙板(按住Control键,点选图标,在菜单中选择&ldquo;Mask&rdquo;),如此一来,我们刚刚从AIN-colors Library当中插入的Symbol就能将其颜色附着到图标形状的蒙板上了。</p> <p><img alt="" src="/sites/default/files/images/201711-2/09-s-sketch-libraries-design-system.png" style="width: 600px;" /></p> <p>需要注意,在Sketch左侧的图层列表当中,带有连环图标的便是从外部Libraries插入的Symbols。</p> <p><strong>这里的核心思路在于Libraries的嵌套</strong>。通过这种方式,每当我需要修改颜色定义,只需要在AIN-colors文档中进行编辑,然后所有用到了这个颜色的图标或其他UI元素就会自动更新了。</p> <p>现在,我们就可以将图标画板转换为Symbols了。需要注意的是,对于这些图标画板,要确保在右侧检查器中选中&ldquo;Adjust content on resize&rdquo;;此外还要将图标的Resizing选项设置为四边同时吸附,并锁定宽高比例,以确保图标Symbols在实际使用的时候可以被灵活地调整大小。</p> <p>重复这一过程,直到完成所有图标Symbols的定义。期间同样要注意层级化的命名方式,以便最后可以通过Symbols Organizer插件将它们组织起来。</p> <p><img alt="" src="/sites/default/files/images/201711-2/10-sketch-libraries-design-system.png" style="width: 600px;" /></p> <h3> 第四步:将图标定义文档添加到Libraries体系</h3> <p>具体方法与我们在第二步当中描述的相同。</p> <p>此时,我们已经完成了两个Libraries文档的创建,对于我的情况来说,就是&ldquo;AIN-colors&rdquo;和&ldquo;AIN-icons&rdquo;。现在我们的图标已经可以通过Libraries的方式被其他文档统一调用了。</p> <p><img alt="" src="/sites/default/files/images/201711-2/11-sketch-libraries-design-system.png" style="width: 600px;" /></p> <h3> 第五步:重复以上步骤,对其他元素进行定义</h3> <p>希望前面四步的介绍已经可以帮你了解到流程的主旨。</p> <p>你可以参考这样的方式继续完善其他基础元素的定义,期间始终保持Libraries的逐层嵌套。</p> <p>在我们的AIN设计体系当中,同类元素还包括按钮、表单元素等等;这些Libraries文档与&ldquo;AIN-colors&rdquo;和&ldquo;AIN-icons&rdquo;一起被保存在同一个路径当中,当我开始制作分子或更高级别UI元素的Libraries时,便会进行调用。</p> <p><img alt="" src="/sites/default/files/images/201711-2/12-sketch-libraries-design-system.png" style="width: 600px;" /></p> <h3> Libraries的更新</h3> <p>随着产品的进化,你总会需要对核心Libraries当中的某些元素进行更新。Sketch提供的机制使这件事变得很简单,你只要在Libraries文件当中像操作普通Symbols那样进行修改便可以,然后所有调用过这些Symbols的Sketch文件都会收到更新提示(Sketch界面右上角)。点击提示信息,查看变更并进行确认,所有更新工作就会自动完成。</p> <p><img alt="" src="/sites/default/files/images/201711-2/13-sketch-libraries-design-system.png" style="width: 600px;" /></p> <h3> 接下来</h3> <p>完成了所有原子级别UI元素的定义之后,你就要着手整理更为复杂的元素了,例如&ldquo;分子&rdquo;,然后是&ldquo;有机体&rdquo;,等等。整个过程中,你都可以对之前创建的各级Libraries进行嵌套,通过小颗粒元素组合大颗粒元素。</p> <p>以此类推,这套基于Sketch Libraries机制逐层构建的设计体系终将越发复杂和完善,并最终有能力帮你实现完整的界面。届时,你便可以在任何项目当中对这套体系进行调用。</p> <p>在本文的后续部分中,我将带各位一起了解一下创建更为复杂的组件的过程,可能包括页头、导航、卡片视图、页脚等部分;同时也将展示如何在实际当中使用这套设计体系。</p> <p>需要说明的是,原子化设计理论只是一种指导原则,而非硬性规则,你最终还是需要一边结合理论,一边根据自己产品的特定情况来判断以怎样的方式对UI元素进行层级划分。</p> <p>此外,关于Libraries在多设备之间的同步使用,我个人目前还没有涉及到这方面的实际运用。正如Sketch在<a href="http://beforweb.com/node/938" target="_blank">官方文档</a>之中建议的,你可以通过Dropbox、Google Drive或类似的存储服务来实现同步;这对于团队共享和协作将非常有用。</p> <h3> 小结</h3> <p>在本文中,我们一同了解了如何使用Sketch Libraries构建模块化的UI组件库/设计体系,希望此时你已经感受到了Libraries功能的巨大潜力。</p> <p>如果你是设计团队中的一员,或是一名需要更好的方式来管理项目的独立设计师,那么不妨试着将Libraries功能运用到设计流程当中 - 这个自Symbols以来意义最为重大的新功能将能越发有效的帮助我们构建和维护设计体系。</p> <p>你可以<a href="https://www.dropbox.com/sh/m63vzakr0oolyvc/AACrJzxtVYpEJoD0IXF14jI2a?dl=0">下载我提供的范例项目</a>作为参考,其中包括了颜色、图标、按钮等元素的定义,以及一个简单的项目案例。希望这套范例能帮你更好的理解本文的内容。需要注意,你需要更新到Sketch 47才能打开这份文档。</p> <h3> 相关资源</h3> <ul> <li> <a href="https://medium.com/ux-power-tools/sketch-libraries-how-they-work-and-the-crazy-stuff-you-can-do-with-them-fc10f142ac80">Sketch Libraries</a> by Jon Moore</li> <li> Brad Frost&rsquo;s<a href="http://atomicdesign.bradfrost.com/chapter-2/"> Atomic Design Methodology</a></li> <li> Pablo Stanley on<a href="https://www.youtube.com/watch?v=suP1sOU4J3E&amp;t=2s"> Sketch Libraries</a></li> <li> Airbnb: <a href="https://airbnb.design/building-a-visual-language/">Building a Visual Language</a></li> </ul> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li><li class=" taxonomy-term-reference-1"><a href="/point" typeof="skos:Concept" property="rdfs:label skos:prefLabel">观点</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/115" typeof="skos:Concept" property="rdfs:label skos:prefLabel">视觉设计</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/234" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计体系</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/235" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Design System</a></li><li class=" taxonomy-term-reference-7" rel="dc:subject"><a href="/taxonomy/term/236" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Atomic Design</a></li><li class=" taxonomy-term-reference-8" rel="dc:subject"><a href="/taxonomy/term/227" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Sketch组件库</a></li><li class=" taxonomy-term-reference-9" rel="dc:subject"><a href="/taxonomy/term/125" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计规范</a></li><li class=" taxonomy-term-reference-10" rel="dc:subject"><a href="/taxonomy/term/164" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Sketch</a></li><li class=" taxonomy-term-reference-11" rel="dc:subject"><a href="/taxonomy/term/16" typeof="skos:Concept" property="rdfs:label skos:prefLabel">原创翻译</a></li></ul> Mon, 20 Nov 2017 13:27:57 +0000 C7210 943 at http://www.beforweb.com http://www.beforweb.com/node/943#comments