很多乙方设计师有一个通病：一拿到上游产品经理的需求文档，就直接开干。哪怕静下心来做了一点研究，也总被需求书框住，跳不出上游的条条框框。
可大家都是人，你怎么能保证上游的“需求”就一定是对的呢？流程的价值不在于照单传递，而在于传递过程中不断查漏补缺，起到一加一大于二的作用。
所以，一个真正好的设计师，一定要怀揣产品经理的心思、想当老板的野心。我用一个很久之前做过的项目来举例。
上家公司有智能家居业务，但C端市场已经被几家头部瓜分得差不多了，因此主攻B端整装，合作客户有小区、酒店等。正常业务流程如下：
在施工阶段，工程师不仅需要在现场安装硬件设备，还得在App里完成设备添加绑定、场景联动设置等操作。这样用户入住后直接登录自己的手机号就能使用。登录方式就是手机的号加验证码。产品经理发现这种登录方式很麻烦，而且会给用户带来“不安全”的印象，于是提出新增一种登录方式——账号+密码。这种登录方式仅限工程人员使用，因此项目最初就叫“工程账号”。施工结束后，只要把工程账号和用户的手机号绑定即可。
假设你是一位普通设计师，拿到这个需求会怎么想？我猜内心一定会说：“wok，这需求也太简单了吧！不就是增加一种登录方式嘛。”如果肯多动一点脑子，也许还能想到工程账号需要和普通用户登录方式做个区隔，比如隐藏入口。最终结果大概率就是下面这个样子：
这样的交付当然没问题，甚至可以说皆大欢喜。但事情真有这么简单吗？请记住一句话：一旦涉及硬件与软件结合、涉及多方人员的场景，那一定是一个服务流程问题。所以，必须先把现有的服务体系摸清楚。
稍微梳理一下你就会发现，现有的交付方式其实只有两种：一是工程账号绑定用户手机号，这种方式需要知道用户手机号并获取验证码；二是某些高端房型会配备一个叫“魔镜”的中控设备，用户可以在魔镜上自行登录手机号。
这时你就明白了，这不是一个单纯的登录问题，而是横跨“施工”与“交付”两个环节的问题。增加登录方式只能解决施工的便捷性，却无法覆盖所有交付场景——比如房型没有魔镜，又刚好联系不到用户来绑定手机号，怎么办？
既然流程有缺口，就必须补一个新节点。新节点意味着需要增加新的交付物，成本也会随之上升。我们借用用户体验地图（CXS-Map）来分析一下。
这种新的交付方式必须覆盖所有房型，最好能实现无感交付，不依赖第三方人员，且不额外增加成本。类似“现场增加二维码物料，再由物业人员引导用户绑定手机号”的方案，就显得过于笨重，行不通。
从房型的共性去思考，你会发现所有房型都有一种设备——网关。网关的身上本来就贴有一个二维码，用来配网。那能不能一码多用，让用户入住后只需扫描网关就能完成验收？这样一来，整个体验更加“优雅”、专业，而且几乎没有新增成本。
走到这里，你是不是觉得这个项目已经做完了？甚至可能暗自窃喜，觉得自己是个天才，能比别人多想一步。其实，这一步还远远不够。都说了是服务体系，自然就绕不开生命周期管理、利益相关者需求梳理等一系列问题。
经过简单梳理你会很快发现，账号只解决了登录问题，但施工人员的实际工作方式并没有发生任何变化。此前也偶尔能收到一线反馈，说App的某些功能“不好用”。因此，非常有必要深入到一线做调研——永远不要当一个只坐在板凳上的设计师。
现场调研加访谈，还真挖出了一些有意思的痛点。比如工程账号与房间号一一对应，一个房间一个账号。实际施工中，一个师傅可能要负责N个房间，根本记不住这么多账号。添加、绑定设备时，还要完成重命名、分配房间、设置场景联动等诸多步骤，流程又长又繁琐，万一一次性添加了多个同型号的设备，重命名时根本分不清谁是谁。某个设备坏了需要临时调货替换，如果工人不专业，说不定还会遗漏。
于是，解决问题的核心思路转向了流程标准化，尽可能让机器代替人工。比如，后台可以根据房型提前配置好设备的名称、房间、场景等信息。现场添加设备后，用“选择”代替“输入”。同时补齐设备电子说明书，帮助施工人员熟悉新设备的配网方式，降低上手难度。
接着，把工程账号直接映射为房间号，施工人员只需要记住自己负责哪一栋哪一层就行。这既简化了登录方式，节省了大量时间，也更符合师傅们的真实工作习惯。
再在切换账号时增加一层防错机制——自动检查是否有遗漏的设备，并提供对应的设备清单，把缺失项清晰地标注出来。
回头看，项目最初的需求只是“增加一种登录方式”，对吧？如果你不怀揣一颗产品的心，就不会追本溯源，去重新梳理需求的来龙去脉。如果你没有“想当老板”的意识，就不会去考虑成本收益和流程体系化的长远价值。
去“主导”一个项目的成就感，远比“推动”或“完成”要来得痛快。谁说一个设计师就不能主导项目呢？忘记你的角色，打破边界限制，不论你处于整个流程的哪一个环节，哪怕是末尾。在云栈社区，你能看到更多这样跨领域思考、真正主导一个完整项目的故事。
发表于 昨天 23:27
|
查看: 6|
回复: 0
