BI 平台方案设计中的移动查看，最容易被误解成“把报表放进手机”。但真正决定方案是否有用的，不是手机上能显示多少张图，而是用户在赶路、开会、巡店或处理异常时，能不能从一个入口找到可信数据，判断问题，并知道下一步该做什么。我设计这类流程时，会先画用户任务链路，再决定首页、指标、提醒和下钻页面；页面只是链路中的一个环节。
电脑端通常适合长时间分析、横向比较、多维筛选和复杂操作；手机端更多出现在碎片时间，用户希望快速确认状态、识别异常，或判断是否需要介入。两种设备可以使用同一套指标口径，却不一定应该使用同一套页面结构。
因此，移动查看流程的设计起点不是“要放哪些图表”，而是四个问题：谁在什么情境下打开、他要回答什么问题、看到不同结果后会采取什么动作、系统怎样让这件事可追踪。回答不清楚这些问题，页面做得再精致，也可能只是把查数成本从电脑搬到了手机。
我会先把流程拆成“触发，进入，判断，定位，行动，反馈”六个环节。它不是固定的产品模板，而是一种评审工具：每一环都要说明用户输入什么、系统返回什么，以及失败时怎么恢复。
这条链路的重点不是每个环节都必须在 BI 内完成，而是边界必须清楚。比如 BI 负责发现异常，任务系统负责分派，业务系统负责执行；如果跳转之后丢失了筛选条件和异常上下文，用户就要重新找一遍问题，流程仍然是断的。
只有页面原型，评审很难判断它是否能解决业务问题。我建议在方案阶段同步形成用户角色与场景清单、任务流程图、首屏信息层级、指标口径说明、权限与异常状态规则，以及上线后的验证方案。这些材料不必做成厚重文档，但要能让业务、产品、数据和研发对同一条流程达成一致。
尤其要把指标口径写在流程附近，而不是放在另一个无人查看的附件里。移动端页面空间有限，名称相近的指标更容易被误读。用户看到“销售额”时，至少应能判断统计周期、含税口径、退款处理方式和数据更新时间；否则，页面越快打开，错误决策也可能越快发生。
主动查看通常发生在例会前、巡店途中、出差路上或收到业务反馈之后。用户知道自己要看什么，但未必知道答案在哪张报表里。此时首页的任务是减少“找入口”的成本，而不是把所有报表都塞进一个长列表。
一个更实用的组织方式，是围绕任务而不是部门层级安排入口，例如“今日经营”“待关注异常”“我的区域”“常用分析”。这些名称只是示例，最终应从访谈、搜索记录和实际使用路径中验证。若用户习惯从业务系统进入，强行要求他先回到 BI 首页，可能反而增加一步。
预警场景看似只需要发一条消息，实际上更考验上下文传递。消息至少要交代异常对象、指标、统计范围、发生时间和判断依据，并提供可直接进入相关分析的路径。若通知只写“指标异常，请查看”，用户仍然需要重新选择区域、日期和报表，提醒本身就没有完成导航工作。
预警也不应把所有波动都推给所有人。发送阈值、接收角色、重复提醒间隔和静默时段，需要结合业务规则及使用反馈设计。对于低风险、可自行观察的变化，可以放在应用内待关注列表；对需要及时处理的异常，再通过更直接的方式触达。
以零售经营为例，区域负责人可能先确认销售和库存总体状态，再看异常门店；门店负责人更关心本店当日目标、缺货商品和待办事项；商品运营人员则可能需要按品类、库存天数和补货状态筛选。相同的数据源，不代表相同的首屏任务。
角色划分也不能只看组织架构。一个人可能同时承担管理与执行职责；临时代理人可能需要短期查看特定范围；高频使用者和偶尔使用者的入口习惯也不同。方案里最好记录“角色，场景，问题，动作”，并为角色冲突、兼岗和临时授权留出规则。
| 用户场景 | 首先要回答的问题 | 适合的移动信息 | 可能的下一步 |
|---|---|---|---|
| 管理者会前快速查看 | 总体是否偏离目标，哪些区域需要关注 | 关键指标、目标对比、异常摘要 | 进入区域分析或联系负责人 |
| 门店负责人巡店 | 本店当前经营短板是什么 | 门店指标、商品缺货、待办提醒 | 查看商品明细或处理业务事项 |
| 运营人员收到预警 | 异常从何时、何处、哪个维度开始 | 异常值、对比基准、筛选上下文 | 下钻分析、转交或记录原因 |
| 外勤人员弱网访问 | 当前能否取得足以行动的信息 | 轻量摘要、更新时间、失败提示 | 重试、保存入口或稍后继续 |
角色表的作用不是提前决定所有页面，而是把设计讨论从“首页放什么”拉回“谁需要做什么判断”。同一角色的不同场景也可能需要不同入口；反过来，不同角色若执行同一任务，也可以共享部分流程和页面组件。
电脑报表常以多列、多图和复杂筛选服务于分析；手机屏幕宽度有限，缩小后文字、图例和坐标轴容易失去可读性。问题不只是布局是否响应式，而是信息顺序是否重新按移动任务组织。
我的判断标准很直接：用户在首屏能否回答当前最重要的问题？如果不能，先检查信息优先级和入口设计，而不是继续压缩字体、缩窄图表或把筛选控件藏进更多菜单。复杂分析可以下钻，也可以引导到更合适的设备，不必为了“移动端功能齐全”把每一种操作都复制过来。
首屏指标越多，不等于用户获得的信息越多。若指标缺少目标、趋势或异常提示，用户看到的只是数字集合，仍然要自行判断哪些值得关注。更稳妥的做法是先定义该角色在该场景下要做的决策，再选择能支持决策的核心指标与必要解释信息。
“首屏应放几个指标”没有脱离场景的固定答案。指标数量要通过任务测试、设备尺寸、页面滚动行为和业务优先级确定。首页可以只展示少量摘要，但必须给出清晰的进一步查看路径；也可以展示更多卡片，只要不会遮蔽高优先级异常。
只推送指标名称和变化幅度，往往不足以支持判断。用户还需要知道与什么基准比较、统计时间是否完整、影响对象是什么，以及是否存在数据延迟。否则，通知可能造成误报、重复确认或不必要的跨部门沟通。
预警到报表的跳转需要保留上下文，包括时间范围、组织范围、指标口径和异常对象。用户进入页面后应能看出“为什么来到这里”。如果每次都落到通用首页，通知只承担了打扰功能，没有承担定位功能。
移动场景中的权限不仅是“能不能进系统”，还包括用户能看到哪些组织、哪些敏感字段能否展示、链接能否转发、截图或导出是否受限，以及岗位变化后权限怎样回收。把权限留到上线前补，会让流程设计和数据治理相互冲突。
分享场景尤其要谨慎。某人有权查看一张报表，不代表他有权把链接转给任何人；某页面可在受控终端中查看，也不代表离线缓存、通知预览和截图适用相同规则。具体控制方式要由企业安全要求、平台能力和数据敏感等级共同确定。
移动 BI 还要面对弱网、后台切换、登录过期、数据未更新和接口失败。只测试顺畅网络下的成功路径，无法说明用户在真实工作环境中能否完成任务。每种失败状态都要回答三个问题：用户看到了什么、还能做什么、下一次尝试如何恢复。
例如，数据尚未更新时，不应只显示一个空白图表；加载失败时，也不应让用户分不清是网络问题、权限问题还是没有数据。清晰说明状态和可恢复动作，往往比额外增加一张图更能改善实际体验。
访问量高，可能意味着入口有效，也可能意味着用户反复寻找信息或不断刷新。停留时间长，可能是分析深入，也可能是页面难懂。单个使用指标很容易被误读，因此要把过程事件和任务结果结合起来看。
建议至少区分入口到达、首屏加载、关键内容曝光、筛选或下钻、异常查看、后续动作和失败退出。再按角色、网络、时间段和入口拆分。这样才能知道问题出在找不到入口、加载过慢、口径不清，还是页面没有提供下一步。
需求访谈不要只问“你想在手机上看哪些报表”，因为用户通常会报出已有报表名称，而不一定说明实际任务。更有效的问法是：上一次你在手机上查数据是什么时候？当时遇到什么问题？你先打开了哪里？最终根据什么决定下一步？有没有转去其他系统或联系同事？
我会把访谈中的回答整理成任务卡片，每张卡片只写一个具体任务，并记录发生频率、紧急程度、决策后果和当前替代方式。所谓“移动端必须支持”，最好有可观察的业务理由，而不是来自某个岗位的个人偏好。
并非所有移动场景都适合同一套交互。查看型任务关注快速获取结果；诊断型任务需要逐层比较和筛选；执行型任务则需要把数据与具体业务动作连接起来。把三类任务混在一个首页，容易让页面既不够快，也不够深入。
| 任务类型 | 主要目标 | 流程重点 | 不适合的做法 |
|---|---|---|---|
| 查看型 | 快速确认状态 | 入口直达、关键值醒目、更新时间明确 | 让用户先完成多步筛选 |
| 诊断型 | 解释变化来源 | 保留筛选上下文，提供合理下钻顺序 | 只显示汇总数，不允许继续定位 |
| 执行型 | 促成业务动作 | 明确责任人、跳转目标与处理反馈 | 把“查看过”误当成“处理完成” |
通常，移动端适合把查看型任务做得短，把诊断型任务做得有边界，把执行型任务做得可衔接。若某项诊断需要复杂建模、长时间对比或高精度操作，可以先让手机完成识别与初步定位，再引导到桌面端完成深度分析。
首屏应优先回答“现在正常吗”“相对目标怎么样”“是否需要我处理”。如果用户确认存在问题，再展示变化趋势、对比维度和明细入口。这样的渐进式呈现能避免把所有维度一次铺开，也能减少用户在小屏幕上反复滚动寻找重点。
指标卡片不应只包含一个孤立数值。根据场景，可以补充目标值、同比或环比、变化方向、统计周期、更新时间和异常说明。但这些信息不是越多越好，要以是否支持当前决策为准。若某项变化容易被误解，解释口径比增加装饰性趋势图更重要。
移动端最常见的断点之一，是从总览进入明细后，用户发现筛选条件被重置。正确的下钻应保留业务对象、时间范围和必要过滤条件，让用户知道自己正在解释哪一个数值。返回上一层时，也要尽量保留原位置和选择。
下钻维度应该符合业务解释路径，而不是只按数据库字段排列。例如，销售变化可能先按区域拆分，再看门店，最后看商品；库存异常可能先确认库存状态，再看库龄、销售速度和补货情况。顺序需要由业务因果关系和用户判断习惯共同决定。
权限规则要在设计阶段说明：用户通过什么身份进入、能看哪个范围、无权限时怎样解释、岗位变动后如何处理。对用户来说，“没有数据”和“没有查看权限”不是同一件事；系统如果都显示成空白，会制造错误判断和大量咨询。
数据更新时间也要成为页面信息的一部分。若指标并非实时计算，就明确最后更新时间或更新周期；若页面混合了不同刷新频率的数据，应避免用一个统一时间戳误导用户。刷新按钮能做什么、何时能看到新数据，也要与后台任务机制一致。
流程图不应只画理想路径。至少需要覆盖网络中断、身份过期、数据延迟、无权限、暂无数据、接口超时和跳转失败等状态。每种状态都要说明用户能否重试、返回哪里、是否保留筛选条件，以及需要联系谁处理。
对于弱网，不一定要承诺离线查看全部数据。可以根据风险与技术成本，考虑缓存非敏感摘要、延迟加载明细、提供最近更新时间，或允许用户稍后恢复。是否缓存、缓存多久、怎样清除，要经过安全评估，不能只为了流畅度做决定。
上线后要判断流程是否有效，不能临时挑一个容易增长的数字。项目应先定义目标用户、关键任务、统计周期和采集方式，再建立上线前基线。没有可靠基线时，可以先做小范围可用性测试，记录用户完成任务时的路径、错误和求助点。
可观察的指标包括任务完成率、从入口到关键内容的时间、无效返回次数、预警打开后的定位成功率、异常处理闭环率和用户反馈。具体口径要写清分母与时间窗口，例如“已打开预警的用户中，进入对应分析页面的人数占比”，不能只写一个含义模糊的“转化率”。
九数云面向数据分析与 BI 使用场景，适合作为讨论移动查看方案的语境。这里不把某项具体功能、性能或集成能力当作已验证事实，也不声称已经在某个客户环境完成部署；具体能力应以当前产品版本、租户配置和实施确认结果为准。下面的数字全部标注为情景模拟，只用于展示方案如何推导。
假设一家有多个门店的零售企业，希望区域负责人在手机上查看销售与库存异常。现有流程是：每天早上由数据人员整理表格发群，负责人打开电脑后再查明细；遇到异常时，通常通过电话或即时消息找门店确认原因。方案目标不是“把表格改成手机页面”，而是缩短从发现偏差到确定责任动作的路径。
在这个推演里，我会把目标拆成三类：负责人能快速判断哪些门店需要关注；进入异常后能沿着门店、商品和时间范围定位；需要业务处理时能把问题交给责任人，并留下后续核验入口。目标不是承诺某个固定提效百分比，而是先确定可测量的任务结果。
由此，需求边界可以写成：移动端负责状态确认、异常定位和处理入口；复杂的跨期分析仍可由桌面端承担；业务执行由现有业务流程完成；BI 页面负责保留筛选上下文和回访路径。这个边界可以避免把移动 BI 变成一个功能无限扩张的超级应用。
主动查看路径：区域负责人从工作台进入“区域经营”，先看到所属门店的汇总状态与异常摘要，再按异常类型进入门店列表，最后查看商品或日期维度的明细。默认范围来自其授权区域，但页面上要明确显示当前区域和统计日期，避免用户以为自己在看全公司数据。
预警触发路径：当某门店的关键指标触发企业设定规则时，负责人收到包含门店、指标、时间范围和变化基准的提醒。点击后直接进入对应门店的分析页面，异常条件保留在页面中，并可继续查看相关维度。若无权限或数据未更新，页面明确解释状态，而不是返回空白报表。
首屏只承担“判断是否值得进一步查看”的任务。它可以展示目标完成状态、异常门店数量、重点风险摘要及数据更新时间；具体指标应由企业确认口径后确定。门店列表按需要关注的程度组织，而非简单按名称排序。进入门店后，用户再选择销售、库存或其他业务视角。
动作入口也要克制。若企业已有任务系统，可以从异常页面跳转并传递门店、指标、时间等上下文；若暂时没有可靠的任务闭环，就不要假装“点击处理”已经完成业务处置。此时更诚实的设计可能是提供责任人信息、复制异常摘要或记录跟进状态，并明确数据侧无法替代实际执行。
假设当前人工整理与查询耗时为每位区域负责人每周 3 小时，异常确认平均需要 2 次沟通，移动方案的小范围测试显示，完成一次目标任务的中位耗时由 8 分钟降至 4 分钟。这些数值仅为情景模拟，不能作为真实客户结果或行业承诺。它们的用途是示范如何比较“任务过程”，而不是给方案包装一个漂亮的收益数字。
评估时还要关注代价：如果通知过多，用户可能关闭提醒；如果数据延迟没有说明，用户可能把旧数据当作实时结果；如果权限粒度不足，区域负责人可能看到不该看到的数据；如果下钻需要多次切换页面，所谓“4 分钟完成”也可能只在测试人员熟悉数据的情况下成立。
试点不必一开始覆盖所有区域。可以选取少量有代表性的负责人和门店，覆盖不同网络条件、不同使用频率和不同数据复杂度。测试任务要明确，例如“从工作台找出昨天需要关注的门店，并说明异常依据”，而不是让用户自由浏览后再问感觉如何。
观察者要记录用户是否找到入口、在哪里犹豫、是否理解指标口径、是否误读更新时间、下钻后是否保留筛选，以及最终是否完成动作。测试中出现的问题要按严重性分类：阻断任务、造成错误判断、增加操作成本或仅影响视觉偏好。优先修复前三类，不要让颜色和卡片样式压过流程缺陷。
若方案基于九数云或其他 BI 产品实施，还应在试点前逐项核对实际能力：移动端入口、身份认证方式、数据权限继承、通知跳转、筛选条件传递、缓存策略、日志采集与业务系统连接。产品能力与方案设想不一致时，要及时调整流程，而不是用未验证的承诺填补差距。
优先做“主动查看，总览，异常摘要，区域或门店定位”路径。首页保持信息聚焦，默认展示与管理范围匹配的内容，并明确时间口径和更新时间。管理者不一定需要在手机上完成全部分析，但必须能判断是否需要继续介入。
此类场景不宜一上来配置大量个性化筛选。先验证用户能否快速找到关键状态，再根据使用行为决定是否增加收藏、常用范围或自定义指标。若管理者更常通过会议材料或工作台进入，就应把入口放到真实工作路径附近，而不是只依赖独立应用首页。
重点放在上下文保留、下钻层次和指标解释。每进入一层，都应让用户知道当前对象、统计范围和筛选条件；如果某个维度不能继续拆解，要说明原因或提供替代入口。对移动屏幕而言，少而清楚的维度通常比密集的交叉表更可用。
当诊断路径变得复杂时，可以给用户一个轻量的移动初筛入口，再允许其将当前分析条件带到桌面端继续处理。这样既承认移动端的限制，也避免为了适配手机而削弱专业分析能力。
先确认数据是否能支持现场判断，再决定是否要在 BI 页面直接提供操作。若操作会影响订单、库存、客户或审批状态，应优先复用经过验证的业务系统流程，避免在分析页面重复造一套规则。BI 的价值可以是把用户带到正确的业务对象，而不是包办所有操作。
对一线人员而言，关键还包括单手操作、短文本可读性和错误恢复。按钮名称应说明动作结果，而不是使用含糊的“处理”；完成动作后要返回可核验的状态。若现场网络不稳定，应考虑是否存在安全且可接受的稍后提交机制。
先治理规则，再调整消息样式。对每条预警，确认它是否有明确责任人、是否代表可行动的变化、是否需要即时通知，以及重复触发如何合并。对于同一对象的连续异常，可以评估聚合展示或冷却时间，但必须由业务风险决定，不能为了降低消息量而隐藏重要事件。
通知最好提供分级策略：需要及时处理的直接触达，值得关注但不紧急的放入列表，低优先级变化留在报表中。发送频率和阈值应经过历史数据回放与用户验证。项目没有可靠历史数据时，可以先小范围观察，再逐步调整，不应直接把未经校准的规则推广到全部用户。
先画数据访问边界，再做页面和分享设计。确认组织范围如何继承、临时授权如何生效、岗位变化如何撤销、不同终端是否有不同限制，并测试从通知、收藏、分享链接进入时是否仍执行权限校验。不能用“用户已经登录”代替完整的授权判断。
若企业安全要求不允许在通知预览中展示具体金额或客户信息，可以只推送经过脱敏的提示，用户通过受控身份验证后再查看详情。具体方案取决于敏感等级与安全规范；便利性不能凌驾于数据治理要求之上。
先测量真实网络环境，而不是凭感觉决定是否做离线。记录页面首次加载、关键内容加载、失败恢复和重试的情况，并区分弱网、无网和服务端错误。页面可以优先加载任务所需的摘要，再按需请求明细，以免首屏被非关键图表拖慢。
如果考虑缓存，必须明确缓存内容、有效期、失效策略和本地数据保护方式。离线展示过期数据时，应让用户清楚知道数据时间，避免把“可见”误当成“最新”。在高风险业务中，展示旧数据可能比暂时无法查看更危险。
首屏越简洁，用户越容易快速判断；但压缩过度可能把关键口径、目标基准和异常原因藏得太深。解决方法不是简单增加卡片，而是分层呈现：首屏给出决策摘要，下一层解释变化，再下一层提供明细。对于容易引起误判的指标，应让必要口径在首屏可见或容易触达。
若用户在测试中频繁打开同一解释信息，说明这部分可能属于首屏必需上下文；若某些信息很少被使用且不影响判断，可以放到详情层。页面层级应依据任务证据调整，而不是依据设计者对“简洁”的审美偏好。
更及时的提醒有助于缩短发现时间，也会增加消息疲劳和误报风险。适合即时推送的，通常是具有明确责任、明确行动窗口且后果较高的异常；可以汇总处理的变化，则适合进入定期摘要或待关注清单。
取舍时要比较漏报和误报的业务成本。若漏掉异常的损失很高，提醒可以更敏感，但需要设计确认和升级机制；若波动本身常见且无需即时动作，过度推送反而会让真正重要的通知被忽略。阈值应由历史数据、业务责任和试点反馈共同确定。
移动端可以支持有限层级的诊断，但不是所有分析都适合在手机上完成。筛选维度多、需要并排比较、需要自由探索或需要复杂导出时，继续增加移动交互可能让页面变得难用。
建议为每条任务定义“移动端完成标准”。例如，手机端负责识别异常并定位到区域或业务对象；更深的归因分析在桌面端进行。关键是跳转时带上上下文，让用户不必从头复现问题。明确边界比追求功能清单完整更有价值。
“越实时越好”并不总成立。刷新频率要与业务动作窗口、源系统更新能力、计算成本和数据质量相匹配。用户如果每隔几分钟查看一次，而底层数据一天更新一次，界面做成实时刷新也不能提高决策质量。
反过来，若业务确实依赖短周期变化，就要明确端到端链路：数据何时产生、何时进入仓库、何时完成计算、页面何时刷新。不能仅凭前端刷新按钮宣称数据实时。项目应把时效目标写成可验证的口径，并区分源数据延迟和页面加载时间。
个性化首页、收藏和自定义指标能适配不同用户，但会增加维护、权限和支持成本。早期项目可以先提供有限的角色模板和常用入口，等实际使用数据证明用户有稳定差异后，再开放更灵活的配置。
如果允许用户自定义指标或筛选，要规定命名、口径、共享范围和失效后的处理方式。否则，同名不同义或同义不同名会增加沟通成本。个性化不是越多越好，它需要与治理能力同步建设。
| 需要做出的取舍 | 优先移动端的条件 | 应保留桌面端或后续迭代的条件 |
|---|---|---|
| 首屏信息多少 | 任务高频且判断目标明确 | 口径复杂、需要多项并列分析 |
| 下钻深度 | 少量维度即可定位并触发行动 | 需要自由探索、复杂交叉分析 |
| 通知方式 | 异常有明确责任人和处理时限 | 变化低风险、无需立即介入 |
| 实时刷新 | 数据变化会影响短时业务决策 | 源数据更新慢或刷新无实际决策价值 |
| 个性化能力 | 角色差异稳定且治理规则成熟 | 需求尚未验证、口径维护能力不足 |
如果项目刚启动，不需要先规划几十个移动页面。我建议先选一个高价值任务，例如管理者确认经营异常，或一线人员定位库存问题，用一周左右完成轻量梳理：访谈目标用户、画出现有路径、标出入口和权限、制作低保真流程，再用真实任务做一次可用性验证。
验证时不要只问“页面是否好看”，而要让参与者完成具体任务，并记录入口是否找到、指标是否理解、异常是否定位、下一步是否明确。即便样本量不大，这类观察也能提前暴露流程断点；但它不能替代上线后的真实使用数据。
上线后先看目标用户是否到达入口，再看是否看到关键内容、是否完成定位、是否采取动作。若访问量不高，先判断入口是否融入工作流；若访问量高但任务完成率低，检查信息层级和口径；若异常查看很多、处理很少，检查责任分配、跳转边界和业务闭环。
不同团队可以选择不同的评估指标，但每个指标都必须能回答一个具体问题。不要用没有分母的“使用率”、没有任务定义的“效率提升”或未经验证的行业均值替代项目证据。数据的价值不在于数字显得漂亮，而在于它能指向下一项可执行的改进。
移动查看流程设计的核心，不是手机上有多少报表，也不是首页看起来多丰富，而是用户能否在合适的场景中取得可信数据、理解异常、找到责任边界，并进入下一步行动。若只能看到数字，却不能判断数字意味着什么，移动 BI 还没有完成任务。
下一步可以从一个高频且后果明确的场景开始，写出“谁触发、看什么、怎么判断、异常后做什么、怎样验证”的五句话，再把它画成流程图。先拿真实用户测试这条路径，确认入口、上下文、权限和失败恢复都成立，然后再决定是否扩展到更多角色、指标和通知场景。
我正在规划企业 BI 移动端，发现大家一讨论就开始画首页和图表，但我还不清楚用户从打开应用到处理完问题，中间应该经过哪些环节。我想要一套能落到流程图和评审清单里的方法，而不是只讲原则。
先按“谁在什么场景下，为了做什么决定”定义任务，再画页面。一个可评审的主流程通常是：进入入口，身份与权限校验，查看概览，识别异常，逐层定位，执行或转交动作，确认处理结果。每一步都要标注用户需要的信息、可能的分支和失败后的去向。
例如，区域负责人早会前查看销售异常，流程不应止于打开销售总览：他还要能看到异常区域、对应时间范围和可下钻维度，并知道如何联系负责人或进入业务处理环节。若流程图只画到“查看报表”，实际决策链路就还没有设计完。
方案阶段建议至少交付用户与场景清单、流程图、页面信息层级、权限规则、异常状态处理方式和验证指标。先评审这些，再进入页面细化，能减少页面做完后才发现入口不对、数据无权查看或异常无处处理的返工。
我在考虑把报表入口和异常通知放到同一个移动端首页，但担心用户收到提醒后还得重新搜索指标。我也不确定通知里应该放多少信息，才能既让人快速判断，又不泄露敏感数据或造成打扰。
两类场景可以共享指标和权限体系，但不宜强行设计成同一条入口路径。主动查看通常是用户带着问题进入工作台，适合从总览逐层筛选；预警查看则是系统带着用户进入异常，应该直接打开对应指标、对象和时间范围，避免让用户从首页重新找起。
一条实用的预警链路是：收到提醒，快速判断异常，查看相关趋势或维度，联系责任人或转交处理，回看结果。通知内容可优先说明指标、异常方向、发生时间和跳转入口；阈值、发送频率及敏感字段则应由业务规则、用户偏好和权限要求共同确定。评审时可以做一个简单检查：用户点开通知后，是否还要重复选择指标、组织和日期？
如果要，就应考虑把这些上下文带入目标页面。对于高频提醒，先小范围验证有效提醒比例和用户反馈，再调整规则，避免用增加通知数量来代替流程设计。
我担心手机屏幕有限，既想让管理者一打开就看到关键经营情况，又怕指标放少了不够用、放多了像把电脑报表缩小。我应该按图表类型、部门需求，还是决策优先级来取舍？
不要先定一个通用的指标数量。首页应优先回答用户当前任务中的少数关键问题，例如“整体是否正常”“哪里偏离目标”“是否需要进一步查看”；需要解释原因的指标和明细，放到下一层，而不是全部挤在首屏。可以为候选指标逐项写清楚：对应哪项决策、查看频率如何、异常时用户下一步做什么、数据是否可信且及时。
若某个指标既不改变判断，也没有后续动作，通常不适合占据首屏位置；若缺少它会让用户无法判断异常，则应保留或提供清晰的下钻入口。例如，经营负责人首页可以先呈现目标完成情况和需要关注的变化，再让用户按区域、产品或时间查看原因。
具体放几个卡片应通过任务测试验证：让目标用户在手机上完成真实问题，观察能否快速找到结论、是否误读，以及是否需要反复切换页面，而不是套用固定数量。
我不想把移动端上线和访问量上涨当成成功，因为用户可能只是点开通知，未必真的解决了问题。我想知道该建立哪些指标、怎样做上线前后的对比，才能分辨是流程变顺了，还是只增加了点击。
先把“有效”定义为用户更顺利地完成目标任务，而不只是打开页面。可按场景选择任务完成率、从入口到关键结论的步骤数、异常定位耗时、提醒点击后的有效查看比例、无权限或加载失败次数，以及用户反馈等指标；每项都要明确统计口径和数据来源。上线前先记录基线，并选取一两个高价值场景做任务测试。
例如，让用户从预警进入报表并找到异常区域，记录是否完成、在哪一步停顿、是否需要返回重选筛选条件。上线后用同一口径观察变化，同时检查数据更新时间、权限和网络等因素，避免把技术故障误判为交互问题。没有适用于所有企业的统一提升幅度或耗时标准。更稳妥的做法是先设定项目自己的目标，再按角色和场景拆分结果；
若点击增加但任务完成率、定位效率没有改善，就应检查提醒是否相关、入口是否准确，或后续处理环节是否断开。
读者评论
把移动端设计成从异常发现到处理反馈的任务链路，比单纯压缩报表更有参考价值。尤其是跳转后保留时间和组织筛选条件，能减少重复查找。
文中按角色和场景区分首屏内容很实用。同一套指标给管理者、门店负责人和运营人员查看，关注重点和后续动作确实可能不同。
指标口径、统计周期和更新时间需要在查看流程中说清楚，这点容易被页面设计忽略。否则用户看到数字，也未必能判断它是否适合用于决策。
弱网、权限变化和加载失败等情况也纳入流程评审，考虑得比较周全。文中的漏斗数据注明是情景模拟，避免了被误当成行业统计。