Be open, and open again

2019年下半年至2020年初，参与了两个项目，一个是虚拟货币交易平台，另一个是企业情报平台。都是大平台搭小团队，在设计和开发层面的协作大都以设计师负责产品、设计及前端UI，工程师直接基于 HTML&CSS 原型应用开发来确保应用的质量。

以下是相关经验总结：

项目的客户情况大致有两类，一类（A类）是自己拥有全职设计师，会用 Sketch 输出高保真视觉设计稿，并通过设计协作工具分享给开发供应商；另一类（B类）只输出需求、数据及平台搭建所需基础设施，供应商则提供项目管理、产品设计、开发及维护支持。

因为不是专业的数字产品管理从业者，B类客户的需求多以文本或 PowerPoint 表达其产品用途及阶段性目标。数据资源分为内部数据和第三方数据，通常以 excel, csv 或来自第三方的 API 数据接口呈现。由于网站所有者及合规性要求，客户会有专门的IT负责人提供基础设施架构设计方案实现对接。

数字平台项目最贵的资源成本是人。项目一方面需要为客户输出价值，即高质量的产品，另一方面也需要保证己方盈利；那么从项目成本及交付质量两方面进行考量，项目经理需要选择最合适的人在有限的时间内交付达到预算相当的产品价值输出。

人多 ≠ 量大质优

一个项目的产品输出的质量与项目参与人员的数量并没有直接的关系。项目中设计与开发人员多并不一定会带来更高质量的产品输出，但一定会增加人与人之间信息同步的沟通成本，这是项目参与者尤其是项目经理需要警惕的。

项目启动后，无论团队是否践行敏捷开发框架，在项目初期客户都免不了会在需求细节上发生一定程度的变更和调整，因为在项目伊始没有可视的高保真界面和真的可以操作体验的原型的情况下，有时客户也不确定某些功能是否真的需要，他们也可能会在看到了初步的设计原型之后产生了新的想法并希望能予以实施应用。一些需求在设计师手上虽然只是几小时或几分钟的效果实现，但到了开发阶段，可能需要数人数天的通力攻关。这类需求若到了开发阶段才发生变更，而项目预算并未覆盖此类需求变更，将削减供应商的利润空间，甚至造成损失，也便成了所谓“吃力不讨好”。

为了让客户在项目初始阶段对需求和实现能有可视化的甚至直接上手体验的认知，避免到了开发阶段才发生调整，尤其是网站整体信息架构和大方向调整，设计师应尽早于需求定义阶段构建原型。

贴士一：参考品牌规范构建初步原型

Tips no. 1: refer to brand guidelines

若客户属于创业公司，还没有建立品牌规范，则产品原型可先以灰度效果实现；

若客户已有品牌规范，尽早索取并参考其中的色彩、字形等用于产品。

需要留意的是一家公司的品牌规范一般由市场运营团队（marketing）制订，多为视觉设计师为传统物料制作而设计。要知道人眼对打印在纸上的颜色和呈现在屏幕上的颜色的感知能力是不同的，数字世界对屏幕上颜色是否能够最大程度方便人类识别是有标准的，若色彩的对比度低于相关标准，字体的大小低于一定的尺寸，将会造成可读性及无障碍访问问题，导致产品不可用。在这种情况下，UI 设计师应在产品付诸开发前主动给出色彩及字号调整建议，帮助客户理解其背后的可用性原理及对用户体验的帮助，而非盲目照搬。

在”好看“之前，用户体验设计师应优先保证设计”可用“。“可用”的大致标准是在没有额外辅助的情况下，用户能通过理解产品界面，独自完成目标任务。

贴士二：撇开传统工具束缚，拥抱高效协作

Tips no. 2: forget Adobe and Sketch… and embrace the efficient tool for collaboration

如果设计师理解网站前端开发的知识和流程，设计时将可以有更好的设计系统思路应用。无论项目是否会安排专门的 web 前端开发工程师，相关前端知识都可以帮设计师更好地理解设计元素各个属性应用到实际产品时的关系，帮助你更好地定义设计系统。

撇开“设计师是否有必要会写代码”这个话题依然存在争议，聚焦“如何更快更高效地产出客户期望的产品”，以下是一些经验，此前主要用于基于 web 的开发。

能力背景：具备用户体验设计知识体系，熟悉 web 前端开发语言及相关命令行，理解 W3C可用性指南相关标准。

贴士三：以共赢的心做专业的事

Tips no. 3: be professional for success business and happy users

客户可能拥有自己 in-house 的设计师，直接输出桌面端或web端单一尺寸高保真设计稿。作为供应商的设计师，你可以：

评审设计，发现其中存在的问题（尤其是导航和信息架构），并给出解决方案建议。当然，首先需要和己方的负责和客户对接的人员沟通一致。这一步的目的不是给客户的设计挑刺，而是以专业的视角给客户以建议，避免客户入坑，希望能够帮助客户的产品最终成功争取到用户的口碑，进而实现双赢。
若客户提供的设计确实出现了有违体验设计原则的问题且不愿接受建议，给出潜在风险提示，并执行客户最终的决定。当然，事后也需要自我反省是否在给出建议的语言和方法上存在问题，是否有可疑优化改进的地方。此处推荐 Tom Greever 的书”Articulating Design Decisions“.

贴士四：忘记职称，高效协作

Tips four: forget the title, work for efficient and high quality deliverables

作为用代码构建产品原型的设计师，如何与开发者共享原型及变更版本，实现协作？

学会使用 git 版本控制语言，至少理解其基本的 commit, push, pull 命令间的关系。如果不想敲代码，可以用 SourceTree 等可视化的版本控制桌面端 app。这样工程师就可以快速获取你的基于前端 HTML, CSS 及 JavaScript 的原型，并通过代码比对工具及 merge 等命令行快速整合至开发版
Web 样式实现的部分建议使用 SCSS，可以直接将设计系统中的各类属性以 variables 变量来规范
使用 npm 或 yarn 等工具来管理扩展库，或使用 React 或 Vue 等 framework 的 start kit 来快速初始化原型项目，这样工程师通过 git 获取到代码后可以轻松将原型版本在本地跑起来。当然也可以选择用基础的 HTML 和 CSS，但可能会导致 SCSS compile 为 CSS 等过程不那么搞笑。比较方便的纯静态构建方法是直接于引入 vue.js 的CDN连接，这样不用开服务器环境，直接双击 HTML 文件在浏览器打开就能预览页面原型。
直接在页面底部嵌入样本数据，并用 vue 或 react 的列表渲染语言实现渲染
你不必成为 react, vue 或 javascript 的专家，只需学习其基础，例如 list、基于状态条件切换 HTML class 等就可以帮助你在理解真实页面背后的层次和关系，也有助训练信息组织能力

这样一来，工程师直接对照原型中的前端页面结构，以项目需要的框架（react, vue）在开发版中予以应用，并直接“复制粘贴”原型中的 SCSS 源文件，确保了项目的设计在开发的应用中不走样不变形。

到了产品中后期，当初期主要的样式和设计系统相关代码已应用到开发版中，当开发环境已经小有功能可以直接跑服务器调试时，设计师可直接 checkout 开发版代码，在开发版中基于更加真实的业务场景和流程调整 CSS， HTML 结构和 Class，就能保证设计更高效的输出。

贴士五：制作接近真实体验的产品原型，更高效的既得利益者管理

Tips five: creating close-to-real prototype for better stakeholder management

将这样的原型给客户展示，客户也能直观地体验目标产品在对应设备上的真实体验，也可以在早期发现需求或是设计层面的潜在问题，例如用户使用的设备分辨率等等，并及时调整相关需求定义。通过代码实现的前期的设计能够以直观可用的形式呈现，并适应到不同的屏幕，也有助于降低基于“想象”的客户沟通成本，减少沟通壁垒。客户也能透过这种接近真实可操作的产品原型，感受到供应商方面的专业能力。

以上方法也适用于包括 native app 在内的所有界面产品，因为使用 web 实现的产品原型可以在浏览器中呈现，手机、web 都有浏览器可实现预览。即使是原声的 app，也可以通过简单的 Swift Webview 来让目标样式在 Xcode 的手机模拟器中预览，或是生成测试 app 在手机中直接体验。

用代码来做设计能让设计师每日的工作从静态的难以自适应的设计图中跳脱出来，去输出更接近用户真实使用的产品原型。当然，这需要设计师付出时间成本去学习相关的代码，而代码这种依赖左脑思维的活动对习惯了以右脑感知画面的人来说会是不少的挑战。