后台产品和用户端产品最大的区别在于，后台更重视业务逻辑，而且后台用户更有耐心，对交互设计的要求稍微低一些。一个可用性高的后台产品功能设计，主要包括以下几步。
第一步，梳理业务逻辑，理清楚谁在什么场景下要完成什么任务，形成完整流程图。关于流程图绘制方法，可以查看《如何绘制业务流程图》一文。
第二步，依据流程图，确定产品的功能点。
第三步，搭建产品架构图。这一步需要确定页面数量、层级关系；每一个页面的功能。如果是只有一个页面的小功能，这一步可以跳过。
第四步，原型设计。确定每个页面包含哪些模块，每个模块包含哪些元素，按照用户认知顺序对页面进行布局，形成原型图。
第五步，流程走查，自己按照原型设计走一遍，或者找目标用户做可用性测试，确定有哪些操作、哪些文案是用户可能会懵逼的，进行修改，或者加说明文字、使用帮助。
案例分析
接下来，用活动上线的小功能的设计过程详细讲解一下。
第一步：理清业务逻辑
理清业务逻辑主要通过和相关使用者交流，了解他们的日常工作流程。
活动上线由活动运营同学负责，上线时需要输入活动名称、配置上线素材（图片、文案、链接），选择上线渠道（安卓／IOS／全渠道）、城市，选择是否需要分享（需要分享的话，需要配置分享的icon、文案）、设置上下线时间。
梳理之后，我们得出如下流程图：
第二步：确定页面和功能点
就活动上线这个功能而言，一个页面就足够了。页面数量的决定需要视情况而定，很多用户端的产品会把流程拆分，尽量减少庞大表单给用户造成心理压力。但是对B端和后台产品而言，用户对这个功能比较了解，而且会多次重复使用，庞大表单带来的心理压力比较小，而且用一个页面可以省去跳转页面的麻烦。
根据上一步的流程，每个步骤都是一个功能点，这个页面的功能也就随之确定下来了。
第三步：设计产品原型
1.确定整体的布局和交互；
（1）首先是每个功能的摆放顺序，符合用户的认知和操作习惯。在这里，功能的顺序按照他们一贯操作的流程来就好；
（2）表单样式布局已经有很多很成熟的设计，可以参考别的系统的设计，不要重复发明轮子，而且你的创意可能并不符合用户的常规认知，增加了学习成本。我个人会从花瓣网上查找大量的表单设计素材，研究他们的布局和交互，然后进行自己的布局设计。
下图是我参考的一个表单设计规范，摘自花瓣网，侵删。
（3）交互要做到操作前有提示，操作中有响应，操作后可撤销。
对于表单设计而言，也就是操作前，可能会出错的地方要加上操作说明（有文字提示和悬浮窗两种形式）；
操作中的响应主要目的是为了帮助用户及时发现问题，引导用户进行修改，或者告诉用户操作已经成功。常规做法是可以在输入框中加入即时校验，让用户出错时可以立刻发现；点击提交按钮时，操作成功的提示、出错的提示（出错后千万不要清空表单！这种设计会把用户逼疯！！！(>﹏<)）；
操作后的撤销主要是提交之后可以手动下线或者再次修改。
另外，这个页面的交互设计要符合整个后台系统的设计规范。
2.确定每个功能模块包括哪些元素；
表单的基本元素是标签和输入框，以及提示文字。需要注意的是文案必须要符合用户认知，提示文字需要让用户理解。
将页面里的每个功能看作一个小的功能模块，确定每个模块元素的重要层级，比如说活动列表里最重要的是活动名称，渠道信息比城市更重要等等。接下来，将元素按照布局摆放好，利用展示顺序、字体颜色来突出或弱化某些信息，最终完成原型设计。
因为初创公司的运营后台没有专门的UI设计师，所以PM需要交付高保真的页面设计图。如果项目组里有专门的UI，线框图就已经够用了。下图是这个页面最终完成的效果。
第四步：设计check
设计完成之后，很多产品经理会直接将设计稿直接交给UI，这是后台产品不好用的一个大来源。我们后台产品有着离用户近的天然优势，应该先将设计图给使用者，让他们试用。
建议可以用磨刀做好demo，然后用可用性试验的方法来进行观察。简单地说，就是向用户描述这个任务，然后不要说话，默默记录他们的使用情况，包括在每一项停留的时间，面部表情等等。对于用户明显停留很久的地方要在测试结束之后进行询问，了解他们不会使用的原因，并及时整理到产品设计笔记里。这不仅是方便这一次的修改，也是为以后的设计作个参考。
网友评论