从0到1「aPaaS平台项目总结」

从项目立项到一期项目结束，总结复盘一年半从0到1的aPaaS平台

文章太长容易造成读者感官体验不佳，为此删减项目细节，尽可能突出重点分析

B端产品和C端产品的思考模式存在差异，有时不受体验的好坏决定数据，更多时候靠公司本身提供的服务和资源

设计初：

了解aPaaS的原则和特性，制定产品方向，规划产品的“广度”，在项目立项阶段，首要的问题是：“为什么要做这个产品”，同时要想清楚“不做这个产品会怎么样”、“风险和结果”

市面上的PaaS平台不多，调研工作也应该更为精准，正如那句“设计B端产品就像在迷雾中建造桥梁”

目标：

整个调研过程要明确目标 

例如准备调研问题的目标是获得用户信息，了解用户喜好，区分用户群体（在toB产品中，用户群体区分不明显），收集分析用户旅程和用户情绪，帮助实现用户价值

用户研究：

考虑的要素还有问卷人的书写习惯、访谈习惯、访谈空间、一对一还是一对多、访谈内容过多造成的疲劳程度，主观客观问题分开问

拿到访谈后区分受众群体和性别、各年龄段的差异程度，不同职责岗位同事的看法

分析得出用户画像、原系统的用户旅程、需要的模糊且必要的功能清单（方便后续进一步访谈）和设计风格初步认定

考虑点：

前期调研中首先需要明确数据库格式，数据体量、用户体量、是否实时响应、存在的计算逻辑、是否需要移动端、审计方面的合法合规性、是否有例如订单系统

与之对应的需要注意很多细节：布局服务器数量、对方需要输出的数据库词典、私有部署or某云服务器、移动端（H5、小程序、苹果商店）、财务人员审核、字段不能存在违规功能导致不能作为上报依据、申请等保三级资质、发票系统等等

用户研究：

用户访谈后会拿到一个雏形化的用户研究报告，包括用户习惯和用户偏好

通过得到用户信息也可分析出受众群体的简要工作流程

用户旅程图我一般不去绘制，而是整合信息，其做用近乎相同，且很多信息需要访谈后出具产品风格评审，功能清单评审

为后面的二次三次访谈做准备

需求和痛点对应的功能点输出具体功能模块，方向制定好再去打磨体验，例如「基础表单模块」

评审对应：合法合规、技术实现

产品层对应的功能：功能方向、功能分类、功能延展

交互对应：使用习惯、操作路径

文档输出：

文档目录区分大的功能板块，标注清版本，给研发和测试的同学提供便利，也为自己日后检查便利

本人习惯将分类功能按表格展示，具体格式也可以和研发和测试的同学沟通，保证畅通即可

大厂在复杂的交互流程中有专门的交互动效设计狮进行梳理

页面布局：

在做页面布局时可以，可以拿出往期的竞品调研（竞品调研要实时同步）

分析界面布局原则，多大体量的平台出于什么原因才有了布局样式，同时遵循易操空间控范围交互原则

配色也是在设计过程中，汲取用户喜好、逐步更新后敲定的结果（后期产品还会有皮肤布局）

个人工作初大部分从事C端的产品交互以及视觉设计工作

前者为MVP版本时期风格，风格偏C端，而后在复盘业务流程下沉积累了更多的体验和建议，最终输出更简洁易用的操作界面

改版视觉：

借用用户调研得出的结果，套用在界面设计，

例如：受年龄段影响，字号不能低于12号字，以最常用的显示器大小作为设计标准，延展适配原则，根据使用习惯布局填报方式

根据数据体量设计表单样式，报表上报平台的格式规范等

交互设计

大量的功能架构稳定后，产品设计可以偏向规范整理交互设计原则

例如：弹窗反馈一致性、关键位置重复询问用户意见、hover交互反馈、下击反馈、视觉意义统一、功能名称统一易懂、配置端属性样式分类等

表单作为本产品的核心功能，优先级应为最高

因此在表单设计的理念应更加统一、可延展可适配性强、新增功能相互关联性强、不出现相互冲突

总结产品的设计历程可以帮助自身发觉每个步骤的相关性，不同工作流程间的协作关系，总结出现的问题

整理和归档文档、分析归纳总结每个阶段文档书写格式问题，是否有提升

回顾最初设立的产品目标，解决的痛点是否偏移，是否实现产品价值，总结重大失误以及其原因

感谢观看！