您的业务需要手机 App，还是 Web 应用？

先描述任务，再选择平台。

第一次寻找服务的客户，与每天多次查看任务的员工，使用需要并不相同。先写下各类用户要完成什么、需要哪些资料，以及操作之后会发生什么。

介绍业务并接收咨询，可能只需要公开网站；管理资料和处理流程，可能需要账号型 Web 应用；反复在手机上完成任务，尤其涉及设备操作与现场体验时，则值得考虑 App。

• 主要用户是新访客、回访客户，还是员工？
• 任务发生在办公室、门店，还是现场？
• 用户通过什么方式找到产品，并再次使用？

比较访问方式与设备要求。

浏览器产品可以通过链接进入。手机 App 则需要考虑安装或分发方式、相关账号和发布准备。这些步骤是否适合用户获取服务的习惯，也应纳入判断。

相机、定位、通知和离线使用，需要结合具体行为评估。部分需要可以在浏览器中支持，另一些可能更适合 App。先在目标设备上确认所需行为，避免仅凭功能名称决定平台。

• 列出主要任务真正需要的设备能力。
• 说明没有访问权限或暂时断网时，需要怎样处理。
• 把目标用户涉及的平台差异与测试纳入范围。

把使用界面与业务系统分开考虑。

不必要求所有人使用同一种产品。客户可以通过网站或 App 预约，员工通过办公工作台处理请求。不同界面可以共享服务，并按各自角色设置访问规则。

除了页面，也要规划数据与交接：资料在哪里创建、由谁修改、已有业务工具是否仍作为主要来源。这样可以避免不同界面各自保存一套难以对应的信息。

第一轮，先支持一条完整的使用路径。

首轮发布应让目标用户从开始到结束完成一项有用的任务。例如服务预约，需要考虑服务选择、请求提交与状态查看；办公端也要有可行的接收和处理方式。

明确哪些延伸功能可以稍后再做。手机 App、客户网站和完整管理系统，不一定要同时全新开发。已有工具能提供什么、哪些部分可以复用，都会影响第一阶段。

• 画出主要流程，也考虑错误与选项不可用的状态。
• 标出与其他人员或系统共享的资料。
• 明确首阶段边界，以及怎样查看和判断成果。

把不确定的部分放进规划。

开始讨论项目之前，不必先选好技术。简要介绍用户、主要任务、设备行为和已有系统，就是有用的起点。重要能力或集成条件尚不明确时，可以先安排针对性评估，再确定更大的开发范围。