「简单版本」产品规划

在着手开发之前，我们需要绘制产品原型图，在绘制原型图之前，最好先将应用的整体逻辑梳理一遍，简单版本将满足用户「给头像添加特定贴图」的需求，核心的功能是「给定头像 → 添加贴图 → 保存头像」。

事实上，在投入开发之前，需要做的事情非常多，包括但不限于挖掘需求、需求调研、反复评估、线框原型、用户调研、高保真原型、产品需求文档、设计规范、交互原型、开发文档、测试文档等等等等。所有这些准备工作在理想情况下都要尽可能全面，一来，尽力保证产品预期的可用性和需求契合度，二来，降低团队不同职位成员之间的沟通成本。这些工作无疑需要额外的付出，但为了在一定程度上确保后续的投入成本是「值得的」，所以或多或少都需要去执行。

虽然由于时间和精力等客观原因我们无法完整走一遍流程，但为了保证后续开发的顺利，我们也会先进行尽可能详细的规划，在后续的某个时刻，大家会切身体会到我们现在所做的准备的「巨大价值」。

在这一版本中，我们只完成能够满足目标需求的核心功能，对于设计原型来说，核心功能的描述过于简洁，我们需要将它变得更加完善。

流程梳理

从核心功能开始逐步具化和发散，对于「为给定头像添加贴图」这样一个工作流来说，首先我们需要「获得用户的头像」，但对于应用的操作者，即用户来说，任何东西都可能想要作为头像，选择实在太多了：

尽管我们可以设想出无限多种用户对于「选择头像」的情境和理解，尽管我们的这些想象可能都是切实存在的用户需求，但在当前，它们之中的大多数都不是我们优先考虑的实现目标，我们的关注点首先是「帮助用户完成核心流程」而不是「满足开发者的一切幻想」，「不要陷入完美主义的泥潭」，这是我过去两年在「挖坑实践」中得到的深刻体会 😣

粗略一看，上面的导图中至少包含了四个不同的功能方向：历史头像、接入第三方云存储、头像搜索、制作头像。不必觉得可惜，总有一天我们会视情况将它们整合到应用中来，目前我们的首要任务还是能够满足 80% 需求的那 20% 的功能 😇

如果实在难以割舍，不妨从实现的角度来思考一下，对于程序来说，无论我们为用户提供多么丰富的选择头像的功能，对于之后的添加贴图环节来说，都是一张图片输入而已，也就是说，多样化选择头像的功能对于我们这个应用主体来说是横向扩展而不是纵向扩展，横向扩展往往比纵向扩展容易得多，因为对于用户来说，横向扩展是可选功能或可选操作，而纵向扩展是必需操作，对于后者的权衡需要更加慎重。

以此为出发点，我们可以为用户提供两个选择：使用当前的头像或者使用其它图片，结合小程序的基础能力，具化为以下三个操作：

• 授权小程序获取当前头像
• 从手机相册中选择头像
• 拍照作为目标头像

也可以从消息记录中选择文件，就是简单的接口调用，我们暂时先不做这个功能，大家可以自己发挥。

获得头像之后，需要一块地方来进行呈现，同时，考虑到用户可能有「重新选择」的需求，我们最好停留一下，提供「更换图片」和进入下一个环节即「选择贴图」的操作选项。

其实，如果用户想重新选择，完全可以使用「后退」功能回到上级操作，但这样其实不是很友好，「后退」属于打断操作流的体验，对于我们的目标功能来说，我们更希望用户能够没有停顿地一直往前走，而不是磕磕绊绊地反复「时光倒流」。当然你可能会说，在进入「选择贴图」环节之后，用户仍然可能反悔呀，这种情况固然是存在的，但我们认为相较于前者而言用户在到达这一步之后再反悔的概率低得多，而且设置「选择贴图」这一选项本身的潜台词就是与用户达成约定「头像已经选好了，不再改了，下一步吧」，当他（她）后续想要返回的时候，属于「自愿打断」而非「被迫打断」。这中间体现的是一种权衡，各人也会有各人的理解和最终抉择，在更加完善的版本中我们还可以通过其它手段来尽量降低「自愿打断」带来的「耐心损失」。

进入「选择贴图」环节之后，我们面临着与「选择头像」类似的权衡，此处不再赘述，考虑到大多数用户都是在特定的时间点为了特定的贴图而来，所以我们事先将贴图准备好提供给大家进行选择即可。（参考 2019 年国庆时的换头像「盛况」）

选好贴图之后，将其直接在已经印有头像的画布上呈现，作为成果的预览。同时，在当前版本中，我们暂时不提供贴图多选、贴图编辑等操作，单一贴图在固定的位置呈现，尽可能从简，当然了，贴图之间可以进行「切换」。

头像和贴图的合成是需要时间的，我们并不希望在用户每选择一个贴图进行预览的时候就将结果合成出来，即使用户可能无感，这也并不友好，所以我们需要一个「确认」按钮，供用户选定之后告诉我们他（她）选好了，我们好进行合成，待合成完毕之后将结果呈现给他（她）。

头像和贴图的合成是需要时间的，即两张图片合成一张图片是需要时间的，我们之后在具体实现的时候还会展开阐述这一点，目前你可以将上述考虑类比为「纹身」，在纹之前选择图案的时候，我们需要将图样简单地贴在身上进行比对，而不是直接纹在身上，要换的时候再洗掉，后者无论从皮肤的承受度和操作所花费的时间上来说都不现实。

类似地我们也可以联想到另外一种解决方案 —— 用户选择好头像之后，点击「选择贴图」，我们就将所有可能的效果呈现出来，然后他（她）选择一个中意的，系统去合成……说实话我还蛮喜欢这种效果的，可以提供实时的对比，免去反复切换进行选择的繁琐，相较之下前者的优势在于模拟了真实的操作习惯——「人不会分身」，在简单版本中，我们采用前者，在更完善的版本中，我们会将后者也有机地集成进来，为用户提供更多的选择。

虽然我们特别希望可以一键将结果设置为头像，但很遗憾微信当前并没有开放这个能力。在这个节点上，我们可以提供一个「保存到本地」的按钮，帮助用户快捷地将合成的头像保存到相册中，同时，提供「再做一个」的操作选项，链接到首页，完成体验回路。

至此，我们将整个操作流程梳理了一遍，以下做简单的总结：

打开小程序: 
选择头像: 授权使用当前头像、从文件中选取、拍照三选一
确认头像: 提供「更换图片」的按钮以便重新选取，待用户确认要加工的头像无误，点击「选择贴图」进入下一个环节
选择贴图: 点选贴图的时候将其覆盖在头像上作为预览，可以在贴图之间切换，但目前不提供多选和移动、放缩、旋转等编辑操作
确认贴图: 选好贴图之后点击确认按钮，程序进行合成
合成完毕: 合成完毕呈现给用户，提供「保存至本地」和「再做一个」的操作选项
关闭小程序:

以上涉及到一些小程序技术能力方面的知识，零基础的同学不要畏难，即使是对于熟练的开发者来说，这些功能也并不是烂熟于心的，他（她）们只是实践得较多，对于当前的技术能做什么、不能做什么已经有了相当的了解，在具体使用的时候，仍然需要去查阅相关的文档。编程实战中更多体现的是组织能力和理解能力，而不是记忆能力 🤗

想大概了解小程序能干什么，推荐查阅以下官方文档提供的内容，简单浏览，查看摘要，心中有数即可，详细品读最佳 😋

• 小程序官方文档 API 部分
• 小程序官方指南
  • 基础能力
  • 硬件能力
  • 开放能力

原型绘制

操作流程并不足以明确地指导我们的代码实现，在这一步，我们需要围绕「操作流程」绘制出产品原型，主要是产品界面和跳转、交互逻辑，要尽可能详细、准确，目标是让我们可以直接照着原型图写代码。

「原型」可以理解为「脑中想法 → 实际产品」的过渡阶段，衡量原型详细程度的指标叫「保真度」，无论是原型还是保真度都不是一个特别明确的概念，你可以把我们上面梳理的流程叫做「低保真文字原型」，也可以把一个直接上手撸出来的可用产品叫做「超高保真实用原型」，这些判断标准都是人为界定的，不必拘泥于此。我们真正需要把握的是「绘制原型」这个步骤在我们把脑中的想法落地为产品的这一过程中具有的作用和意义。对于个人来说，绘制原型是统筹规划，设置一个清晰可见的目标，事先尽可能完善地考虑之后可能遇到的问题以及解决方案，不至于在实际投入开发的时候状况百出，频繁停滞，对于团队来说，原型主要是作为团队内外成员之间交流的载体，根据不同阶段、不同交流对象的不同需要，「原型」也就具备了不同的形态。
> 「照着原型图写代码」是一个非常笼统的表述，在实际的开发中，「如何实现功能」和「如何优雅地实现」是两件不同的事情，前期规划和绘制原型对于开发阶段的意义就是尽可能将「如何实现功能」的顾虑降低，让开发人员能够集中于思考「如何优雅地实现」而不是把时间用于吐槽产品和设计。在理想的团队中，投入开发之前产品经理、设计师、开发组长会碰头确定每一项产品细节，具体到功能实现、交互动效、后续扩展等方面，事后输出产品需求文档（简称 PRD，带需求描述、对应的功能模块和操作逻辑等）、设计规范（带标注）、开发文档（技术方案、架构设计、模块关系、特殊情况实现方法等）等，然后开发人员拿着这些文档去做作业。> 前期功课做得足够好的话，产品经理和开发人员是不会吵架的 😶

有很多工具可以用来做原型，譬如 Skecth、Adobe XD、Figma、Axure RP、墨刀等等，PS 或者 AI 也可以，但「术业有专攻」，前面几个用起来更加方便一点。Whatever，选择自己最趁手的即可，在这次工作坊中，我选择使用 Xiaopiu，项目地址是：CTW-Ⅰ - 头像定制小程序，大家可以去看我们绘制好的原型啦，整体流程预览如下：

在上一小节中，单就操作流程来说，我们已经梳理地相当详细了，但你会发现在根据操作流程设计原型的时候，仍然有不少出入，原因在于能够满足目标操作流程的界面并不止一种，而我们在实际进行绘制的时候，最终要选出最心仪的一种，当然「心仪」也是有标准的，在满足功能的情况下，一方面要优先照顾到用户的体验，另一方面要照顾到技术实现。在原型拍定之后，对着原型进行技术实现的时候，方案仍然有很多种，一个好的前期策划，应该尽可能为后续的环节多想。

在上述「简单版本」的原型设计中，有 4 点值得一提：

1. 在首页的选择中，我们主要考虑了两种方案，如页面 ①、② 所示，在页面 ① 中，使用「开放组件」在不需要经过用户授权的情况下即可显示头像，让用户对当前头像有个直观的感知，然后直接呈现选择头像的三种选项，相较页面 ② 使用「操作菜单」的方案可以减少一次点击，并给予「我能做什么」的直接感知，在页面 ② 中，选择头像的三种选项以「操作菜单」的方式呈现，页面更加简洁，并且上方显示头像的画布与后续页面相同，具备「一致性」体验，但画布区域是不是要先使用「开放组件」呈现当前头像是个难题，如果呈现的话，下面「选择图片」的选项第一时间就会觉得多余，如果直接将其像页面 ① 一样展开为三个选项，在元素大小不变的情况下页面 ① 又显得更为美观（权衡之后我们决定先选用方案 ①）。
2. 大家可以注意到后续三个流程中显示头像的「画布」部分是一致的，在具体的实现中完全可以使用单一页面完成，只需要在不同的操作阶段动态更换页面下方的「操作选项」即可，但我们考虑到后续扩展的时候可能要在不同的阶段添加更多的功能，如果全部集成在一个页面中，扩展起来会有麻烦，所以按照流程切割成了三个不同的页面。
3. 由于我们的 PM 具备一点开发的技术背景，所以在设计原型的时候帮开发做了一点微小的决策，即在实际进行图片合成之前，都使用 「Image」容器来放置头像或贴图，这样做比直接绘制在「Canvas」画布上要高效一点。
4. 设计师给的设计稿中，还会包括页面上各个元素的尺寸、颜色、边距等标注信息，由于我们没有设计，所以这一步就由 PM （产品经理）代为执行啦，Xiaopiu 有为我们自动提供原型页面元素的标注信息，可以供开发参考，如下图所示：
   

「提出需求 → 梳理流程 → 绘制原型 → 代码实现」就是将一个简单的想法落地为切实可用的产品的一般步骤，以上我们已经走完了前三步，接下来可以开始撸码啦~

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.