产品经理经常被称为是“业务、设计与技术之间的桥梁”。在交付高质量的产品时，这座“设计与技术”之间的桥梁尤其重要：它必须是无缺陷的，像素级完美的，并且考虑了所有可能的场景和极端情况。为了确保这座桥的正常运行，设计团队可以考虑从以下几种处理方式：
设计师提供一个全面的，可以展示产品所有流程的原型。不幸的是，这通常要花费很多时间，并且仍然会错过一些极端情况。
设计师只提供能展示功能主要流程的原型，同时随时接受开发团队的质疑。不幸的是，这些反复沟通的效率极低（尤其是在远程办公的环境下），并且会浪费设计和开发团队的大量时间。
除了全面的原型之外，设计师还撰写了合适的规范文档，里面列举了所有可能的场景和极端情况。问题在于，这往往是在浪费时间，因为（1）设计师的宝贵时间本来可以用来设计其他功能而不是浪费在写规范文档上面，以及（2）他们未必能像产品经理那样对产品拥有360°的视角，这会导致他们忽略掉一些场景和极端情况。
这就是为什么成熟的产品团队通常会把产品规格书的编写工作委托给产品经理的原因。
但是，产品规范应该如何编写呢？产品规范书我已经写了5年了，在这过程中国我发现有一种格式很受跟我合作的软件团队的欣赏。在本文中，我会把我的方法论和用于编写产品规范的工具等更多信息跟大家一起分享。此外，我还会讲讲自己正在使用的工具存在的一些局限性以及我的一些改进想法。
可靠的产品规范有5大支柱
以下是产品规范要处理的5个主要主题：
背景和目标
架构图
长篇故事与用户故事
验收标准
设计，内容和翻译
1.背景和目标
即使产品规范主要是写给软件团队的，他们仍然希望知道为什么要做自己正在做的东西。我现在已经知道，这是软件工程师工作的主要动力之一。他们当中大多数人都梦想着能开发出为数百万用户使用的功能。比方说，当他们听到自己实现的新UX把留存率率提高了15％时，会感到非常兴奋。因此，把有关将要实现的功能的背景交代清楚很重要：
我们在讨论什么？是产品的哪一部分？只要有助于理解现状，可以随时增加任何的功能历史方面的描述。
目前遇到的问题是什么？注意：可能遇到的问题不止一个。
是否有任何来自用户的定性反馈/原文记录可以引用？
有没有要展示的数据（比方说图表）？在这一章节里面，任何能让数据更易于理解的图表都可以添加进去。
选定的解决方案是什么？（用几句话简单描述一下）
是否考虑过其他解决方案？如果是，为什么搁置不用？
是否已经实现过了其他的解决方案？执行情况如何？
目标是什么有没有什么要影响到的KPI？这对于帮助软件团队了解他们是否有必要实现任何新的跟踪器/标签/事件来正确地收集数据特别有用。我就见过有的团队了解情况后，自己对项目无比兴奋，以至于会主动开发仪表盘来实时跟踪指标，根本不需要被别人开口。
2.架构图
在深入介绍功能细节之前，重要的是先对产品哪些要改以及哪些保持不变进行概述。哪怕你开发的是全新产品，架构图对于了解产品的结构仍然非常重要。
“架构图”就是我所谓的产品功能（流程、屏幕以及内容）及其相关系的高级图解表示。有人称之为“信息架构”，“流图”，“UX映射图”等。
架构图怎么画并没有官方方法论。针对移动应用，我一般会试着用不同的形状来表示不同的流程、屏幕以及“部分屏幕”（或者“页面内容”），如上图例所述。
运用颜色代码也很有帮助。在上面的示例当中，我用了3种颜色以及实线和虚线来解释怎么通过我们正在做的应用的UX改进来更新当前的信息体系结构。（绿色：保持不变，橙色：会被更新，红色：会被删除；实线：会留在原来位置，虚线：会移至其他位置）。这样以来，工程师就可以清楚地看到应用的哪个部分可能要变更。
做出易于理解的体系结构图还有一个技巧，那就是明确区分导航的各个部分，如下图所示，每部分都有单独的区域。
有一个架构图对于你的产品规范非常有用；这张图可以让你突出在每个用户故事里面讲的是产品的哪个部分。
那么应该用什么样的工具来绘制架构图呢？有很多可用的软件，不过我最喜欢的是Whimsical（因为它界面好看又简单，没有太多杂乱无章的功能），但我过去也曾经用过Draw.io，那个也很有趣，因为它跟Google Dribe是集成在一起的，如果你也在用Google Slide和Google Doc的话，用那个也不错。它还跟JIRA和Confluence集成在一起。
如果你想了解有关架构图的更多信息（该做什么不该做什么，可以使用哪些工具，有哪些例子等），Toptal有一篇非常棒的文章：The Comprehensive Guide To Information Architecture（信息架构全面智指南）。
3.长篇故事和用户故事
分解然后解释产品的所有部分很快就会变得乱作一团。在写了5年的产品规范之后，我发现，要想让规范保持条理并且易于理解，最好办法是根据“用户故事”将其分解。
什么是用户故事？按照Agile Modeling（敏捷建模）的说法，用户故事是“对需求的一个非常高级的定义，里面会包含有足够的信息，可以让开发者可以对实现需求的工作做出合理的估计。”
用户故事的想法是把用户放在第一位，并且在讨论功能时避免用晦涩难懂的技术词汇。就像Atlassian所说那样：“在看完了一个用户故事后，团队就可以知道他们为什么要开发自己正在开发的东西，以及它所创造的价值是什么。”
他们的目的是开发出更好的产品——要把用户放在争论的焦点，而不是像过去那样瀑布流式的产品开发模式。
以下是编写用户故事的方法：
作为<用户类型>，我想要<一些目标>，以便<一些原因>。
比方说，针对我为一位客户绘制的体系架构图的子部分，我是这样构思用户故事的：
用户故事1：作为个人档案上的一名员工，我想可以编辑个人资料，这样将来可以更新自己的照片、名字和姓氏。
用户故事2：作为个人档案上的一名员工，我想可以访问设置，从而可以更新密码以及更新通知首选项。
用户故事3：作为个人档案上的一名员工，我想能访问聊天室，以便向应用的开发者提供反馈
讲述用户故事需要详细到什么程度要由产品经理决定。如果愿意的话，其实用户故事2我们还可以讲得更深入一点，比方说：
但是正如你所看到的那样，在某种程度上来说这种做法很显而易见，并且是多余的。我个人会选择 “验收标准”（请参阅下一节）中介绍故事的这些场景。
为了组织好用户故事，我们经常使用“长篇故事（epics）”。用敏捷的术语来说，“长篇故事”就是可以分解为较小的用户故事的大量工作。我个人会用长篇故事对属于产品相同主题或者领域的用户故事进行分组。比方说，我选择将上面的故事归类为“个人资料”长篇故事的一部分。有些人选择与写用户故事相同的方式写长篇故事，但结构会简单些（比方说“作为一个用户，我想访问我的个人资料”）
4.验收标准
为了确保给用户故事添加足够的细节，我们要采用“验收标准”（有时也称为“满足条件”）。
根据LeadingAgile.com，“验收标准”是指“为了让用户、客户，或者在系统级功能的情况下的消费系统所接受，软件产品必须满足的条件。”
在验收标准中，你应该列出在用户故事里面并未明确阐明的所有功能特性。比如：
用户故事
作为个人资料部分的一名员工，我想编辑我的个人资料，以便可以更新自己的照片，名字和姓氏。
作为个人档案上的一名员工，我想可以编辑个人资料，这样将来可以更新自己的照片、名字和姓氏。
验收标准
假设（Given）我在编辑个人资料屏幕上，当（When）我单击“编辑名字”图标时，则（Then）应用应该切换到编辑模式，焦点要移到输入框并显示键盘（姓氏也一样相同）
假设（Given）我在编辑资料屏幕上，当（When）我单击“编辑照片”图标时，则（Then）应用应该要求我选择相机或者照片库
假设（Given）我正在编辑我的名字，当（When）我单击“保存”时，则（Then）它应该把我重定向到只读模式，并且我应该看到保存成功的通知
可以把验收标准看作是待交付产品需要完成的核对清单。上面采用的“假设（Given）/当（When）/则（Then）”的模式是制订验收标准的好办法，但是在某些情况下这种用法可能会遇到困难。
5.设计，内容和翻译
让你的产品规范拥有最新设计
到目前为止，我还没有提到我正用哪个工具来编写规范。过去，我会在Google Docs、Google Slide以及Notion之间换着用。Notion我真的非常喜欢，因为它提供的所有那些很酷的集成（尤其是跟InVision 和Figma的集成）。但是，现在我已经完全转向了Google Docs：在确定产品规范的格式方面，我更愿意拥有更多的自由。而且在跟外部合作伙伴或客户合作时，用Google产品也会更加方便。
为了确保开发团队能够准确地还原你所设计产品的视觉形象，重要的是要让他们能够使用设计师提供的最新屏幕。但是由于Google Docs跟Figma、InVision 或Zeplin之类的设计工具之间并没有真正的集成，所以我习惯把屏幕导出，然后复制/粘贴到我的产品规范里面。
这很快就会变成问题：设计师设计的屏幕每天都要迭代，哪怕屏幕的所有内容大家都已达成共识，但由于设计库更新了某一个特定的组件，几周后屏幕可能又会变了。这会导致我的规范大多数时候都是过时的。
这就是现在我只使用屏幕名称的原因。比方说，如果关于个人资料编辑的某个用户故事由Figma 设计的2个屏幕组成，那么我会只写“Figma screen name：edit-profile-1和edit-profile-2”。
当然，这不是理想的选择，这会限制开发人员或其他阅读我的规范的人不断地在多个工具之间切换。
但是，这也说明了今天我们编写产品规范的方式效率有点低下。多种产品的使用产生了集成和同步的问题。如何确保开发产品所需的所有信息都可以在一个地方看到而不会过时？（实际上，这不仅适用于设计，也适用于体系结构图和内容）。
→ 如果你也遇到过这个问题，并且已经找到了解决办法，我会很有兴趣得到你的反馈！
要让人能够轻松访问内容和翻译，避免输入错误
在设计包含有大量内容的屏幕时，最好让开发人员有机会能够轻松地复制/粘贴屏幕，而不必自己重新键入。否则，你可能最终会遇到（1）许多错别字和（2）开发人员很生气。你可以通过以下几种方法让他们能访问内容：
如果你的产品要支持多种语言，那还得让他们可以访问每一种翻译。比方说，你可以用数组显示原始内容每种语言的翻译。升级版的翻译管理是使用本地化工具（比方说Phrase），并且在产品规范里面只加上“翻译键”。但是同样地，这意味着你又得知产品规范与另一种工具之间前后往复。
总结一下，以下是我认为撰写全面产品规范所必要的信息：（1）背景与目标，（2）架构图，（3）长篇故事与用户故事，（4）验收标准，（5）设计、内容与翻译
如你所见，写规范最棘手的事情之一是在你的参考文档（我建议你用Google Docs、Notion、Confluence等推荐协作工具写的东西）与其他更具体的信息结构和设计工具之间来回反复。这个问题可以用不同的方式解决：
在现有工具之间进行更好的集成。我们目前看到的最好的解决方案是Notion能够把整个Figma项目集成到Notion文档里面。但是只是把某个特定的Figma屏幕集成到规范（不管是用Google Docs、Confluence还是其他协作工具写的都行）里面也不错。
开发插件，赋予设计工具超级能力。比方说，Figma正在增加大量插件来增强设计体验。我们可以构思一个插件，使得直接在Figma里面创建规范变得很简单。
从头开发一个“产品规范”工具，这个工具将会解决跟信息架构、设计与翻译工具的集成问题。但是我对这种工具的普遍适用性表示怀疑，因为每一支产品团队的流程和工具会各不相同。
德仔网尊重行业规范，每篇文章都注明有明确的作者和来源；德仔网的原创文章，请转载时务必注明文章作者和来源:德仔网；