本文从产品角度出发，深入探讨了如何发起交互设计。通过明确产品目标与用户需求、进行用户研究、构建信息架构、设计流程与界面、进行原型测试以及持续优化等关键步骤，阐述了如何打造出满足用户期望、提升用户体验并实现产品目标的交互设计。
在当今数字化的时代，产品的成功不仅仅取决于其功能的强大，更在于能否为用户提供流畅、愉悦且富有价值的交互体验。从产品角度发起交互设计，意味着将用户置于核心，以实现产品的商业目标和用户需求的完美融合。
产品目标是交互设计的起点，它决定了设计的方向和重点。产品经理需要与团队共同明确产品的定位、市场需求以及预期的商业成果。例如，是旨在提高用户活跃度，还是增加用户转化率，或者是提升品牌形象。
通过市场调研、用户反馈、竞品分析等手段，深入了解目标用户的行为习惯、痛点和期望。这不仅包括对用户显性需求的捕捉，还包括对潜在需求的挖掘。
基于收集到的数据，构建详细的用户画像，包括用户的年龄、性别、职业、教育背景、使用场景等特征，以便更精准地理解用户的行为和需求。
模拟用户在不同场景下与产品的交互过程，发现可能存在的问题和优化点。
我们要知道，地铁周边美食，这是一个解决方案。真正的需求是什么？一个字一个字地找需求，地铁=快速方便出行，美食=和朋友一起吃饭/自己一人吃饭。这是一个和线下场景很相关的项目，我们要把不同目的核心用户的主要使用场景写出来。经过分析，我们得出了用户会选择我们产品，且产品未来可能存在的各种场景A、B、C、D、E。如下图所示：
如果按照目标人群所在场景分类，进行细分，则为下图：
乘地铁去地铁站和附近地铁站区别：前为用户会乘坐地铁去目的地寻找美食；后为用户不用地铁/吃完后使用地铁，地铁边美食没有其他美食团购产品有竞争力。
上班族和普通大众区别：上班族工作日使用固定地铁站上下班，时间可能紧急，快速获取食物；普通找美食吃的大众不使用固定地铁站，目的是通过地铁快速到达某目的地，就近享受目的地美食。
朋友们和个人区别：朋友们一起吃饭，容易出现喝多、吃过点等异常行为，并且在选择地铁旁吃饭地点时需要考虑朋友们家的位置就近选目的地。个人均不需要考虑以上，较为自由。
经过领域场景的分析，我们知道了真场景都是用户有目的乘坐地铁去到某地铁站出站口寻找美食的。那么我们对这么一群大众进行用户人口统计学类的细分：
-
上图为前期定位的目标大众用户群，依靠地铁的工具属性，我们得出了具体的两个影响因素：时间+美食热爱程度。同时我们把直接竞品和间接竞品一同进行用户群比较。可以看到和大美团有相同和不同维度，这就是产品最初冷启动时期的差异化！也就是我们的前、中期场景的主要目标用户类型。
-
红色部分即种子用户群，以这些群体为冷启动阶段，可以更快的向四周扩张。因为他们有使用地铁的时间属性，同时有较高的美食热爱程度，有利于带动其他时间+热爱程度的用户加入产品，实现快速并有质量的拉新、活跃的目标。
-
低端直接竞品即用户群工具属性明显，只是搜地铁站，选择美食的用户，无明显其他行为；高端竞品即注重社交、ugc为起点，逼格高的搜寻美食工具。这部分开始很难，工作量巨大，且较脱离大众主流群体。
结合上图和要做的场景，我们得出了产品具体目标用户：乘坐地铁快速到达并寻找目的地美食的大众用户（上班族休息日，大学生，个人或一起），要求在地铁站附近便能方便享受目的地美食。且对美食有一定热爱程度。
邀请真实用户进行产品试用，观察他们的操作行为，收集反馈意见，为后续的设计提供依据。
需求很有可能是在线上接到的，并不是面对面交流传递的，并且还会遇到很多坑，例如需求本身不具体，或者自己理解有偏差，因此在接到需求后，最好和交互、产品等同事进行面对面的交流和沟通。
详细了解测试目的和关键点，确定用户配比。
最好是让交互带着跑一下整个程序（半成品demo也好，交互稿也行），这样能在头脑中快速形成操作流程的认知，并把相应关键点对应上去。同时把大致的用户配比情况敲定一下，后续就可以直接招募用户了。
了解demo的完成进度，相应确定具体测试时间。
交互、视觉等完成demo的时间具有太多不确定因素，因此我们需要及时了解整个demo的完成进度，在尽可能快的情况下保险安排测试时间，如果邀请的是外部用户，结果用户到了而demo还没出来，那也是够了。
让交互稿帮助自己
。在完成测试方案撰写的过程中demo还未诞生，具体程序细节记忆又很模糊，不好写测试方案，怎么办？不要慌，去看交互稿吧。
及时沟通
。在方案撰写过程中，如果有一些疑问，例如在看交互稿的时候还不是很理解某个具体操作过程，或者自己对产品有疑问的也可以跟交互等沟通，因为自己会遇到的问题，很有可能在测试用用户也会遇到，这样子用户如果问到了，就可以相应作出解释。
核实确定方案
。完成方案后，可以在公司沟通交流工具上和交互及产品等同事再确认一下，是否有什么地方遗漏或有不妥之处。
这是一个大多数人都头疼的一个过程，希望看完了以下几点，可以稍微缓解一下大家的症状。
方案定下来后，再跟交互确认测试时间，了解是否有变动和调整，尽量避免用户来了demo或者测试环境还不ok的情况。
需要把用户要求、测试日期和地点、报酬、大致的测试时长、用户需要在测试中做什么，以及报名方式等表达清楚。有以下几点可以注意一下，方便我们自己招募：
-
详细列出测试安排的时间段
。例如10:30-11:15、13:30-14:15，让用户自己挑选合适的时间段，这样就不用事后再协调不同用户测试时间了；
-
优先人力、信息管理、行政等岗位同事
。尽量避免相关产品人员、设计岗等同事。
-
制作简单的招募海报，并检查。
可以事先将“海报”用word或者ppt做好，然后保存成图片格式，记得检查核实一下是否有错。因为在公司IM群上直接黏贴确实方便，但是其排版往往不利于阅读，导致用户会遗漏重要信息。而制作成图片格式，可以更好地去避免这个问题，同时还可以显得整个招募过程比较正式，突出了对用户的尊重，也能在一定程度上体现我们用研工作的规范性。
内部用户可以尝试先在公司IM群组上招募，之前招募样本量比较小，因此很快可以招到，其他途径暂时未尝试，公司论坛应该也可以，不过隐约感觉效率会比较低。外部用户可以在朋友圈试试，效果还不错，大家都很热情帮忙转发，群众的力量大无穷。也可以相应去搜索一些QQ群，加入并发布招募信息。另外还有一些社交论坛什么的，都可以尝试一下。方法很多，针对具体招募情况，大家就尽情发挥吧~
海报发出去后，有时也会出乎意料用户数量超过预期了，这是好事，不要担心，也不要急着拒绝，平和的跟对方说明情况，强调下次还会有测试，把用户相应信息了解一下做个记录，下次招募的时候可以直接先联系这几名用户。当然前提是你真的有下次测试需求，如果没有那还是老老实实说明情况。
确保自己和用户能彼此联系上
。
跟用户强调测试时间和地点，尤其是外部用户，如果招募和正式测试隔了几天，最好在测试前一天再通知一下。给出自己的联系电话，同时询问用户的联系电话。
很多时候demo的完成情况会出现意外，到了测试时间demo还不能用，内部用户可以方便取消或者更换。另外，在第一次测试前谁都不确定用户会有什么反应，第一个测试是可以起到试水效果，而外部用户成本高，用来试水太奢侈。
需要准备的内容有：量表、报酬签收表、记录笔记本、录音笔、会议室借用，以及记录表格，如果是外部用户过来，相应准备一杯水，人家大老远过来也不容易。
其实每次访谈用户自己都会挺紧张的，不知道用户是不是也很紧张（PS：好想当一回用户，体验一下被访的感觉）。为了消除这种紧张，同时也是为了更好的完成访谈，可以有尝试以下几点：
-
尽可能多的去了解所需测试的产品
。有时候demo出来的晚，下午要测试，demo中午才出来，自己都没玩过，测试还怎么搞？之前也说了，那就使劲去看交互稿吧，虽然比不上实际操作来的真实，但是也能有不小帮助，但也要给自己留足熟悉demo的时间。
-
按照模块来列提纲
。其实相当于组块策略，把同一个模块的问题放到一起更方便记忆，并且也在访谈中也方便自己和其他同事发现遗漏点。但模块不要太大，如果太大了就相应拆分一下。例如，在考拉新版测试的时候，有“首页”、“活动”、“购物车”等测试，但是光是首页内容也很多，作为一个模块还是太大了，可以拆分成“首页整体感知”、“商品详情”等几个方面来整理提纲。
-
根据任务演练提纲
。有了提纲后，按照任务大致过一下所有列出来的问题，这个过程会打乱按照模块列好的提纲，有一次这样的排练，在测试的时候更不容易漏掉题目，而且也相当于模拟了一下测试，自己心里会更踏实一点，在实际测试过程中也能有更好的应对。
通知交互和产品的同事具体测试时间和地点，邀请他们一起参与。不建议交互和产品只是后期测试查阅报告，如果他们参与到测试中，能更近距离和用户接触，并能更加深刻感受到产品存在的问题，也能更好的推动产品的改进。
-
划分我们和产品的关系。在测试之前跟用户说明清楚，我们并不是产品的设计者和开发者，我们只是受产品方委托来进行测试，以免用户不好意思当面如实评价产品。
-
强调测试的是产品，而不是用户。要跟用户说明产品尚处于不完善阶段，因此邀请用户过来进行测试，帮助发现问题和改进产品设计，但请注意不是为了评价产品。
-
-
尽可能深入的去挖掘用户的需求。不要停留在用户话述表面，更进一步去追问，用户为什么会这么说或这么问，例如，很多时候在测试中会碰到用户说“哦，原来这个按钮是xx功能，我还以为是xx功能“，这个时候可以再推进一步，了解用户为什么会这么认为。
-
给其他在场的同时发言的机会。主持人如果觉得自己访谈的差不多了，可以询问一下记录者以及交互、产品等同事，了解他们是否还有问题需要补充。
-
记得量表评分和报酬签收。长时间的测试和访谈后容易忘记量表评分和报酬签收，可以把这两份东西放在显眼的地方，另外可以让记录的同事打个招呼，帮忙提醒自己。
-
仔细观察用户行为并记录。记录不仅仅是用户的观点、想法等，更重要的是记录用户的实际行为。
-
按照模块记录。记录者可以按照测试方案中的模块来相应记录用户的行为和言语表述。
-
查漏补缺。主持人可能会遗漏一些点，记录者作为旁观者需要提醒主持人遗漏了什么，或者自己有什么新的内容需要补充。
欢送用户。对用户表示感谢，并开门送一下用户，对于外部用户，最好能送到大楼外面可以看见出口的地方。
测试后及时讨论。这个是重点！
在每一名用户测试后及时和交互、产品等同事快速过一下主要发现的问题点，这样做有以下优点：
-
有效达成共识，确定解决方案。刚访谈结束印象最深刻，因此能快速有效达成对主要问题的共识，并讨论确定相应的解决方案。
-
体现敏捷优势。确定了一些比较严重的问题后，交互和产品的同事就可以相应去改进产品设计，做到了边测边改，加快迭代速度。
-
帮助优化访谈提纲，和测试用户安排。有些问题在事先撰写方案的时候可能没涉及到，在讨论后可以补充进去，而有些问题确定后则不需要再测。另外，也可以通过讨论对事先安排的测试用户进行相应调整，例如增删用户，或者调整新老用户测试顺序等。
-
事后帮助我们自己快速撰写方案。通过讨论确定了关键问题，并且，交互和产品的同事也相应清楚了，因此在最后可以快速形成报告。
再次感谢用户。所有用户测试结束后，可以花几分钟时间简单感谢一下用户。
针对不同大小项目的用户测试，在完成报告撰写过程中有两种具体方式：
-
小测试项目简单快速撰写报告。对于那些1-2天的小测试项目，由于在每次测试后都有讨论，已对主要问题达成共识，因此在报告撰写的时候就可以快速地将主要的问题和风险点呈现出来。
-
大测试项目每天总结并反馈主要问题。大的测试项目持续时间比较久，针对每天的测试及讨论，简单总结一下主要发现的问题，并反馈给相关人员，如果到了最后再总结，容易遗忘掉一些内容，并且这样子也方便自己最后撰写报告。
思考信息架构有三个核心关键词：用户角色、产品价值、使用场景。
用户角色清晰揭示用户目标，帮助我们把握关键需求、关键任务、关键流程，看到产品哪些是主要的事，哪些是次要的事。我们应该尽可能丰富、形象化我们的用户角色，让它在设计决策过程中发挥作用，设计出更符合用户场景的产品。
作为产品的设计师一定要理解产品的价值，知道用户想要什么，把最重要的优先级提到最高，尽量移除无关紧要的信息，或降低其他优先级的权重，以免对用户造成干扰。
要了解产品的业务流程，比如目标用户是谁、什么场景、如何使用，要把产品业务流程上的节点一个一个梳理出来，还要考虑这个产品对用户的价值是什么，不要仅仅考虑界面的元素规范、设计细节等等，要知道产品的目标价值体系。
基于三个核心点（用户角色、产品价值、使用场景）分析，把目标用户人群核心价值的功能点业务流程梳理出来，分清主次关系，切忌功能堆砌，具体方法可以把所有功能业务逻辑的主线列出来，然后根据业务的优先级做评级，分清楚这些功能哪些是主要的，哪些是次要的，然后通过数字做排序，这样我们就知道哪些功能设计需要明显，哪些功能设计需要低调。
从整体上思考信息类产品的分类及整合，比如用户资料相关的产品会有用户信息、资料、等逻辑，这样就要把所有跟用户相关的信息都归在同一个分类菜单下，不要让他们分散在各个页面中。也就是所谓的一级菜单、二级产品的处理逻辑。
随着产品规模与复杂度的提升，要随时关注信息架构是否满足当前的产品框架，不要等需要时候再去孤注一掷的全盘优化，这样会让项目陷入被动的局面，可以逐渐增强，循序渐进的优化，从小的细节对信息架构进行调整，提升产品的易用性。
使用快速原型工具制作可交互的原型，以便更直观地展示设计方案。
团队内部进行初步测试，检查功能的完整性和流程的合理性。
邀请外部用户进行测试，收集他们的意见和建议，发现潜在的问题和改进空间。
通过收集和分析用户的使用数据，了解用户的行为路径和偏好，为优化提供数据支持。
及时响应用户的反馈，将有价值的建议融入到后续的优化工作中。
根据数据分析和用户反馈，不断对交互设计进行迭代更新，以适应市场和用户需求的变化。
从产品角度发起交互设计是一个综合性的过程，需要充分考虑产品目标、用户需求、信息架构、流程界面、测试优化等多个方面。只有以用户为中心，不断追求卓越的用户体验，才能打造出具有竞争力的产品，在激烈的市场竞争中脱颖而出。
在未来的产品开发中，随着技术的不断进步和用户需求的不断变化，交互设计也将面临新的挑战和机遇。产品团队应保持敏锐的洞察力和创新精神，持续探索和优化交互设计，为用户创造更多的价值。
作者：Charlotte的嘻酱
链接：https://www.zcool.com.cn/article/ZMTYyNzM1Mg==.html
来源：站酷
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
