首页天道酬勤买白色E300纠结是立标还是大标(纠结房子买大买小)

买白色E300纠结是立标还是大标(纠结房子买大买小)

admin 12-01 05:20 185次浏览

编辑导语:对于追求完美的人来说,工作中会有一些非常纠结的地方,甚至会煎熬,耽误正常的工作进度。本文作者在产品设计方面也有过类似的经历。跟大家分享一下,看看吧。

今天的话题对于产品经理来说是一个很有争议的话题:是日常产品设计过程中常见的一些纠结。

有些人觉得完全没必要纠结,有些人小心翼翼,每一步都在纠结,有些人可能根本没有经历过这种感觉,也没想到会有这么多。而我又谨慎又纠结,有时甚至会干扰我正常的工作节奏,所以决定把自己的想法和纠结点写出来。

一方面可以通过文字放慢思维,回顾总结过去的计划,考虑是否有值得改进的地方;另一方面也可以和大家分享一些背后的故事,看看不同的人有什么立场和派系。

00-1010缠结如下:

你想展示这个吗?这有用吗?会不会是多余的?会不会太久?名词的定义准确吗?字段翻译问题.在B端后台管理界面的设计中,最难的问题是字段问题。你想显示多少字段?每个领域都有用吗?太简单的后续不容易拓展,太复杂对用户体验不好,也显得产品没有想太多.

以“有赞”为例

赞的整体风格是简约克制。比如Zan没有显示操作日志和记录、关键节点的时间(采购审核时间、采购入库时间)、采购订单的备注等.

我很佩服这种克制的赞美,但我也很困扰。这样的极简功能,如果符合一些管理要求严格的公司,真的能满足吗?

我对SaaS产品设计有一个根深蒂固的印象:不同的行业、不同的公司、不同的用户会有不同的需求。为了减少后续频繁的迭代和调整,所有的产品设计方案基本都会是最细致的,采用最麻烦、最全面的方案进行设计,但前端封装会更简单。

当然,我的观点可能是错误的,对此我采取辩证的态度。

除了决定要有哪些字段,还有一个纠结的点:字段应该叫什么?例如,之前让我最纠结的名词有:

FBA中转/中转FBA/FBA订单/FBA备货物流订单/获取面单/获取跟踪号/预测面单更新时间/修改时间/上次更新时间/上次修改时间订单/出库单/发货订单运单号/跟踪号/跟踪号物流渠道/物流服务/物流产品.有很多名词的定义并不准确,但却被一些行业中有影响力的产品所使用。

我只能“犯错”来适应用户的习惯,但其他尴尬的事情是一些“老实”的用户不愿意叫这个名字,或者新用户(之前没有用过其他产品)觉得定义不清晰不容易理解,希望改变准确的名词定义.

举个例子,到现在我还有点困惑:FBA中转是把货物从海外仓库送到FBA,还是FBA中转是把货物送到海外仓库。然后,我需要调用我的“系统2”进行简单的转换,我才知道这意味着将货物从海外仓库发送到FBA。

还有物流渠道、物流服务、物流产品的定义,也让新人看起来很傻。每次说到这个概念,都要解释一下,但如果用英语解释,我觉得可以直接顿悟。

物流/物流服务物流产品(航运服务集团)物流产品实际上是包装物流渠道的集合。按组定义简单明了,但每次按产品定义都需要额外说明。

00-1010当田地煞费苦心地确定后,在绘制原型时又出现了另一个棘手的问题:如何安排田地的顺序?

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

目前很多后台管理系统的列表区一般允许用户自定义字段和排序,所以产品只需要定义开头显示的字段和顺序,后续用户可能会打扰自己,所以这一块的排序不会过分纠结。

以“有赞”为例

awesome列表区不支持自定义显示字段和排序,符合他的极简风格,但不知道用户有没有提到相关反馈,所以需要增加自定义字段和排序的需求。

目前,编辑区和表单页面基本遵循“分组”原则,将一些同类字段放在一起。至于同类如何排序,就看如何画出产品的原型了。

以“有赞”为例

以产品创作为例。有赞将产品信息分为五组,然后将相应的字段放入组中,从上到下编辑输入。

详细信息页面的显示通常遵循分组原则,但是在分组之后,在组内

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

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

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

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

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

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

三、单号生成规则

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

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

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

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

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

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

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

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

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

四、总结

关于这个话题,我在2年前就想写了,但是当时感觉自己工作经历不是很多,所以可能一些疑惑是会在后续得到解决的。

直到我最近重新从0到1做一款产品的时候,我才发现,2年前纠结的一些事情到现在依然没有很好的解决。该纠结的还是很纠结,该思考停顿的地方,还是要思考和停顿。

对于以上一些纠结的问题,大多数我都有了答案或者探索之后内心更加坚定和安心,但是这些纠结时刻确实是发生过的,以后也会继续发生。所以我想记录下来分享出来,如果这些描述能对大家有所帮助,那就更好了。

鉴于篇幅的问题,本文就先将这三个比较经典和常见的困扰,后续有了灵感和素材之后再来更新下文。

我们下期再见!

#专栏作家#

我叫维他命(Vitamin),微信公众号:PM维他命。前PHPer,做过在线教育类产品,也做过3年半的跨境仓储物流方向的产品,目前是一位外贸SaaS领域的供应链产品经理。主要专注于WMS/OMS/TMS/BMS/ERP等领域,分享供应链相关的产品知识。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

Android中TeaPickerView数据级联选择器功能的实例代码
多种接收方案促成的正确描述有(多种接受方案促成法的正确描述) 协同办公软件有哪些(文档协同办公)
相关内容