产品设计中的几大纠结点，看看你是如何解决的？（上篇）

PM维他命 2023-08-01 12:40:57

今天聊的话题，对产品经理来说是一个很有争议性的话题：就是在日常产品设计过程中常见的一些纠结点。

有些人觉得完全不需要纠结，有些人则每一步都很慎重、很纠结，还有一些人压根可能没有经历过这种感受，都没想到这么多。而我就是慎重、纠结派，甚至有些时候会干扰到我的正常工作节奏，所以我决定将自己的思考和纠结的点写出来。

一方面可以通过文字来放慢自己的思路，回顾和总结自己的过往的方案和考量是否还有值得改进的点，另一方面也可以与大家分享一些背后的故事，看看不同的人分别是什么立场，什么「派系」。

一、字段问题

纠结点如下：

要不要展示这个？
这个有没有用？会不会重复累赘？
会不会超长？
名词的定义是否准确？
字段翻译问题
……

在B端后台管理界面设计中，最容易纠结的就是字段问题，到底要展示多少个字段？每个字段是否都有用？过于极简后续不好拓展，过于复杂则对用户体验不好，也显得产品没有进行过多的思考……

以「有赞」为例

有赞的整体风格就是简约和克制，例如拿采购订单来说，有赞没有展示操作日志和记录，没有展示关键节点的时间（采购审核时间，采购入库时间），也没有采购订单的备注等……

对于有赞的这种克制我表示很钦佩，但是也很困扰，这么极简的功能如果遇到了一些管理要求比较严格的公司，真的能够满足吗？

我对SaaS的产品设计的一个根深蒂固的印象就是：不同的行业，不同的公司，不同的用户会有不同的需求，为了减少后续频繁的迭代和调整，所有的产品设计方案基本上都会做到最细化，采用最麻烦，最全面的方案来设计，只是在前端包装的时候做的简单一些而已。

当然，我的看法有可能是错误的，这一点我持辩证性的态度。

除了确定要有什么字段之外，还有一个纠结的点就是字段应该叫做啥名字？例如之前让我最纠结的几个名词有：

FBA中转/中转FBA/FBA订单/FBA备货
物流下单/获取面单/获取跟踪号/预报面单
更新时间/修改时间/最后更新时间/最后修改时间
订单/出库单/发货单
运单号/跟踪号/追踪号
物流渠道/物流服务/物流产品
……

这里面有很多名词定义是不准确的，但是被一些行业中有影响力的产品使用了，用户长时间使用这些产品之后，就被植入了根深蒂固的认知。

那我只能「将错就错」去适应用户的习惯，但是其他尴尬的是有些「正直」的用户不希望叫这个名字，或者新用户（之前没有使用过其他产品）觉得定义不清晰不太好理解，希望能够换个准确的名词定义……

例如至今为止我都有点恍惚：FBA中转到底是海外仓发货到FBA去，还是FBA中转一下发到海外仓.然后还要调用我的「系统2」来简单换算一下才知道，原来这个是从海外仓发到FBA的意思。

还有物流渠道、物流服务和物流产品的定义，也是让新人一脸懵逼，每次讲这种概念的时候都要一通解释，但是如果用英文来解释我觉得直接就可以顿悟了。

物流服务/物流渠道（Shipping Service）物流产品（Shipping Service Group）物流产品其实就是一个打包的物流渠道的集合，用Group来定义简单明了，而用产品来定义，则每次都需要额外的解释。

二、字段顺序问题

当辛苦确定了字段之后，在画原型的时候又出现了一个让人纠结的点：那就是字段顺序怎么摆呢？

一般的后台字段摆放比较纠结的页面或者模块有：

列表/表格区；
编辑页/表单页；
查看详情页；

现在很多后台管理系统的列表区一般都允许用户自定义字段和排序了，所以产品只需要定义好一开始的展示的字段和顺序就好了，后续用户可能自己也会打乱，所以这一块的排序不会过度的纠结。

以「有赞」为例

有赞的列表区不支持用户自定义展示字段和排序，符合他极简的风格，但是不知道用户是否有提过相关的反馈，需要增加自定义字段和排序的的需求。

对于编辑区和表单页，目前基本上都是会遵循「分组」原则，把一些同类的字段放在一起，而至于同类中怎么排序那就看产品怎么画的原型了。

以「有赞」为例

以创建商品为例，有赞将商品信息分成了5组，然后分别的将对应的字段放在组内，从上往下依次编辑录入。

详情页的展示一般也会遵循「分组」的原则，但是分完了组之后，组内的字段怎么排序也是一个头痛的问题，如果都是一个产品来负责，可能还好一点。只需要做好一个标准页，然后批量的复制和微调即可。如果是多个产品来负责，那么很有可能就会有两种风格的展示出现。而有些产品是对这个东西敏感的，有些产品压根就不敏感，反正把字段丢上去就完事了，协调性，美观性，一致性都抛之脑后了。

当然，最后可能还有一个解法就是靠UI来全局把控，鉴于我之前的项目经验几乎都没有UI，所以我也不太好下定论是否真的有效果，但是我仍然会建议产品自己需要关注这种小细节。

再补充一个小细节，在画原型的时候我觉得Axure可以提升优化的一个东西就是支持「AB互换」或者「自动排列」，导致我每次要增加或者删减字段的时候，都需要重新调整一个位置。

在两个字段中间插入一个新字段：

拿上图为例，我需要增加一个字段到预计到达日期这个位置，那么预计到达日期之后的所有字段都需要重新挪一个位置，挺费时间的。后续如果我又需要删除某个字段，那么其他的字段也要跟着一起向前挪一位。

目前来说，我只在Figma上看到了相关的解决方案，Axure不知道啥时候能解决这个问题。

三、单号生成规则

B端后台管理系统，有很多单据号要生成，怎么生成单据号也是一个值得斟酌考量的问题（一不小心就容易纠结）。

大多数业务都会要求单据号需要具有唯一性（作为内部数据交互的字段），然后具有语义性（能通过单号知道是什么业务），最好还要足够短（运维或者客服处理时方便记忆），最后可能还会要求开发简单，能复用或减少维护成本。

从我多年的踩坑经验来说，一般会有这么几种方案：

关键字+日期/时间+自增法
随机生成法
关键字+日期/时间+特定规则法
毫无章法

最常见的，也是最不需要动脑筋想的一个方案就是「关键字+日期/时间+自增法」，这个方案简单粗暴也能让用户从单号上快速get一些信息，使用此方案需要注意的是：阈值上限的问题和删除/弃用的占用问题。

如果超过了阈值上限怎么办（自增只有四位，超过了4位怎么办）？如果占用了一个自增序号又删除了，那么下一个号是从该序号后自增还是继续沿用删除了的那个序号？每次自增都需要查一次前一个单号递增到哪了，如果有并发或者查询超时怎么办？

「随机生成法」一般用于一些不希望用户从单号看到蛛丝马迹的场景，例如电商中的订单号，如果用自增法就会被人猜到具体的业务单量，显然不合理。大家日常听说的「雪花算法」，就是用来生成单号随机数的一种常用方法。

「关键字+日期/时间+特定规则法」和第一种自增法类似，不过为了缩短单号的长度或者隐藏一些业务数据，也可以引入字母构成36进制或者字母数字随机组合，具体规则可以视业务情况而定。

「毫无章法」是我调侃的，最根本的原因就是一个产品经过多年的迭代，不同的产品经理经手，所以单号生成规则发生了各种演化，最后发现根本找不到什么章法。如果是产品经理对此有执念或者强迫症，那么建议在项目启动的初期，就把单号生成规则和要求放在全局说明之中，这样后续别人接手的时候也可以遵循规范，避免出现「毫无章法」的情况。