后台产品设计要点
(内容为学习摘抄笔记)
*一、后台设计八大法则
1、布局-有规律
2、列表-排序
默认按照创建时间降序排序,信息反复修改的列表按照修改时间降序排序,业务按照先来后到的列表按照创建时间升序排列(如:举报信息列表)
3、列表-默认信息
优先级按照:唯一编码—名称内容(过长时部分显示)—状态值—时间值—辅助信息
4、图标
用图标按钮来区分功能,且进行颜色区分
5、表单-要给出默认项
6、表单-命名
业务专有名词、动宾结构(最好不要用技术专有名词、越能直接表达出操作越好)
7、使用大白话
二次确认弹窗不要使用确定、取消,直接写出操作的动作
8、日志-记录细节,有用
操作日志一般包括:谁什么时候、什么IP、通过什么系统,对什么模块(如订单模块)、进行了什么操作(修改信息),数据是什么(用户名,修改前为:***,修改后为***),操作级别是什么(如一般性操作)
某些敏感性操作可触发安全警报,向上级发送信息或邮件
*二、其他要点:
1、功能一般要做正反两套,且操作按钮要放到一起(封号/解封)
2、删除信息时要做Double check ,并显示即将删除的内容提供确认
3、批量操作
一般操作流程:1、选择批量操作对象—2、选择操作方式—3、中间页确认,填充其他数据—4、执行操作—5、操作反馈—6、操作完成
当操作完成后涉及到数据的迁移时,可以选择:1、刷新当前页,2、跳转到数据迁移页面
4、可以在后台设计“我的模块”显示“我”可以查看到的内容来代替权限控制
5、Dashboard(数据可视化模块)make it easier to react to problems and maintain system health.
关注效益—关注数据—关注商业—实现升级
这是《后台产品设计指南》系列文章的 第14篇 内容,更多精彩可以点击下方链接查看。
后台产品设计指南
详情页是用来展示内容详细信息的载体。在后台产品列表页面中,因为页面空间的限制需要优先展示内容的关键信息,而完整的信息则需要在详情页中查看。设计合理的详情页能帮助用户更快捷地获取信息,从而更好地提高效率。
内容详情页的入口一般在列表右侧的操作链接区域,点击即可查看详情。
还有一种设计是在列表标题字段上添加跳转链接,比如文章标题、客户名称。在列表中可能会出现多个链接,比如订单列表中在客户名称和商品名称上都可以添加链接,方便用户查看。
这两种设计是可以并存的,其中第一种为标配,第二种为可选项。
后台详情页的展现形式包括弹窗和新页面两种形式。弹窗适用于详情页内容比较少的轻量场景,新页面适用于内容比较多的场景。有些后台产品中支持多标。签页,在新页面浏览内容时还可以切换查看其他页面的内容
在一些后台产品中为了节省开发成本,没有提供专门的详情页面,而是 将编辑页中的操作禁用掉 ,代替详情页面给用户使用;甚至有些产品中 只提供了新增页和编辑页 ,用户需要在编辑页中查看内容详情。这种设计一般适用于文章、评论这种既有编辑又有详情展示的场景;本身不需要编辑的数据记录还是需要单独的详情页。
1.内容的关键信息尽量展示在前面,方便用户第一时间找到关键信息。
2.内容过多时可以通过分组来展示,比如客户详情可以按照基础信息、客户意向、流动记录等维度来展示客户的信息。
3.详情页面中需要添加编辑功能入口,大多数情况下这个编辑时针对整个内容详情的;也可以使针对页面中部分内容进行编辑,然后保存。如果内容本身没有修改,保存时不能修改内容的更新时间字段,从而保证信息的准确性。
4.详情页面可以考虑增加上一个下一个切换功能,方便用户浏览临近的数据。
5. 图片元素需要支持查看大图,旋转等操作;音频和视频元素需要支持播放操作,因为flash已经停用,需要使用H5来实现播放器。
列表页、添加页和详情页都是后台中比较常用的页面。多浏览一些第三方的系统,接触地多了就能找到感觉,通过再实践中总结出产品规范,帮助我们更高效地进行产品设计。
在写作过程中,如果有意见或者想法,欢迎有兴趣的读者添加我的微信一起交流探索,共同进步。
后台产品设计指南
按钮是我们使用产品过程中必须可少的元素,本文会和大家一起了解下按钮在产品设计过程中需要注意的事项。
按钮是网页上的一个常用组件,用于触发某种特定的操作。它有6种状态,分别是默认、鼠标悬浮、点击激活、聚焦、加载、禁用。
默认状态表示组件处于活动状态,但是当前并未使用。
鼠标悬浮状态表示光标在按钮上悬浮显示手型。
点击激活状态表示按钮当前被选中使用的状态。
聚焦状态不太容易理解,它是指电脑光标当前所处的位置,使用tab或者方向键可以快速切换选中的内容。
加载状态是在用户操作没有立刻执行成功需要等待一定时间时使用的交互状态,比如登录按钮在登录过程中显示加载状态。
禁用状态表示按钮当前无法使用,不能进行操作。
主按钮和次要按钮
主按钮是指页面上的核心操作,往往只有一个,一般都是填充样式,比如客户列表页面的新增客户按钮、新增客户弹窗中的保存按钮。如果页面上没有特别核心的操作,主按钮并不是必须存在的。
次要按钮是指页面上的非核心操作,一般都是轮廓样式,相对主按钮会弱化许多,比如页面上的批量上架、批量下架、删除按钮等等。
文字按钮
文字按钮基本上等同于链接,可以多次使用。文字按钮比较容易理解,一般不会存在歧义。
图标按钮
图标按钮是指用图片展现功能的按钮,一般都使用约定俗成的图片,比如消息,保存等。图标按钮可以增加悬浮提示信息,这个提示信息不是必须的。
下面是知乎首页的截图,其中提问是主按钮,赞同是次要按钮;推荐是文字按钮,消息中心和私信是图标按钮,这里的图标按钮就没有悬浮提示。
1.从视觉层面上看,主按钮、次要按钮、文字按钮和图标按钮的重要程度是一直在下降的。
2.通过合理的组合,可以引导用户用户在完成平台期望用户完成的操作,比如强化某一种操作或者弱化某一种操作。
3.按钮要放在合适的位置,放在用户能最快操作的位置。比如下面的截图中,搜索按钮应该在重置左侧,紧挨着搜索条件,而不是相反的设计。这是因为在这个页面用户选择搜索条件后最常用的操作是搜索,设计上应该帮助用户快速实现搜索操作。
4.按钮的圆角、颜色、尺寸、文字、阴影一定程度上能影响用户的感知,在设计的时候一定要注意规范。
比如圆角的辨识度更高,传达了简单、乐观和开放的态度,这一点是通过大量的调研数据总结出来的。
按钮是后台使用非常频繁的组件,根据使用场景结合设计规范才能设计出来符合使用习惯,简单易用的后台页面。同时这些规范可能是在动态变化的,这就需要产品岗位能主动学习,主动接触新鲜的事物。
在写作过程中,如果有意见或者想法,欢迎有兴趣的读者添加我的微信一起交流探索,共同进步。
缘起在以前的一个东家干活时提后台产品需求,后台开发大锅向我要UI设计,我当时的第一反应是:后台能用就行了?还需要UI设计??
是的,这就是问题之所在。根据前东家的经历,加上一般来说的想法,给内部人员使用的后台,从来都没想到过还需要经过设计部这个流程——赶快做完投入使用就行了,要什么用户体验?要什么自行车?要什么手表……=。=
凝望着开发GG水汪汪的大眼镜(好吧其实我只是觉得貌似定个属于公司自己的UI风格也挺有道理的,而且还能提升使用后台人员的幸福感,从而间接提高工作效率blabla……怎么貌似括号里的注释吐槽也可以这么长……),我终于开始思考后台产品设计的更高层次。
说干就干,于是立即开始骚扰度娘,走向西方求取真金啊不真经……
------------分割线(楼主查询资料中,敬请期待)分割线------------
承:
让我们继续。
暂且先将取经结果放在一边,回想从前对后台的认识,其实就是最简单的线框图,和用Axure基本元件画出来的没什么两样。
类似这样:
或者这样:
这么看来貌似没什么问题嘛,可以用嘛~~相信很多童鞋都是这么想的,于是我翻了翻有设计的案例。
比如这样:
这样:
以及这样:
……
…………
………………
好吧设计师大大,请给我一个后台的UI设计=。=
------------分割线(楼主和设计师斡旋中)分割线------------
转:
几经威逼利诱一哭二闹三上吊晓之以理动之以情申之以大义之后,终于拿到了后台设计的样板。
这是登录界面:
这是单点界面:
这是具体系统界面:
比较之下,总算有点感觉了呢,貌似看到了我们自己的后台style了。
OK,那就这么定了吧~
------------分割线(楼主整理总结中)分割线------------
合:
如果把后台也当做应当认真对待的产品,那么使用他的童鞋(比如运营、市场、商务等)就是这个产品的用户,我们除了考虑这个产品能不能用的同时,还需要像对待前端产品一样,更进一步考虑好不好用、用着爽不爽舒不舒服的问题,这个时候为后台也做一些UI设计也就有所必要了,毕竟提高了童鞋们的工作效率,也是对公司业务整体效率提升的重大帮助。
另外,在后台从无到有的初期,除了UI设计,各类元件和界面的重构也是为了今后的开发打基础。实际上这一次设计和重构之后,后面的后台开发工作就可以直接复用这些劳动成果了,确实是很有裨益啊:)
最后分享个关于后台产品设计的链接(虽然貌似做得不算好看,仅供参考了):
http://www.luexiao.com/group/blog/119540
http://www.luexiao.com/group/blog/119541
http://www.luexiao.com/group/blog/119542
---没有分割线了,完---
后台产品设计指南
弹窗是后台产品中比较常见的组件,本文会和大家一起了解下弹窗的定义,使用场景及相关规范。
弹窗是一种中断用户当前操作的组件,引导用户进行下一步操作。
弹窗包括模态弹窗和非模态弹窗,前者是指会中断用户操作,需要用户进行交互的弹窗;后者则是指不影响用户当前操作的弹窗。
弹窗组件可以看做由主体区域、关闭入口、遮罩层三部分组成。主体区域包括相关文案,操作按钮;关闭按钮一般在右上方;遮罩层是半透明的黑色,有些弹窗支持点击遮罩层关闭,和关闭按钮效果是一致的。
主体区域
主题区域的内容往往千差万别,但可以总结为提示信息类和引导操作类。
提示信息类主要是显示关键信息,用户只需要确认即可。比如toast提示,tips提示就是这个类型。
而引导操作类则一般需要填写内容,保存确认,会与其他数据产生交互。
关闭入口
弹窗中的关闭入口主要包括以下几种:
1.弹窗右上角,用户关闭弹窗一般都会点击右上角关闭按钮,所以要设计的尽可能的明显。
2.弹窗主体区域内,经常会和确认按钮一起出现,但并是绝对的。比如上面的弹窗截图就只有一个确认按钮,这里点击确认也会关闭弹窗。
3.遮罩层,在一些系统中支持点击遮罩层关闭弹窗,这个操作确实比较方便,但有时候也会因为误操作导致带来麻烦。可以通过存储草稿或者弹窗确认的形式来降低误操作风险。
4.ESC键,虽然很多人不知道或者不使用ESC键,但这个快捷键对于部分人来说确实是一个很舒服的体验,我们在设计弹窗时也可以考虑进去
遮罩层
遮罩层是半透明的黑色,具体的色值和透明度需要单独设计,过深和过浅的设计都会影响用户使用。
在后台产品多层弹窗是经常出现的,在设计中应该尽可能控制在2层以内。过多的层级会让用户困惑,不知道自己当前所处的步骤;同时过多的层级在程序处理上也会相对麻烦一点。
下面会列举一下常见的弹窗类型,基本上覆盖了后台产品中的各种使用场景。需要说明的是弹窗的内容没有固定的限制,是根据产品的功能来自行设计的,千万不能生搬硬套。
1.新页面一般用于比较复杂的表单操作,而弹窗适用于轻量的操作。如果内容较多,仍使用弹窗时可以考虑通过合理的分组,分步、排列来降序用户学习的复杂度。
2.弹窗的宽度是遵循一定的规范的,过大的弹窗在笔记本及低分辨率显示器上体验很不友好
3.弹窗内的文案内容也是有规范,这里推荐大家学习一下有赞设计语言系统,里面的很多规范都可以直接借鉴。
我们在设计产品时需要根据使用场景来选择合适的弹窗,同时要尽可能地满足交互规范和用户体验,保证用户操作体验的连贯性和数据的安全性。
在写作过程中,如果有意见或者想法,欢迎有兴趣的读者添加我的微信一起交流探索,共同进步。
后台产品设计指南
把复杂、抽象的数据通过可视的方式以人们更易理解的形式展示出来的一系列手段叫做数据可视化。数据可视化在后台产品中的应用主要包括和数据图表数据大屏和两部分,本文会和大家介绍一下数据可视化的产品设计规范。
数据图表一般出现在后台产品中的首页、统计模块。后面提到的数据大屏实际上也是不同数据图表的组合,因为比较特殊所以单独进行介绍。
后台的首页可以是简单的欢迎页面,但这样做会比较浪费首页这个黄金位置。更合适的做法是根据用户的角色和身份设计不同的内容,展示用户当前的待办、平台的关键数据、数据预警,用图表的形式展示会更加直观。用户一进入首页就能看到核心内容,可以知道当前的宏观情况,接下来要做哪些事情。
至于统计模块则是平台管理层决策的利器,除了展示基础的数据报表、图表,还需要结合平台业务,相关政策等信息给到用户决策的辅助信息。下面和大家介绍一下常用的数据图表类型。
柱状图
柱状图一般用来表达某种分类下的数据的大小,分类可以是单个也可以是多个。比如某地2021年不同月份的最大值。
横向的柱状图也叫条形图,和柱状图的使用场景比较类似。条形图更适用于类别名称比较长的数据展示,使用柱状图会出现数据展示不全的情况。
折线图
折线图一般用来反映数据一段时间内的变化趋势。比如最近10年的考研报名人数。
柱状图和折线图有些类似,柱状图适合数据较少时的分析,折线图适合连续时间内较多数据的分析。
饼图
饼图一般用来表达不同类型的数据的占比情况。比如某公司不同部门的业绩占比。饼图也有一些特殊的展现形式,比如玫瑰图,理解起来需要一定的成本。
散点图
散点图一般用来变现两组数据之间的是否存在某种关联,这个关系可能是线性相关,也可能是正相关或者其他类型。比如员工工作年限和薪资的对应关系。
雷达图
雷达图一般用来对不同指标进行对比分析。比如腾讯公司产品经理的能力雷达图。
热力图
热力地图用高亮的形式表达数据的集中区域。比如国内国庆假期游客的分布情况。
关系图
关系图一般用来表示实物之间的相互联系。比如下图中围绕李白展开的关系图。
漏斗图
漏斗图一般用来表达不同业务环节的价值转化情况。比如电商行业客户访问、注册、下单、付费的转化数据。
其他诸如K线图、桑基图、盒须图等类型使用的场景不多,这里就不做展开,感兴趣的读者可以自行研究。
数据大屏是以大屏为主要载体的数据可视化设计。数据大屏是数据的最后应用环节,与数据怎么收集、清洗、处理,是否使用数仓技术没有必然的联系。
数据大屏设计流程
1.了解业务流程
数据大屏一般是用来做信息展示、数据分析和监控预警,无论是哪一种都需要对业务有充分的理解,否则设计出来的大屏只能是空中楼阁。
2.提炼数据指标
每个行业的数据指标是不同的,比如电商消费的核心数据就是GMV;购买人数,订单数,最受欢迎品牌就是次要数据。大屏因为空间限制可以展示的内容有限,一定要优先展示核心数据。
3.确定分析维度
同一个数据指标有不同的分析维度,比如电商GMV可以统计平台的累计金额,也可以按照月份统计新增金额,还可以按照商品类型来统计数据。
4.确定图表类型
这个步骤需要使用到前面提到的图表,根据业务数据里选择合理的图表类型。选择图表时既要考虑用户能直观地理解,又要考虑开发实现的可行性。
5.了解大屏参数
在正式输出设计稿之前,需要提前了解现场环境中信号源电脑的分辨率以及大屏的相关参数,如果没有提前了解做出来的效果很容易出问题,再返工会浪费很多成本。
6.页面设计稿
设计师按照一定的规范根据要展现的内容输出设计稿。大屏产品不能贪图炫技,而忽视了本质,即大屏是为了高效地展示信息,提供决策辅助。
7.程序开发实现
这个过程包括前端样式的实现和数据的接入,实际上数据的接入在前期就可以先行了。有一些效果开发很难实现,这个时候可以设计师配合提供切图实现。开发完成后需要内部验收测试,除了关注样式还需要验证数据的准确性。
大屏适配
数据大屏的展示可以使拼接屏,也可以使一块完整的大屏。数据大屏的本质是把电脑屏幕通过有线信号投放到大屏上,两者的内容是一致的。
一般情况下我们需要了解大屏的类型和分辨率,选择合适的设计稿尺寸。如果 大屏和电脑比例一致 ,可以按照大屏的分辨率来做设计稿,然后再进行开发实现;或者是使用等比例缩小的分辨率尺寸来做设计稿,再导出2倍图和开发实现。如果 大屏和电脑比例不一致 ,这个时候需要优先保证大屏上的展示效果,电脑上和大屏上会出现一定的误差。
数据大屏实现后,一定要到现场进行调试,避免出现突发情况。数据大屏的设计稿和开发适配不需要产品经理过多地关注,只需要关注最终的质量即可。
注意事项
1.数据大屏上一定要有主次,不能贪多,也不需要炫技;
2.数据大屏的字体大小和PC上有区别,需要重点关注;
3.需要根据行业、应用场景等因素选择合适的配色方案;
4.合理地使用动效可以增强大屏的品质和空间感。
数据可视化在后台产品中应用非常广泛,先了解数据可视化的应用场景和设计规范才能设计出实用的可视化产品。
在写作过程中,如果有意见或者想法,欢迎有兴趣的读者添加我的微信一起交流探索,共同进步。
这两天3.8妇女节,各大电商又开始不断推出促销活动,借势营销。电商平台仿佛不愿意放过任一个可以作为营销话题的日子,不断推陈出新。经过10多年的电商经验积累,现在做起活动来游刃有余,丰富多样。
下图是我从淘宝、京东上取的两个活动页面,可以看出页面自定义程度很高,美观大方。另一种叫法叫做店铺装修或页面配置,那么问题来了, 这样一个自定义页面怎么配置?怎样通过系统化的方式实现页面动态配置。
由于页面动态配置的内容较多,所以打算分两篇长文介绍,第一篇先讲页面动态配置的整体产品逻辑,第二篇详细描述各组件的功能,一直到组装之后的解析。
页面动态配置是CMS系统(内容管理系统)的一部分,在电商行业,CMS系统有时会局限用作页面动态配置的功能。有时也叫作“ 装修 ”,店铺装修、页面装修、自定义新页面。平台见到的首页管理和新建活动页面都属于此类范畴。
在PC电商时代,页面的自定义比作盖楼,添加一个楼层,每层可以自定义内容,譬如商品、优惠券、商品排名等。“淘宝旺铺“就是店铺装修发展出来的一门生意,淘宝店家可以选择基础模块的内容,编辑首页或新建页面,动态配置页面。
可以把页面的动态配置比作乐高玩具,每一个组件就像乐高积木,可以用它搭建不同的乐高玩具,就类似组装成不同的动态页面。我将页面的动态配置分为3步:组件→ 位置+内容 → 动态页面,如下图。
2.1 基础组件
组件是动态页面的基础,提供给用户编辑具体展示的信息。有许多类型的组件:图片轮播、ICON、优惠券等,每种组件都可以有多个不同的样式,选择内部展示的内容或者自定义。用的最常见的就是链接,组件显示样式虽然多样,但是点击之后通往的页面选择库却是共通的。例如:新的活动页面、商品详情页、商品聚合页、购物车、客服等等。
基础组件的定义和解析是自定义页面的核心,不同的组件有不同的功能,表示不同类型的内容。每个组件都需要单独设计,定义其规则和样式。 例如ICON、图片轮播就是简单的图片展示,商品排名对应的算法较为复杂,需要实时去取动态排名。
2.2 位置+内容
有了组件之后,用户在设置或者系统在解析的时候,首先要确定组件在自定义页面中的位置。位置可以称为“楼层”,每个页面的各楼层可以定义名称、设置背景、配置内容,目前最主流的交互是拖动组件到相应的位置,设置内容之后实时预览,自定义页面动态可视化。
2.3 动态页面
对于整个动态页面,需要定义生效时间、结束时间、活动页面名称等基础信息。设置之后可生成相应的链接进行预览。
动态页面是由不同的组件内容构成,首先按照各组件位置去解析,然后再去解析组件的内容(样式、图片/商品、背景、链接等)。按照上图的反向流程走,就能解析出对应的自定义页面内容。
首页设置也是相同,类似自定义页面,可动态设置首页内容,动态添加自定义组件。目前绝大部分电商首页都是动态配置,有着丰富的自定义内容。
配置组件有许多种,常见的图片轮播、 商品推荐、商品分类、 宝贝排行、图标(ICON)这几种形式,其实是富文本、 客服、优惠券、满减活动、满赠活动、自定义区域、商品搜索、文字、公告、倒计时、Tab组件(顶部、底部)。
丰富的自定义组件可以实现各式各样的活动页面,前面举例的京东、淘宝活动页都是通过CMS配置实现。
至于不同的组件设计和功能,下篇再详细讲解。
组件之间有些通用的自定义要素:
页面动态配置的整体产品逻辑基本已经介绍完毕,可以了解到,页面动态配置看似复杂,理顺之后发现其实就分为三个步骤,绝大部分的复杂度增加只是基础配置组件的丰富。
虽然CMS系统产品逻辑简单,但是页面要做到较高的自定义配置程度,需要技术框架的高效率和较强的可扩展性。在浏览一个自定义页面时,系统要逐步去解析该页面下的自定义组件内容和要素,运算量很大。
目前绝大部门电商公司的自定义页面仅仅停留在一个初级阶段,限于首页和少数特殊页面的自定义配置,而且自定义程度较低。本文提供了CMS系统的产品设计思路,落到实际项目中,还需要权衡实际需求和自定义配置程度之间的关系。
需求调研与分析完成后,就是自己对内容的消化和吸收。首先要做的事情是自己先清晰地理解一个产品。只有自己理解了,才能更好地推进产品进行开发。
先梳理清楚线下的业务流程。将线下的业务流程梳理清楚以后,然后才是对产品的思考。这里要介绍几种帮助自己更好地梳理业务流程的工具。
状态图,流程图,泳道图。三种图,所起到的作用是不一样的。下面我详细说明。
a.状态图
状态图的作用是让人清楚业务的实现需要经历的状态序列,以及引起状态转移的事件,和因状态转移而伴随的动作。状态图的驱动是基于状态的转换。下面我以点餐为例子。
业务的开始和结束用圆角矩形表示。业务的状态以矩形表示。每一个矩形都表示一个状态。菱形表示业务分支。每一个矩形之间都伴随着一个动作。
也许会有人觉得,这样做将简单的事情复杂化了。如果对于简单的业务逻辑,确实有点多此一举,但如果一个业务流程中存在很多个(7 个 +?)状态的时候,我相信状态图能让你在进行业务梳理时保持比较清醒的头脑。
b.流程图
流程图,相信大多数人对此并不陌生。但是,我看见很多人绘制的流程图并不是十分规范。不规范的流程图,自己理解起来可能没有什么问题,但是别人可能就会产生误解。
流程图,我将它分为分为三步走。1.流程图。2.泳道图。3.分阶段的泳道图。下面一个一个介绍。
业务流程图描述的是完整的业务流程,以业务处理过程为中心,一般没有数据的概念。流程图以动作来推动业务前进。下面还是以点餐作为例子。
同样业务的开始和结束用圆角矩形表示,而每一个动作则以矩形表示,菱形表示可能会出现的分支。可以清晰的看到流程图没有任何状态标识。状态图与流程图表达的不同效果一眼便知。
流程图更加关注的是业务实现具体需要进行哪些操作。每一个动作的构成形式基本都是 “动词 + 名词” 或者 “动词” 的形,这样才能更加明晰以动作为驱动的流程图。
c.泳道图
泳道图,又称为跨职能流程图。也是我所说的流程图的第二步。作为流程图的进阶,泳道图加入了泳道表示不同角色(或岗位、部门等)。让人在了解业务流程时,也清楚由谁执行该动作。同样以点餐为例子。
可以看到,每一个动作都放在相应的泳道下,对应了执行此动作的人。这样对于业务流程中不同角色的职责也会更为明确的认识。
d.流程图终极版
可以看到,在最左边加了一个侧栏,将不同的动作划分进了不同的阶段。个人觉得这是弥补了之前没有状态说明的不足。让人在了解详细业务流程的同时,也对状态有了大概的认识。
也 许很多人,觉得花这么多时间画图会浪费很多时间。我觉得仁者见仁智者见智了。对于我个人而言,每天捣弄这些图,会很快加深我对产品的理解。特别是在业务比 较复杂,而且之前有完全没有接触过相关方面知识的时候,仅靠大脑很难有清楚的思维,但是图形化后却能很好地理解。在业务整理上多花点时间整理,我觉得是很 有必要的。
产品梳理
a.梳理好线下的业务逻辑以后,要将它抽离搬到线上。这个过程,可能会删除掉某些线下的环节。
同样以点餐为例。
可以看到,这个过程当中,厨师和勤杂工在线上不需要有操作。所以状态图和流程图看起来简洁了很多。
b.产品功能点。
依据产出的流程图,基本上可以大致确定产品的功能点。
先理出单独的功能(功能)
然后加入角色(功能 + 角色)
准备工作做好以后,可以开始搭建产品的架构图了。
页面关系
页面 + 功能
页面内架构
后面的架构就不写了。
先搭页面,再确定页面内的功能,最后细化页面内的信息。在原型出来以前,可以拿产品架构图先和别人进行一下交流。产品架构图相较于原型图,与数据库的设计思想比较一致。而原型视图化后,对于数据库设计却反而变得抽象了。另外,产品架构图修改较快捷,返工成本相对较小。
需要说明的是,产品架构图更多是需要个人的整理。
原型设计
产品梳理好以后,就要开始搭建原型了。
a.先确定通用模块:页头、页尾、一级导航、二级导航
根据产品的不同,选择合适的布局。
b.将产品架构图的内容填充到页面内,并加入文字说明操作
c.细节添加
文案
导航: 一(二、三)级导航;菜单…
常用模块交互方式
按钮
弹窗:对话框…
色彩:页面基调;字体颜色…
反馈:提示;警告;正确;错误…