如何设计出色的网站后台原型?

新手请教,如何设计出色的网站后台的原型?前辈们都有那些什么工作方法,设计经验,请不吝赐教!~
关注者
6127
被浏览
163813

47 个回答

时隔4个月回来再看这个回答,确实是发现有很多不够严谨的地方,也有不少朋友和我聊过这方面的问题了,特此补充一下:
1.后台的架构设计是非常复杂的,决计不是一篇千字不到的文章就可以将后台设计的整个生命周期阐述清楚,因此我建议大家把这个回答当做一个立项时候的方法论就好。
2.关于第一张图已经被很多人吐槽了,这种图是我立项的时候,自己整理思路,或者和需求方讨论的时候作为纲领来用的,主要是帮助我在需求还不清晰完整的时候,枚举出大部分可能存在的需求并进行粗略的分类,当需求已经得以窥知全貌的时候,当然还会有更加细节的功能流程图和时序图等uml吧啦吧啦的。大家如果更习惯用思维导图,其实更好。
3.一个完备的后台,可能会包括多种类型或者不同权限的用户,以及功能之间很多时候并非完全割裂,对于这样的情况,粗暴的将功能分为一个个桶自然不太合适,后续是需要对此进行功能的再次梳理和功能间的合理跳转的。
4. @justinlam 搞系统架构比我资深,他的这篇文章可以作为大家的补充阅读:如何规划系统的架构 - 遇见产品 - 知乎专栏
5.在后续的产品迭代过程中,后台的确会越来越臃肿,但是这不是在设计后台之初就不进行模块结构化设计的理由。诚然当初答题的时候我思考的不一定的完全的妥当,但是一个结构不够清晰的后台意味着以后想加功能都不知道放哪。信息架构杂乱要命的后台,无论是对使用者还是对后续的开发团队都是噩梦。总而言之,好看不重要,但是清晰的结构,正是为了以后想加功能的时候更方便顺手。初创功能不复杂的时候弄一个mvp没问题,但是题目问的并不是这个(创业的时候赶紧搞一个能用的才是要紧事)
6.欢迎吐槽,哈哈哈(做了一点微小的工作,被好多前辈点了反对,误人子弟了,有点愧疚)
---------------------------------------------------分割线-----------------------------------------------
要制作一个优秀的后台原型,我认为主要就分为三个部分:
1.对于后台功能模块的结构和页面逻辑有清晰的认识
2.能够熟练的使用原型工具
3.优秀的设计风格和设计规范

1是基础,2是进阶,3则是让原型变得出色的点缀。
  • 那么首先聊聊怎么样保证后台的功能结构和页面逻辑的清晰合理。
    很多人画原型都有一个习惯,就是不管想没想好,直接就开始打开原型工具先拉几个框,或者就照一个自认为非常不错的网站后台开始照葫芦画瓢,这在我看来都是极其危险的。网页后台不同于一般的web界面,他对于功能模块的划分和页面的逻辑要求是非常高的。一方面网站后台的层次结构相比之下要复杂的多,另外一方面,网页后台的功能更偏向于对前端页面的管理,这就导致了功能之间的关联性和引导可能就要弱得多,这样的情况下,如果没有很好的理清后台的结构就开始画原型,那么最后做出来的后台管理系统很可能就是功能的堆积,功能易用性和操作的流程性都很难得到保障。

    我将这一步需要注意的事项总结为以下几点,也是我在绘制后台原型时时刻谨记的:

  1. 画原型之前,先理清后台管理的功能模块,通过树状结构图来帮助自己划分页面和模块。大概是下面这样(仅供参考~~~)
  2. 理清模块之后,就可以着手设计后台管理系统的骨架,我个人分为三种:主模块(主要分为哪些独立的功能模块),次级分类(每个功能模块又有哪些次级的功能分类),功能事件(具体到每个功能页面内存在哪些主要的操作),大概的布局方式大概如下三种
    1)顶部选项卡划分主模块,左侧边栏划分次级分类

    2)左侧边栏汉堡包样式的层级分类(偷懒~大概就是worktile的侧边栏样式)
    3)左侧边栏二级分类列表浮出

  3. 思维导图帮助理清思路很有帮助。
  4. 思考的路线应该是自上而下,在进行模块划分时不要拘泥于具体的某个界面的展现形式。
  5. 结构和逻辑的清晰(骨架)>功能页面的设计(具体到某个页面怎么设计)>优化性质的功能设计(是否需要预览,实时存储等功能)>用户体验
  6. 必要时, 可以牺牲用户初次使用的学习成本,初次使用的学习成本是可以为用户熟练掌握后的使用效率让步的
  7. 尽量遵循亲密/对比/重复/对齐的四原则。
  8. 对于重要但是不知道如何放置的功能,可以考虑放在顶栏的右侧,而不是放在主模块上(例如把发布任务放到一堆XX管理中)
  9. 借鉴并不可耻,脑补尤为可怕。
  10. 频繁的弹窗并不是好的选择(必要时该弹还是要弹的),如果可以的话,展开和右侧浮出半页都是不错的解决方式。
  • 再来说说原型应该怎么玩
    虽然最近各种在线原型工具层出不穷,但是守旧的我还是习惯用Axure+PS的方式来完成高低保真原型的工作,具体到后台管理页面的原型绘制,我觉得一分钱的交互动效都是没有必要的,那么你需要做的只是拉框拉线罢了,这里上传一些我攒的axure控件库,有收集的也有自制的,应该能够很大程度上提高制作原型的效率(pan.baidu.com/s/1eSzBSI)。
    另外分享一个我很早之前制作的网页原型,可惜关于后台的部分在我离职交接的时候遗失了,大家凑合着看吧,希望能够帮助到大家(KPPW原型.rp_免费高速下载
  • 最后来扯一下怎么让自己画的后台页面原型逼格满满
    分享一个超级棒的网站(主题森林290+ High Quality Admin Templates),可不仅仅有各种好看到爆后台界面demo哦!!!
    看看人家歪果仁的后台界面,心水啊
    1.Oxygenna Themes

  • 2.这个动效炒鸡喜欢PLEASURE - Material Design Responsive Admin Panel
    3.EDUMIX这个也不错

    最后,Pmer在路上,与大家共勉,欢迎杭州的小伙伴请我吃饭~~~~
    收藏比赞多,心好痛,我分享的两个文件都是花了我好多时间的干货T^T,都不值得你们赞一下么QAQ
给分享干货的点个赞吧~

不太认同前面两个最高票数答案,感觉说的是制造业里的企业模块管理和供应链上的信息管理系统,即ERP,恰好有个朋友就是在金蝶做ERP销售的,现在ERP服务已经很成熟了找专业人事设计即可。而题目是如何设计后台管理系统原型,我理解的是,针对互联网产品范畴的后台管理系统。即维护用户、管理社区、跟踪分析用户行为并进行数据统计分析等。我当初搭建后台产品的时候也遇到过很多疑问,正好借着这个回答来个梳理和总结。

这里不讨论涉及供应链系统的后台产品,如电商、团购等,美团O2O供应链系统架构设计解析 里面涉及复杂的交易流程优化。

为什么说设计后台产品很难?看看这个问题的回答。
难参照竞品。用户只要大量地使用过别的产品,便会建立起相应的心智模型。然而后台对于很多人而言却非常陌生,毫无心智模型可言,也难以做竞品调研。——郑坚义
也就是说面向大众用户的前台产品,大家培养起了使用习惯,对功能有一定程度的理解,见过的模式足够多,能够建立起一定的产品模型,也容易找到参照物去模仿。而且,做后台产品需要非常懂业务,考验产品经理的核心竞争力——业务知识储备、结构化思维和系统性抽象能力。推荐看:为什么说好的产品经理一将难求? - 蒸汽机的回答

开始后台产品设计之前,先找找相类似的产品,虽然我们无法去观照其他产品的后台都是长什么样的,但是现在有不少提供标准化数据分析的SaaS服务公司,如友盟、诸葛IO。但是为什么我们很难直接采用这些公司的产品来管理和维护运营?软件运营(SaaS)模式的核心是标准化架构+定制化需求,比如体系已经成熟的ERP、CRM、OA等管理系统涉及审批流程、财务审计等更容易标准化生产。而互联网产品的业务各式各样,变化不断,还会随时出现一种全新的业务模式,所以后台产品做到标准化有一定难度。

我们先看看,类似的数据分析平台。
百度统计——最大的中文网站分析平台
诸葛IO——精细化数据分析工具
友盟_专业的移动开发者服务平台
TalkingData-移动.数据.价值
莲子数据首页-lotuseed-专业的移动数据分析服务平台
腾讯云分析

面对公司的社区型产品和运营人员提出的需求,发现以上平台都难以满足后台管理运营。但是拆解分析里面的业务逻辑能帮助你理解后台产品的模块结构。
后台产品的功能里最容易标准化的就是用户分析,新增用户、留存率、活跃度等,所以我在设计后台产品的运营数据上很大程度上参考了这些数据分析的结构和模式。而市面上的数据分析工具,最大的问题在于,我所知道的工具里还没有任何一款可以整合统计不同渠道的数据,也就是说PC、H5、iOS、Android分别进行统计,假如统计今天多少用户进行了“点赞”的操作,这个用户行为跟踪是无法进行全渠道分析,那么分析就被割裂开来,难以形成系统。并且大部分是针对移动应用,网站分析这一块只有百度做得相对详细点。后台产品是根据业务情况定制化需求的,游戏应用、O2O、电商、垂直社区、社交产品都会有形成巨大差异的后台产品模型。

针对我负责的垂直社区来进行下一步分析,结合前台产品的整体功能,我确定了后台产品的模型架构分为三大模块:运营数据分析、社区管理、交易中心。运营数据分析是用来监测用户和内容的变化趋势;社区管理是运营人员对用户和内容进行日常的维护和管理;交易中心是用来记录交易明细和收支变化趋势的(社区有打赏和红包功能)。

运营数据分析包括用户分析、内容分析和事件分析,其中有用户类别和渠道两个维度。就是说每个分析里面可以针对不同的维度,比如除去内部运营人员后今天产生多少点赞数,比如在iOS上今天产生多少点赞数。以下是我考虑功能结构的思路(下面图片涉及核心业务数据将会模糊处理):
用户分析→用户追踪→新增趋势+活跃度+留存率+用户特征
内容分析→用户生产内容追踪→新增趋势+类别情况
事件与转化→用户行为追踪→事件趋势+事件交互+事件转化


社区管理主要包括用户管理、内容维护、事件设置。社区管理在一定程度上影响运营数据的变化。比如,给用户添加标签生成用户画像。
用户管理→用户特征+用户分类→用户分析
内容维护→用户生产内容管理→分类管理+内容监控
事件设置→用户行为管理


交易中心包括总资产概况、交易明细、交易分析,结构比较简单,用来管理社区的财务和监控财务数据,与电商平台复杂的财务系统相去甚远。

以上仅仅是提供一种后台产品模型架构的思路,后台产品主要由前台产品模型和业务模式决定,不同种类的互联网产品的后台可能千差万别,勿直接套用。

说了那么多,是想说明后台产品的设计非常有挑战性,虽然由于多种原因不像前台产品那样是香饽饽,但绝对是个很好的锻炼机会。产品人除了把控流程逻辑和功能细节外,产品模型架构能力来自于业务知识储备、结构化思维和系统性抽象能力,因为你的思考维度需要跳出单线程的逻辑或单一功能的交互,要进化成梳理多线程之间的复杂逻辑或多个功能之间的交互。


好了,最后贴个干货出来,记录这一次挑战。

产品结构

产品原型

最终产出
为什么?