在过程中不断提升

    培训结束了，最后的黑客马拉松也落下了帷幕，最终的超级产品大奖在掌声和颁奖词中宣布给了别的组，颁奖之前就告诉自己放平心态，享受过程，因为过程中的收获要远大于最终的喜悦与欢笑，不出所料，我们的产品成为了落选产品之一，没有获奖。当欢呼簇拥着把你要做的产品价值抬高后，或许你会陷入对产品的自我肯定与自我想象中去，以自己的需求和态度来定义产品，这应该也是作为产品人的大忌吧，作为产品人之一，我们要做的不是只将产品单纯的以流畅美的操作与画面呈现在用户面前，更主要的是要抓住主要用户的需求痛点，分析和抓住产品命题的本质需求。

  回想一开始确定的三天时间，虽然前期有明确的时间规划，但在执行过程中也会因为人力以及经验的不足而打乱节奏，最终造成时间的浪费，效率的不高，配合过程的拖沓。

     从整个产品的目标实现性来讲，在一开始产品经理通过鼓励每个人发言谈自己的看法来进行小组头脑风暴式的思维发散，并将需求痛点和产品可执行性以及产品最终所能带来的价值进行讨论，在这期间，有些想法被流产或是没有进行深入讨论，有点遗憾。包括扫描识别菜的产品想法。在这个讨论过程中大多是基于自身的生活经验提出的一些对扫描方面的需求，说白了更多的是面对自己这个用户，而对于自身之外别的人有没有这个需求，他们的需求本质是什么，他们在遇到同你类似问题时是如何解决的，可能我们也并没有很清楚，我想出现这样的情况可能一是源于自己认知的局限性，考虑问题基于自己的层面，对其他方面了解的不多也不深入。其二是容易把自己的想法强加给是所有用户的想法，这样在产品整个后期设计过程中容易陷入以一推十，推所有的窘境。

  在这个讨论过程中大多是基于自身的生活经验提出的一些对扫描方面的需求，说白了更多的是面对自己这个用户，而对于自身之外别的人有没有这个需求，他们的需求本质是什么，他们在遇到同你类似问题时是如何解决的，可能我们也并没有很清楚，我想出现这样的情况可能一是源于自己认知的局限性，考虑问题基于自己的层面，对其他方面了解的不多也不深入。其二是容易把自己的想法强加给是所有用户的想法，这样在产品整个后期设计过程中容易陷入以一推十，推所有的窘境。

     论产品框架结构的重要性，复盘这次的产品设计过程以及回想自己之前所做的一些产品，发现有时很容易陷入产品的局部问题中去，在追求完美解决局部问题的过程中往往容易忽视整个产品的信息架构及其关联性，导致在整体审视产品的过程中无法做到各功能的平衡与协调，当突然出现需求的变动时之前做的功能再好再完美的页面也只是废品，所以在对需求转化为页面功能设计的过程中应该提前做好框架结构、信息流程的规划，将产品在不同场景下的使用方式、遇到问题的解决方式考虑清楚、并记录下来，因为有时在交互设计的过程中，头脑是容易陷入特定的思维场景中，而忽视特殊情况下的问题解决方式。

      论线框图的重要性，在进行设计时为了省时省力，有时会在原型软件上直接将最终效果呈现出来。这次在进行设计时，通过前期在本子上画的几张低保真图，以及结合原型软件直接上手进行原型设计，由于时间的紧迫性，后期的设计过程直接进行了高保真的深入，在这个过程中可以发现，作为交互设计师，当给出的产品是高保真图时，对于最后的UI设计而言可能会限制对产品界面设计的想法。由于人力、时间的紧迫性，整个产品的第一版缺乏着重对于界面视觉进行严格要求的设计，更看重的是将产品页面的交互和功能输出的表达、需求问题的解决进行了主要呈现。

     论沟通及时的重要性，短短四天的时间，体验了一款产品从无到有的过程，重要的不是结果，而是这个过程中你懂得了什么、学会了什么，有哪些不足需要立即学习与改进。首先从前端说起，前端是设计的支撑者，好的设计、交互条件都需要通过前端来进行技术上的实现，在这次整个产品的设计中前端的工作量最大，也是我们整组最辛苦的。之前从来没有与前端进行过设计对接，从这次的经历了解到一个设计要想从原型图实现到真正的客户端，要懂得前端的一些基本需求，了解他们需要什么规格的图片、以及在设计中要把色彩、尺寸、字体等等标的清楚明白，这样才能更好地让前端了解你设计的东西，同时也从中能更好的减少沟通成本，提高工作效率。

      论用户画像、产品文档的重要性。回想起来，其实时间紧迫只能算是一切不成功的借口，短短的半个小时都足以将产品文档或用户画像呈现出来，产品需求文档及用户画像在这次整个产品设计的过程中我认为它们所起的作用就是防止需求随意变更、没有约束的发散需求、没有参照的增加功能，导致在产品的设计过程中迷失或模糊化主要需求，偏离最初目标，最后脱离想要解决的痛点。

     能用文字说明的，就不要用嘴说。文字语言是最明晰有力的，而嘴上说的往往有时会不经大脑、考虑不全。为了提高合作默契与工作效率，以及及时记录自己的交互想法，在使用原型软件设计时，我会进行及时的标注，同时共享链接，让开发者及时看到变更，这种方式如果采纳的好，可以提高开发效率。但是在进行交互文档的说明时要注重语言的简洁与可读性，冗长的文字叙述不便于开发者的阅读。