抖音号资讯：是对上一步的抽象化的方案进行实例化，实例化

先是顶部的搜索区，然后是中间的表格区，最后是表格内容的区域，再加上一些特殊的信息或者备注。如果是其他产品，例如桌面客户端，Android，iOS等可能展示的形式会不一样，可以自行酌情区分。

到此，产品结构基本上就梳理清楚了，当你拿这些信息去和开发、测试、业务等沟通的时候，他们基本上知道了你要做的东西是怎么样，对于合作顺畅的团队也许就可以直接动手开发了。

当然其中还有一些细节是需要补充的，补充的方式可以是丰富导图，也可以是写相关的文档，亦或者是画精细点的原型图。

产品结构图的构建完成也意味着基本上此需求的抽象结构已经处理完了，而怎么填充血肉，怎么完成最后的临门一脚，就要看原型图和文档写的怎么样了。

实操四：原型图与文档

毫不客气地说，我的原型图画得很烂！Axure一些高级用法，我一个都不会，墨刀也就用过几个月，其他工具都没怎么玩过。

但是我对自己的表达能力并不怀疑，我相信如果原型我表达的不够清楚，我可以借助其他的方式来解决。例如：当面沟通，TAPD沟通，文档沟通，截图沟通等。

沟通其实是双向的，你画的天花乱坠，但是对方看不懂也没用，你画的寥寥几笔，对方就能get你的意思，其实也是一个优秀的原型。所以，原型的好与坏是以开发、测试能不能看懂，协作是否高效来判定的，至于颜值嘛，好看固然加分，不好看也能将就。

画原型这一块我也没有什么金玉良言，从自身踩过的坑来说，我一般会有这么几个观点：

1. 画原型之前一定要有导图，就是前面的产品结构图，如果没有这个原型很容易反复修改；
2. 多用母版或者多用母版思维，这个和开发里面提到的「可复用」、「组件化」是一个意思，能极大地提升效率；
3. 写的多不如说的多，原型上写的多固然好，但是开发不一定看，看了也不一定会转弯去思考，所以在实际项目管理的过程中，多线下反复沟通，让他们做的东西和你想要的东西保持一致；
4. 多定义一些规范和标准，尤其是团队没有UI或者开发众多的时候，定一些规则出来大家都遵守，以后不容易出现相应的返工情况；
5. 尊重大家的意见，多PO出自己，让大家给自己提意见，UI方面的意见，产品文档的意见，原型绘制方面的意见，忠言逆耳，怕的是别人不提意见而你却自以为很棒，活在大家的捧杀中！

最后原型图就不丢出来，这个相信大家都会画，也画的比我好。原型设计其实就是对上一步的抽象化的方案进行实例化，实例化的方法有很多，但是要让大家看得懂即可。

最后

长篇大论的还要插图解释真的是太累了，但是写了这么多也蛮有收获的。一方面是写得越多，越发现自己的文笔太差，废话挺多，干货写不出多少；另一方面是，自己产品这一块的交流太少了，平时只会一味地输出，但是却很少有机会和别人沟通交流，了解自己的短处在哪，缺点在哪。

至此，方法论和实操演示就讲完了，感觉说了很多，但是仔细一看也没啥东西。那我就过段时间再优化迭代一下，争取写得更好一点。