页面设计

在团队分工明确、人力储备充足的情况下，开发一套全新的 B 端业务系统。界面设计的流程一般如下：

产品经理绘制线框图原型，表达软件中每个页面的设计需求。线框图的重点在于说清楚界面上的交互功能设计，而非 UI 效果。产品经理需要将每个页面的排版形式、控件设计以及交互效果，用最通俗易懂的形式表达出来，以便其他同事能够快速理解。
UE 设计师协助产品经理完善交互体验，并制作交互原型。
UI 设计师基于交互原型进行美工设计，生成切图文件。
前端工程师拿到切图文件进行前端开发，包括实现交互动效等。

一套业务系统上线之后，后期迭代基本上不再需要 UE 和 UI 设计师的支持。前端工程师参考线框图就可以直接进行前端研发。因为前端工程师一般会采用现成的控件，在这种情况下，产品经理相当于同时承担了交互设计师的职责，一定要保证线框图排版整齐、重点突出。

做界面设计的时候，多研究并借鉴成熟软件的界面设计方案，可以提升设计能力，少走弯路。结合自己所设计的软件形态，找到行业内相似的 SaaS 软件，借鉴并参考其布局和交互方式，可以提升设计效率和合理性。

产品经理要经常浏览、研究不同系统或 APP 的交互设计方案，多看、多用，很多基本的交互设计感觉就会潜移默化地植入在脑海里。在做产品设计的时候，就会想起曾经见过的类似功能设计，从而借鉴参考。

B 端产品不需要花哨的前端页面，不需要充满创意的控制。B 端产品的用户解决的是业务问题、提高效果，交互体验并不是他们最在意的，而且复杂的界面和交互设计会增加研发的工作量。选用标准的控件方案可以节约产品经理和前端工程师大量的时间。

在一个新系统从无到有的设计过程里，首先要明确导航方式和框架结构，其中有两个要素很重要：

首先是内置多标签页，指系统内部具备多标签的交互形态。打开一个新页面和菜单时，会在框架内部打开一个新页签。虽然现在浏览器本身都支持浏览器级别的多标签页，但在某些场景下，系统级别的多标签页设计很有必要。

无标签页的设计虽然在前端研发时很简单，但不能同时打开多个窗口操作。内置多标签页可以让多场景平行处理、平滑切换。对于需要嵌入软电话条的系统，一般要使用内嵌多标签页，避免软电话条的会话状态数据不一致。

缺点是页签打开太多容易让浏览器崩溃，对前端技术框架要求高一些。

其次是排版方式。一般来讲，典型的排版方式包括横排排版、竖排排版以及横竖混合排版。横排排版常见于官网、企业门户，除此之外已经很少见了。竖排排版是当前的主流选择。

横排排版的优点是，对于二级菜单选项多、结构复杂的情况，可以做比较好的级联展现效果，多见于官网。在企业门户场景下，适合多应用、多系统的整合呈现。缺点是菜单过多后，尾部会被隐藏；文字过多后，菜单会被撑长，不容易找到想要的菜单。

竖排导航的优点是，展开菜单后名称一目了然，折叠后通过图标快速定位菜单，折叠后可以节省屏幕空间，并且有足够的空间容纳非常多的一级菜单。对于移动场景，UI 框架比较简单，一般采用底部导航菜单的方式。

从定义上来讲，首页是指用户登录进入的默认页；工作台一般是指集成办公页面，用户在工作台应该能够集中完成任务的分发和处理。多数时候，直接将首页以工作台的方式实现，但也并不绝对。首页到底该怎么设计，主要还是看业务场景。

设计首页可以从两类场景出发分别设计：

针对管理人员的首页设计：管理人员首页一般包含快捷菜单、公告消息、待办以及大量实时数据仪表盘。相比其他类型的用户，管理人员使用系统的时间更少，因此一个能够快速直接解决问题的首页就显得很重要。
针对执行人员的首页设计：执行人员首页应该包括快捷菜单、公告、消息、仪表盘，尤其是待办组件，罗列所有需要处理的工作和任务。针对执行人员比较理想的系统设计，应该由系统半自动化地输出工作任务，用户只需要每天按照系统给定的优先级，将每一条工作任务执行好，做到日清日结。

移动办公场景下，首页设计要满足移动办公的便携性，符合高频碎片化的操作需求，而不是沉浸式设计。在移动 APP 里面，常见的首页可能采用消息页、仪表盘、待办或者工作台的形式。

B 端产品的全局搜索功能是一个非常精巧的设计组件，但往往被人忽略。强大的全局搜索可以帮助用户查询功能、视图、数据、导航菜单、报表等任意类型的资源，而不是单纯检索一些报告和文档。

对于复杂的全局搜索进行设计和实现，也需要耗费很多时间和精力。但对于一款成熟的商业化产品，一定要有强大的全局搜索能力。

成熟的商业化软件产品应该提供灵活的消息配置能力，以便用户自己决定接受什么样的消息提醒。

对于一套独立的软件系统，通知组件最好只有两类：公告和消息。

公告是一种内容比较重的通知形式，一般要包括标题和富文本格式的正文，用户需要点进去查阅具体内容。

消息是一种轻量化的通知形式，核心目的是提醒事件发生，但并不提供细节，可以在消息里嵌入链接，跳转到相关的具体页面或场景。

根据来源，消息可以分为系统消息和人工消息。不同类型的消息应该通过唯一的消息组件进行统一管理，不应该针对不同类型的消息创建不同形态的消息组件，因为后者的设计肯定会导致信息呈现混乱和爆炸，让用户无所适从。

不论是公告还是消息，都是通知行为，并不要求用户跟进执行某个具体动作。如果希望用户执行某个动作，就需要通过待办组、待办组件来实现。

待办是一个需要用户跟进处理的任务对象，有自身的状态和过期时间；消息只是一条无状态通知。一条待办被创建之后，可以选择通过消息组件给用户发送提醒，也可以不发送。但无论是否提醒用户，待办一定要在首页或工作台某个位置呈现出来，提示用户跟进处理。

但是日程和待办之间当然有区别。日程关注的是时间范围内的工作计划，始终存在。而待办只是一条有截止时间的任务，处理完成就消失了。多数待办都没有起始时间，而只有结束时间。

一个典型的待办拥有如下关键字段：

描述：也就是待办的具体内容。
创建人：也就是创建待办的人员。
执行人：也就是需要执行待办的人员，可能是创建人，也可能是其他人。
开始时间：这个是可选的，一般不需要设置开始时间；如果需要，可能也只是为了控制待办显示的时机。
截止时间：逾期后可能会触发各种业务逻辑。
是否提醒以及提醒时间：控制待办到期前多久进行提醒，比如可以通过消息组件来进行提醒。
待办状态：这个应该由系统自动生成并维护，包含四种状态：未开始、待处理、已超时、已完成。

日程包含的关键字段有如下几个：

主题，也就是日程的名称。
内容，描述具体日程事项。
创建人，日程的创建者。
参与人，也就是日程的参与方，参与方一般会收到消息或邮件通知。
日程的开始和结束时间，精确到分钟。
日程的提醒时间，也就是在日程开始时间之前多久进行提醒。
日程是否重复，可以将日程按一定的周期规则进行重复设置。
日程的地点和附件等。

业务系统经常需要将某些数据对象的集合展现给用户，呈现的页面就是列表页。列表页是 B 端产品中最重要、最常见、最基本的页面，也很讲究设计技巧。

对于研发人员来讲，如果把所有列表页一一开发出来，会是一个巨大的劳动。所以可以对列表页进行高度抽象，因为所有列表页上实现的操作不外乎增删查改。

通过观察成熟的列表页可以发现，列表页上的元素主要包括检索条件区域、结果列表区域、分页器等有限类型。所以只需要实现一套高度灵活的前端控件，能够自定义配置所有内容，就可以实现列表页的灵活定制。

虽然实现这样一套灵活控件的周期比较长，但长远来看是非常有必要的。对于自研自用的系统，多数情况下选用硬编码列表页，是投入产出比最高的方法。但是对于一款商业化软件产品，面临不同的客户诉求，就要考虑在合适的时机实现一套灵活的自定义列表控件，一般也叫视图编辑器。

很多时候，用户只需要浏览几页数据，但是代码可能读取了所有数据。如果数据量非常大，就会对数据库造成压力。不要小看这个问题，实际工作中经常出现因为分页不合理导致数据库崩溃的情况。为了避免用户一次查询的数据量过大，常见的做法是在某些日期选择字段上做控制。

详情页包括单条数据的呈现和编辑页面，是 B 端产品里最基本、最重要的页面形态。

自研系统往往采用硬编码的方式实现详情页，而商业化的软件产品则是通过产品化功能，以配置的方式将背后的数据对象按照要求的格式呈现出来。

近些年来，很多商业软件为了提高办公协作效率，都实现了针对详情页的数据对象添加评论的功能。不仅可以评论，还可以艾特某个人，这样对方就会在消息盒子里收到提醒。这个设计范式现在已经被广泛采用了。