6.6.2 X公司的需求
了解了这些背景情况之后，你就可以着手准备实际的设计工作了。首先，你要根据客户的实际需求来定义产品的核心功能。经过了与X公司相关决策者的访谈交流，并对其桌面应用做了进一步的了解之后，你认识到，他们的iPhone应用需要满足以下几个方面的需求：
- 帮助用户访问内容库当中的全部信息。
- 为用户提供一种机制，帮助他们快速高效地发现新内容。
- 用户可以将内容分享给朋友。
- 用户可以对内容发表评论。
- 用户可以发布他们在iPhone上创作或拍摄到的内容，并通过内容库分享给全部用户。
这些需求目标已经得到了X公司相关团队及决策人员的确认。虽然其桌面应用的很多功能并没有体现在这个列表中，但是根据移动应用上下文环境中的用户实际需求来看，目前的这些功能已经足够了。
明确了产品需求，我们就可以对工作流的组织方式进行构思了。在这方面，最好多花些时间和心思，从细节层面对工作流进行深入地挖掘与定义，这样做可以使接下来所创建的交互模型能够最大程度地发挥出自身的潜力和价值。
这份需求列表可以帮我们看出这款应用的本质。其中，绝大部分需求与内容有着直接的关联，而类似分享和评论这样的辅助功能也是依托于内容的基础之上的。所以我们可以得出结论，内容是这款应用在功能与用户体验等方面的核心。当你与客户进行沟通交流的时候，还会对一些将要在后续工作当中面对的关键问题有所预见。例如，我们可以了解到，对于这款以内容检索和浏览为核心的应用来说，用户所做出的交互行为多数是为了获取内容而在层级化的信息结构中进行的导航操作。
要将这一点体现在工作流文档中，有两种方式供我们选择。一是在文档中准确地反映出涉及内容浏览和导航的层级结构；另外还可以将这方面的工作流简化成为文档中的一个节点。让我们通过一张流程图来看看这两种方式之间的区别(见图 6-13)：
图 6-13流程图被简化前后的信息结构对比
这给我们带来了一个值得思考的问题：究竟是否有必要将工作流完整无缺地体现在文档中？ 这个问题的答案还要视具体情况而定。对于那些会对用户界面设计方案产生直接影响的交互流程 ，你需要在文档中将它们尽可能完整而详细地体现出来。而对于那些有可能在用户界面设计过程中得到一定程度简化的交互流程，不妨直接在工作流文档中将它们打包成为一个节点，避免工作流的组织方式被复杂化。
在当前的案例中，我们需要为用户提供一种机制，帮助他们在移动应用的上下文环境中快速高效地发现并浏览内容。可以预见的是，为了实现这个需求，我们必须在将来的某个设计环节当中将桌面版应用原有的信息结构进行最大程度地简化，例如可以在构建交互模型时，将内容的导航与浏览整合到同一个交互过程当中。在这种情况下，我们完全可以选择简化版的流程图来指导我们接下来的工作(见图 6-14)。
图 6-14 做出了信息结构会被简化的预见之后，采用简化版本的流程图
随着核心需求的基本工作流被逐步确定，我们也能越发清晰地看到，这个案例带给我们的一个很大的挑战，就是能否找到一种与移动应用上下文环境的关联更加紧密的方式，来帮助用户获取内容。接下来，我们将带着这个问题进入到交互模型的构建阶段。