如何设计出优秀的网站后台原型？

时间：2023-07-24 21:48:01 | 来源：网站运营

时间：2023-07-24 21:48:01 来源：网站运营

如何设计出优秀的网站后台原型？：

本文首发「卡拉云产品技术博客」：《如何设计出色的网站后台原型？》

如何设计出优秀的产品后台与设计者的水平和对产品后台的本质理解，紧密相关。

接下来，我想从不同水平的产品经理对同一原型的思考过程，和产品后台的本质到底是什么，这两个点来具体聊聊，如何才能设计出优秀的产品后台原型。

一. 产品经理的水平

不同级别的产品经理对设计后台原型的思路和执行有着很大的差别。

初级产品一般会去和后台使用者聊聊需求，用 Axure 画个漂亮的原型图，写个逻辑清晰、格式漂亮的文档。

中级产品开始对业务线有深入理解，站在成为使用者的角度来思考产品后台设计，并能根据自己公司业务线的独特性，有针对的设计后台。极大提高使用者的工作效率，降低使用成本。

高级产品能从更宏观的角度融会贯通业务线，甚至比业务部门的多数人对业务有更深刻的理解，设计出在未来需求变动、突发情况、业务升级时，也不需要太多改动的产品后台。

举个例子：如何设计财务对账系统

接下来，我用财务支付系统中的对账后台来举个例子。面对如何设计一套「对账后台」的产品需求，不同级别的产品会怎么做呢？（我之前写过一篇「如何设计财务对账系统 —— 从0到1搭建对账系统实战」只能算是入门水平，大家可以参考一下）

入门级产品经理 - 解决表面问题

1.首先百度一下，看看现成的对账后台有哪些功能，理解什么是对账系统。

2.调研用户使用流程，去财务部，找会计姐姐一对一面访，问问他们需要些啥功能。

3.将搜到的例子与调研的信息汇总一下，打开 Word 文档，用自己的话讲一遍，格式一定要漂亮，图文并茂。然后用 Axure ，把刚刚写好的文档转化成原型图画出来。

入门级产品设计原型只解决了表面问题，搭建了基本工作流。但并不理解业务更深层的问题，这会导致系统上线后，在使用者使用的过程中，发现无限多没有思考到的问题，导致最后后台重构，浪费大量人力物力。

中级产品经理 - 深入理解，解决深层问题

1.收集对账后台基本资料，充分理解对账后台在整个财务系统中的意义和位置。

2.和财务部的会计姐姐一起整理对账需求，理解每一个步骤背后的意义，理解对账是整个支付系统最后一道防线，内部订单与外部支付渠道对账的意义和可能出现的问题及所有问题的解法。理清楚真实的需求后，再根据产品逻辑和自己公司在这个业务上的独特性来设计整个对账后台。

3.最后，在设计原型时，根据调研需求，保证后台的功能结构和业务逻辑简单清晰，模块化，框架化。在面对未来突如其来的新功能时（一定会加功能），更够更从容。

中级产品经理已经能比较深入的理解业务逻辑，并有一定的抽象能力，将业务抽象成模块，形成结构清晰，业务逻辑流畅的后台框架。搭建的后台原型已经能够面对未来业务需求多变的情况，但还没有融会贯通。

高级产品经理 - 融会贯通，提前预判可能发生的问题

1.拿到对账后台的需求后，先研究财务系统的支付环节，支付与对账有怎样的关联性，从更宏观的角度理解什么是对账。对账与财务的关系、支付的关系，对账对于公司的意义，对于前端用户的意义。对账后台在全局中与其他系统的关联，信息在对账后台如何流入，又如何流出。

2.和财务部的会计小姐姐一起，从财务角度观察会计在对账时，上下游信息如何获取和流动。

3.是否可以更自动化：观察整个对账流出，能否把人工判断的部分抽象出来让系统自动判断。举个比较浅层好理解的例子，「跨日交易」用户在当天23:59在我方系统中下单，2分钟后，即次日00:01在支付渠道支付。那么对当天账时，会有一笔支付渠道没有的已支付订单，这笔交易应该自动挂起，次日再自动核对，在当日没有必要显示出来用人工处理。

4.抽象的通用方案：比如公司目前只接了微信和支付宝，未来如果需要接网银（传统银行）、paypal（国际支付渠道），又会有什么不同，是否可以做成通用接口，未来新增这些功能时，后台是否可以不需要有太多变动。

高级产品经理对业务的知识储备非常全面，全局观和抽象能力极强，能够先一步想到产品后台的未来形态，预判未来可能发生的问题，并已经将这些线索埋在产品原型中。

二. 后台的本质是什么？

接着我想从另一个纬度来谈谈如何设计出优秀的产品后台。

1.后台本质是一张大白纸（信息承载） + 一支笔（信息增删改查）

大白纸：我们可以用一张大白纸手写用户信息（用户管理系统），记销售情况（销售系统）、用户问题（工单系统），核对账本（支付对账系统）但每一个变动，修改，查找都非常麻烦，纸质记录很容易到达数据上线，比如管理3万名用户的用户信息，纯纸质记录的劣势就显现出来了。

Excel（纯数据库类）：大白纸的升级版是 Excel。有了 Excel 后，极大的提高了信息记录和信息流动的效率，我们可以很方便的以表单形式记录信息。使用用户 ID 为 key 来做关联的锚点，扩展出无限多的信息记录，他可以是销售记录，也可以是工单记录。但问题又来了，就算 Excel 再简单，一但开始构建稍微复杂的信息系统，情况就不一样了。上手学习成本，记录数据多样性（对长文本和富媒体不友好），多员工协同，都是 Excel 的劣势。

可视化UI+数据库（后台+数据库）：Excel 的升级版是「可视化UI+数据库」，它可以是 ERP 、 CRM、OA、CMS、HRM、财务或是进销存。不论他叫什么，底层都是由「可视化UI+数据库」构成。它们区别在于对流入系统的数据，做了对应的产品逻辑优化，让操作系统的人，能够最高效便捷的使用这些数据。

2.在从大白纸到数据后台的升级过程中，使用者获得了什么？

（1）根据工作流优化的操作界面 —— 人工操作部分

同一组数据，在不同的后台，有着不同的处理方式。

姓名：卡拉；年龄：21；学历：本科 ；

这组数据既可以是销售后台的数据，又可以学生管理后台的数据，还可以是人力资源后台的数据、风控后台的数据。

数据相同，处理方式不同，形成了不同的业务后台，所以对数据处理的关键在于后台产品设计中对业务逻辑的深入理解，理解的越透彻，后台设计的越简明流畅。

（2）自动化一切 —— 机器操作部分

从大白纸到数据后台，能有这样巨大的变革，是因为有了计算机（硬件）和程序（软件）。计算机和软件的优势是自动化批量处理。

所以后台原型的设计除了人工操作的部分，还有另一个重要的部分，自动化。我们如何将业务中的数据，抽象成系统能处理的数据呢？我们来看一个美团的案例

美团在初期还是个团购网站时，每一单上单，都需要人工手动来填写一系列内容，从标题到文案。公司有一只编辑团队专门做这件事。随着上单量井喷式爆发，这种纯手工编辑的方式，显然非常低效和不可规模化。

那么我们是否能将编写文案的人工部分抽象出来，自动化起来呢？我们拿最需要抓眼球的标题来举例。标题中包含的信息，其实已经在上单时，由销售和店家填写好了。我们可以把这些字段，稍加组合形成标题。

上单活动填写表单

• 代金券面值：30
• 团购价：1
• 参与活动：超级星期二
• 使用时间：周二
• 使用范围：全场通用
• 使用次数限制：1
• 库存：500
• 是否为连锁品牌：是
• 是否有wifi：有
• 产品描述（限35字）：杭州售价着陆璀璨群星城，最接地气的民间烤鱼和香锅，很辣，很上瘾！

以上这些信息，线下BD在和店家对活动内容时，已经填写好。我们直接使用活动信息生成标题即可完成全自动化上单。

是不是眼前一亮？ 这一自动化策略实现后，解散了一只近百人的编辑审核团队，帮助美团上单成本降低90%，效率提升8倍。因此美团内部称这个项目为908，后续这个思路延展成自动化一切。 （这里只简单讲了一点点，推荐大家直接看原文）

优秀的产品原型应该首先抽象业务逻辑，将能够自动化的部分交给机器去做。必须手动的部分，设计好工作流，让使用者在顺畅的工作流中完成对信息进行的加工处理。

能够处理好以上两点，可以说是做出了一套不错的产品原型。

三. 扩展阅读

• 用户管理系统 - 用户权限设计从入门到精通

本文作者

蒋川，卡拉云联合创始人，B 端产品经理，专注研究企业内部生产力工具实施搭建。

卡拉云：快速搭建企业内部工具的低代码开发平台，只要会写SQL，即可快速上手。

如果本文对你有帮助，想了解更多，欢迎访问我们的网站「卡拉云」