下载掌阅APP，畅读海量书库
立即打开
在产品开发迭代过程中，设计师的工作职责一般包含前期调研、方案设计、设计评审和开发跟进。如果想让自己的设计稿在设计评审时一稿通过，除了理解需求，掌握以用户为中心或者以业务为中心的设计方法外，设计方案是否能被实现也是很重要的。上述每一个设计步骤都和技术息息相关，下面笔者将对此一一讲解。
在互联网产品设计中，设计师在设计方案前一般都会做竞品调研和分析，但是设计师大多都是围绕着产品本身进行分析，包括功能、界面、交互设计等，也就是对竞品看得见的部分进行分析。其实除了分析竞品看得见的部分外，还要分析看不见的部分，这在智能硬件或者人工智能领域尤其重要，设计师需要关注值得关注的体验设计背后用了什么关键技术。以共享单车为例，用手机解锁美团单车背后的原理是什么？笔者尝试分析一下整个交互流程，有以下关键点。
（1）每辆美团单车都需要有自己独一无二的ID信息，当用手机扫描单车上的二维码时，云端将授权信息发送给手机。
（2）用户通过手机蓝牙将解锁指令和授权信息发送给单车的智能锁，智能锁获得授权信息后解锁，并将解锁成功的信息发送给手机。
（3）用户的手机将解锁成功的信息发送给云端，云端开始计费。
结合解锁、锁车等交互流程大概能判断出美团单车的智能锁包括什么硬件模块，当然也能直接上网查看别人上传的拆解报告，这样在设计新的智能单车时就能判断出需要考虑哪些技术因素。除了竞品分析，前期调研还应该分析我们的设计需要做什么？还可以做什么？这时候工业界公布的信息和专利以及学术界的研究都能帮助设计师了解技术的可行性和边界在哪里。那么，设计师应该如何做相关的调研？笔者认为有以下三点。
（1）多看发布会。例如，每年苹果的WWDC和Google的I/O大会，除了主论坛还有各种分论坛，从这些论坛上能了解到苹果和Google的最新动态和历年的关注事项。举个例子，在WWDC 2020的Design for Intelligence分论坛上苹果设计师解释了苹果怎么利用Shortcuts、Siri Suggestion和Clips打造基于意图理解的AI设计，这是苹果首次公布自己关于AI和设计融合的想法。在WWDC 2021上苹果设计师讲解了空间交互的设计规范，空间交互有可能成为苹果下一阶段的重心，从macOS和iPadOS的多屏联动以及新发布的AirTag也能验证该可能性。
（2）多了解每家公司申请了什么专利。通过了解每年各大科技公司和实验室在某个领域申请的专利数量，能大概了解一项技术的发展趋势是什么样的，是开始布局、技术成熟、布局完成还是技术已经被放弃。专利检索很考验设计师的搜索技巧和工具，如果只想初步了解，可以通过免费的Google Patents搜索想了解的专利内容，通过标题、权利要求和保护范围能粗略知道这篇专利讲了什么；如果搜索不到可以利用Incopat等付费工具。
（3）多阅读某个领域会议和期刊上的论文，例如人机交互和人因研究领域的CHI、座舱领域的AutoUI等。学术界不需要过多考虑工程实现和商业落地，所以能比较自由地探索新方向，但这也意味着部分教授做的事情有可能“不靠谱”，读者在阅读论文时尤其要注意这一点。
设计师结合用户需求和技术可行性综合考虑整体方案能有效避免设计评审时为开发人员带来的技术挑战，在后期开发跟进和设计还原时也能减少不必要的麻烦。以互联网设计为例，交互设计师和UI设计师在设计时需要考虑的技术细节是不同的，但又彼此有关。
交互设计师在画设计稿时重点关注的事项包括交互框架的合理性和可复用性。合理性包括交互框架和交互流程是否匹配，重点在于每个控件、页面和流程的点击、跳转逻辑是否畅通。以长页面加载数据为例，当用户进入某个页面时，App从服务器下载数十个甚至数百个资源，App会白屏或者卡顿一段时间。为了解决这个问题，不懂技术的设计师可能会采取分页加载的设计，也就是用户滑到页面顶部点击“加载更多”按钮或者通过手势触发“加载更多”的交互事件。但如果设计师懂技术，在数据加载这个细节上可能会有更好的解决方案，那就是采用懒加载（Lazy Loading，也叫延迟加载）策略，相关细节会在本书后续章节讲解。
可复用性更看重的是设计师是否熟悉当前平台的设计规范和实现策略。例如，自己设计的控件/组件在样式和功能上是否和当前设计已有的或者平台的控件/组件设计规范保持一致，如果不一致需要开发人员重新实现一套新的控件/组件库。在这一点上如果没做好，可能每个页面的控件和组件调用的是不同开发人员写的库，后续维护成本相当高。现在设计行业逐渐推广的原子化设计和设计系统也是为了该目的，复用程度高的设计对于开发人员来说就是调用一段甚至一行代码，所以设计师在设计相关流程时可以提前和开发人员沟通，这样有助于减少双方的工作量和后期沟通成本。
UI设计师在画设计稿时重点关注的是界面的可复用性和美感。可复用性包括App界面如何适配不同平台以及不同大小的屏幕，之前设计的控件/组件样式是否适合用于当前的需求。设计做好适配前提是了解响应式设计该怎么做，以及将这套策略和开发人员沟通清楚，包括如何通过百分比来控制控件/组件的大小和间距；如何通过界面布局和交互流程将一套设计自适应计算机和手机屏幕，这些工作都需要和交互设计师以及开发人员协商一套可用的交互和技术规则。有些UI设计师为了保持当前界面的美感会设计出和其他界面不同的控件和组件，这对于自己、组内其他设计师以及开发人员来说都不是一件好事，因为整套设计变得不好维护。在设计时UI设计师可能会重新调整交互设计稿中控件/组件的大小和摆放位置，这时候UI设计师应该考虑这些元素的摆放规则是什么，是居左、居中还是居右？每个元素之间的关系是什么？元素和容器之间的层级是什么？UI设计师在设计时可能没关注这些细节，但这些细节会影响整个界面的技术实现。因此，设计师在画稿时结合技术实现考虑设计可行性，能有效提升和上下游的沟通效率。
设计师在和产品经理、开发人员一起评审设计方案时，开发人员一般会提出各种问题来消除方案无法实现的可能性。这时候如果设计师无法解释，开发人员的回答很有可能是“做不了”，这意味着设计师要重新改稿。“做不了”其实分3种情况：
（1）能做但时间不允许，这时候更多是一种博弈，如果设计师能提前预估工作量，可以和开发人员协商时间问题。
（2）开发人员一时没有想清楚技术的可行性，如果设计师了解技术细节，可以帮助开发人员解决相关问题。
（3）由于时间、技术成本高，真的无法实现，这时候设计师只能重新改稿。
设计师前期做好技术调研并在设计方案时提前考虑好各种技术问题，能有效解决前面两种情况产生的问题，避免第三种情况的发生。在设计评审时，如果设计师能站在开发人员的角度阐述设计方案，就有助于开发人员了解设计师的想法。久而久之，当设计方案长时间没出现技术问题，设计师和开发人员之间就能逐步建立良好的信任，这对于双方的后续合作有着较好的作用。
当设计方案进入开发流程后，设计师最害怕的是开发人员突然说“这个设计做不了”，从而重新梳理整个设计方案。为了避免该问题，设计评审时双方应该达成共识并产出纪要；但有时候确实避免不了这种情况的出现，这时候设计师最应该做的就是和技术人员坐在一起排查技术问题和风险，这考验设计师的技术水平和沟通能力。笔者在以往工作中偶尔会遇到这种现象，这时候需要了解清楚是什么原因导致做不了，是技术架构、网络还是系统底层？这些问题需要双方站在全局角度一起去思考，解决的办法很多，只是看大家有没有探索出来。如果真的没有解决方案，只能结合问题和关键点重新梳理设计方案，但这种情况笔者遇到的甚少，如果前期调研、方案设计和设计评审三个流程充分思考过设计背后应该采用哪种技术方案，就能有效避免该情况的发生。
看完本章内容，相信读者应该大概了解了设计师为什么要懂点技术。在笔者的过往工作中，发现设计师多多少少会提到希望自己能学点HTML和CSS知识，其背后大部分的需求都跟上文内容有关。设计师觉得学点HTML和CSS就能掌握技术其实是一个很片面的想法，因为HTML和CSS都算不上编程语言。HTML中文名是超文本标记语言，它通过标签将网络上的文档格式统一，使分散的互联网资源连接为一个逻辑整体；而CSS中文名是层叠样式表，它是一种样式表语言，用来描述HTML呈现。技术也不仅仅是编程和代码，在计算机相关专业里需要掌握的知识还包括网络工程、操作系统、算法、数据库等，编程和写代码只是程序员学习和应用这些知识的手段而已。在大学里系统掌握一套技术体系都需要花4年的时间，设计师不要觉得学点代码就能把开发人员过去4年学到的知识一下子都掌握了。
那么设计师应该重点掌握哪些技术知识？笔者认为，技术原理、技术架构和计算思维才是设计师应该掌握的。就像技术架构师可以不写代码，但不能不懂这些内容。技术原理能让架构师知道这门技术是怎么运用的，它的上下限分别在哪里；技术架构则是像建房子一样，将不同的技术有序组合；而怎样搭建出根基稳但又便于拓展的技术架构归根到底在于架构师的计算思维能力。笔者希望读者读完本书后，能像技术架构师一样站在技术上层思考问题，这才是对设计师来说价值最大的地方。