每个人都是产品经理【起点学院】，BAT实战派产品总监孙孙系统带你学习产品，学习运营。模板。

嗯，首先，这是一个很小的需求(毕业半年以上接触的大多数都是小需求)，没有什么可以照理用的。但是之前写了一篇做用户体验设计的文章后，慢慢有了一些心得，有时候小需求也很光荣的时候，在观众中窥豹，觉得以前的文章方法还是有用的，所以总结一下思路吧。

一战略层

为了谁，为了什么。

战略层包括业务目标和用户需求。

为什么做这个？

当时是开学季节，有一天产品突然来找我。

产品：samper，现在有两件事。一个是最近这段时间很多父母得到反馈的问题。新学期开家长会，班主任用AA收款收取学费，家长支付后显示微信昵称，不知道是谁出的。不仅是家长，很多旅行人群、临时拉的吃饭人群也有这样的问题。另一张AA收据的大款，用户帮朋友代缴后，自己的头像也露出来了，收款人不知道是怎么回事。

乙：现在学校和家长们这样与时俱进吗？用AA收班费哈哈。学费征收问题，让很多微信集团为了方便，从一开始就让所有人进入集团，更换昵称，并在用户付款后显示集团昵称。代理方面会选择微信朋友重新支付，从而暴露代理人的军名吗？

产品：首先，如果直接使用学费作为集团昵称，可能会有安全问题，第二级选择朋友涉及朋友关系链安全问题，目前内部无法开放该权限。

……。

2. 初步的需求分析

业务目标

这里的商业目标也可以说是产品目标，显然满足用户的需求，减少不满量就是这里的产品目标。

用户要求

产品作为需求提供者，是用户和使用场景的直接资料来源。我们要引导产品共享更多信息。这里要初步发现用户的要求有两个。一个是帮助收款人清楚地知道相关付款人的身份，另一个是帮助收款人知道代理人的身份。

对

3. 调研

产品的考虑不一定代表实际用户，我们仍然需要“眼见为实”。可以从周围的同事开始调查。通过采访可以看出，这种场面确实存在，但很少，所以这个地方不适合以强烈的需求来做。

4. 详细需求分析

产品端和调查都获得一定信息后，我们需要整理需求信息。从工作内容和用户的角度来看，这是优化的用户疼痛要求。

合并分析初步要求

事实上，上述问题有一个理想的解决办法。因为不起作用，所以与用户一起构成新问题。

整理一下从对话中得到的信息，我们可以对问题做出初步定义。这里说的问题好像有两个。也就是说，收款人不知道付款人的真实身份，收款人不知道代理人的身份。另外，原来的理想方案不能实施，而且这不影响少数人的需求对公众的体验，所以必须找到各自的解决方案。

陷入解决方案的深渊

起初，结算用户建议直接添加注释似乎很自然。但是考虑到这是少数人的要求，不适合对现有页面设计进行太多更改，所以正在考虑注释的位置。

下图左边是微信AA收款的新页面，右边是旧页面。我们一度想恢复那个评论功能和下面的纵向头像。只是因为符合我们的备忘录要求。

看到 AA的设计回归，我现在才冷静地思考。我去了，怎么又进了解决方案的坑。问题的定义真的足够明确吗，是否足够明确，可以用一句话概括？意识到自己的错误后，我重新找产品聊天，抛开目前的方案和困境，从头整理一下我们面临的问题到底是什么。

最终要解决

这里看似有两个事件，但是实际上说的都是一个身份确认的问题， AA提供的是头像+微信昵称来确认身份，但是事件1收班费非好友头像+微信昵称无法表明付款人的真实身份，事件2代付的情况则是目前显示的都是同一人头像+昵称，根本就无从确认身份。所以，这里的问题是收款人无法确认相应付款人的身份，从而无法收齐款项。

我们再来回顾总结一下我们到底要解决什么问题：

我们要在理想方案走不通的情况下，另辟蹊径，既不影响大部分的人的体验，又要帮助特定场景下的AA收款人通过确认相应付款人的真实身份来统计排除谁没交钱，从而帮助收款人收齐款项。

在加上对于用户使用场景的梳理，填写表格如下：

要帮助特定场景下的AA收款人通过确认相应付款人的真实身份来统计排除谁没交钱，从而帮助收款人收齐款项。再加上对于用户使用场景的梳理，填写表格如下：

二．范围层（怎样来实现需求）

范围层说的是功能和内容，为了解决问题我们提供什么功能和内容，也就是初步的解决方案。

1. 功能

考虑到身份直接对应的就是姓名，所以这里考虑让用户直接修改昵称来表明自己的身份。

2. 内容

尽量简单易懂，符合用户常规认知，所以使用“备注名”一词来提示用户修改昵称。为了不显得很强硬的逼迫用户修改，文字建议为“点击头像可设置备注名”，表示非必选项。付款人代付之后提示用户“代谁支付”，用简单口语化的询问来提示用户填写代付备注。

三．结构层（怎样使用功能来实现需求）

结构层说的交互设计和信息架构，通常指的是产品的流程设计和页面架构。

1. 流程设计

流程设计就是设计用户的行为，或者说是引导用户的行为。

入口设计

作为一个新的功能上线，为了减少对大众用户的干扰，大规模的功能指引是不合适的。所以我们选定在用户付款完成之后进行提示。提示的频次也要仔细考虑，修改现有昵称的场景较少，但考虑到AA本身频次较低，所以考虑前期在每月第一次支付时进行提示。代付严格意义上来说是补全原有的环节，可以每次都进行提醒。

用户操作流程

也叫用户行为预设计。虽然解决的问题是一个，但是存在两个场景，所以还是要分两条流程来设计。这里需要按照用户的心智模型来看：

修改现有昵称

备注代谁支付

业务整体流程

我们需要把用户的流程串联起来进行观察，加入业务逻辑思考，还有异常情况（如用户修改失误可快速再修改）。

2. 信息架构

这里只是一个小的功能，并没有涉及信息架构的整理。

四．框架层(做成什么样）

框架层是结构层的具体表达方式。有了前面清晰的流程，这里主要考虑一些细节上的问题。

修改现有昵称

• 为了降低干扰，支付后出现的提示框过几秒就会消失。
• 按照原有的时间顺序排序，当前付款人的头像可能出现在一屏页面之下，用户可能根本注意不到提示，所以这里修改好友列表排序，始终将当前付款人自己的头像置于首位，保证提示信息能够及时被发现。
• 头像和下方的蓝色昵称都可以点击，扩大点击区域，同时使用弹层进行昵称修改，如有问题可以再次点击快速修改，使得操作可逆。
• 原本设计最多输入5个字符（主要是中文），但是考虑到输入框无法识别中英文（英文姓氏一个字母也是一个字符），所以设计最多显示5个中文字符的长度，超过部分以省略号形式代替。

备注代谁支付

代付和上面大同小异，被代付的头像一开始加上代付标签再提示用户备注代谁支付。

五．最后

1. 排查

当设计完成后最好对自己的方案进行排查，这里可以使用尼尔森的可用性原则进行排查。

• 状态可见原则：可编辑态采用蓝色链接文字，点击即可弹层修改，修改完立即看到修改结果。
• 环境贴切原则：使用了用户常见的备注昵称等语言。
• 撤销重做原则：修改后如有问题可以再次修改。
• 一致性原则：修改操作前后一致。
• 防错原则：通过提示框文字和弹层标题文字，尽量避免用户出错。
• 易取原则：用最简短的文字引导用户操作。
• 灵活高效原则：初级用户提供直接提示，中级用户通过文字链接色了解操作。
• 易扫原则：文字尽量简短。
• 容错原则：修改出错可以再次返回修改。
• 人性化帮助原则：修改昵称每月首次支付进行提示，代付每次进行提示。

2. 评审

即便在整个项目期间我们一直和产品保持交流，最后的方案评审也仍然可能遇到多方分歧。以备注名显示字数为例，产品、视觉、我、重构和前端都有各自的考虑。不要带着一种说服的心态来办事而是积极寻求共识，肯定大家的共通点，寻找分歧点。最终在体验和技术的平衡下找到较好的实现方案。

总结

• 这里的确是一个非常小的功能，但是我自己还是很受启发，尤其是当做了三四版解决方案之后才回过头来重新思考问题的本质，希望以后多注意少走弯路。
• 这里面也遇到了很多技术上的小问题，的确一开始考虑不周，造成了一些返工时间上的浪费，以后在思考时要更加脚踏实地的一步步验证可行性。
• 自己之前摸索的设计方法在这里有所价值体现，希望以后通过更多的实战经验来优化。

本文由 @jxwoosa 原创发布于人人都是产品经理 ，未经许可，禁止转载。