爱华网新接触这个产品，作为专门的交互设计。和研发部门的产品经理合作。他们控制需求，我们负责易用性方面设计。开发团队负责制作。
一、 设计交互规范
这头几天，我一直在熟悉这个产品，但是我始终没分清“弈衡”“弈择”“锐图”这几个产品是干什么的，从我这个非专业角度来看，都是对某一类人进行网络心理测评。
还需要对一个叫BSP的平台进行易用性分析。貌似是管理员后台。维护各企业的帐户信息，权限等等。难道这公司就非得把产品名字起的这么晦涩么？由于对产品不了解，我只能对产品很浅的交互设计问题提些建议。其实整个系统是如何运做，需要在这个系统上完成哪些任务，如何完成我还都不太清楚。
由于各部门同事成立。产品经理还在业务需求初步调研期。我们有点空闲。领导要求写份交互规范，目标：一致性最重要。
根据以前的项目经验，我认为连需求还不了解，不知道会用什么控件。交互规范的制订还为时尚早。于是从其他地方拽过来一套现成的。略加改动。
交互规范包含：
- 用户体验交互设计规范——基本原则
- 通用交互的规范
链接，按钮，文字，表格的典型交互状态，规则描述 - 基本控件交互规范
文本输入框，按钮，复选框，单选按牛，下拉列表，列表框，分组框 - 扩展控件交互规范
翻页控件，气球状提示，表单提示，工具提示， - 信息提示规范
错误信息，警告信息，确认信息，提示，树形视图，选项卡，滑块，进度条，联想搜索，折叠层控件 - 导航规范
引导，菜单 - 页面典型视图规范
列表，表单，文档 - 窗口规范
弹出窗口引用，布局，样式 - 文本规范
语气及文字定义
这样一份长长的文档，在我还不知道要做一个什么东西的时候来确定，并且要Share给个部门，我怀疑是否有意 义。而且前期，在这上面花很多心思没价值啊。
我倒想，这个作为提纲，每次讨论完细节后，把结论记进来，还是个不错的方法。
我们还确定了产品的框架布局，并且经过几次争论顺利通过评审（我得说，这是由于我们的经验不足，在这个阶段评审这个基本上会被颠覆）。
二、 了解需求
公司安排了两周的培训，从测评原理，到系统功能。我终于知道我们的产品具体要做哪些事情了，不过我还是分不清那几个产品的名字。对此，我在会上提了我的意见。虽然领导当时没点头（毕竟是他们创业之初好不容易确定的啊）不过后来我发现在新产品的开发中，这种代号消失了。
了解产品需求，就需要做用户访谈，不过这样可能会骚扰客户。所以我们抓了几个内部HR，资深销售，和长期接触HR的培训师做放谈，并记录了他们常用软件的使用轨迹进行分析。
放谈前列了提纲：
- HR访谈问题：
HR日常工作职责有哪些？那些是重要的？那些是要费大量时间的？
HR日常工作职责有哪些？那些是重要的？那些是要费大量时间的？
工作中使用的HR辅助系统有哪些？使用情况是？业界其他HR会使用那些？
工作中使用的软件有哪些？用途和使用情况是？
招聘、选拔人才的难点是什么？
那些职业类别的人才更难以把握？
如果有可能，是否需要工具来辅助目前的工作?是那些? - 销售访谈问题：
以往发布的都是怎样一些产品？解决了用户哪些需要？那些需要没能解决？
以往的客户中不同规模企业的比例是多少？
不同企业对测评产品的需求差异是那些？我们满足了那些？不能满足的是？
企业中购买我们产品的决策者在企业中一般是什么角色？
吸引这些决策者购买产品的有哪些因素？
老客户续签率有多少？没有继续使用我们服务的客户一般有哪些因素？
目前企业中使用我们产品的人员在HR中是什么角色？
用户通常在工作中的什么环节使用系统？前后关联的工作还会有哪些？用户工作中还会使用那些软件？信息系统？
你认为什么样的产品或改进能够带动业绩增长？ - 访谈客服，主要是看客服记录
- 分析数据库，比如一些自定义功能，用户都是如何使用的
三、 设计原型
接下来被安排做一个很匪夷所思的任务，设计整个平台的“系统设置”模块。天！我都不知道平台上需要哪些服务，怎么设计“系统设置”的原型呢？经过争论，变更了我的任务，对以前开发过的系统设置进行优化设计。领导说，先搭个架子，以后优化。
研发计划是开发一个平台，平台上将承载和整合几个业务模块。 第一个业务模块的概要需求出来了，我开始加入焦点小组进行讨论。
产品经理们凭空讨论有点别扭。于是我开始画原型以供讨论（这是一个让我后悔不已的决定）。于是焦点小组的讨论点转移了，本来应该讨论用户是否需要一个导入功能，以及这个功能的开发优先级如何。现在变成了：导入功能这样实现是否合理。资源管理的菜单应该放在哪里。等等。于是我被牵着不停的改原型。经过无数次的小组讨论，原型终于初步确认。上会评审！！
在我设计的同时，前端的同志开始做控件开发，和几个典型高保真原型。但八十个人的研发团队，我们只有两个前端工程师的配置，要前端又开发控件，又开发高保真原型，工作量可是相当大的。我们可是3个交互设计师同时出产品。把所有高保真原型都做出来，实在是个太不靠谱的梦想了。（前端页面发给开发工程师后，还要配合套页面，调BUG）
四、评审原型
老板和开发经理提了几个问题，诸如：“在这个场景下用户不使用这个功能是否可以顺利完成任务”“实现这个功能在8月前上线可能么？”我得说，我们确实在这方面的的讨论不充分。OK，重新更改。但是同志们看到原型还是不知不觉的讨论实现细节。
由于开发时间点的限制，原型被迫评审过了。
但比如说，页面框架结构不适用（由于框架已经评审过了，所以不能改） 列表控件有些功能无法实现这样的问题已经无法改了。导致设计上有点尴尬，只是控件元素的堆砌。
开发的周期安排的很紧，原型才评完，开发就开始了（这倒是很正常）。但问题是我们没有来得及安排太多的用户测试。
产品的原型都通过了，系统设置这个支撑模块的设计很多都要改了。建议以后这个可以放在后面点再做。
五、 可用性测试
没有高保真原型了，没有。技术用 低保真原型来开发，没有美术设计了，没有。前端直接照原型出典型的页面。开发已经开始了，然后再套页面。（前端人数确实是不够完成这样的工作量的 ）
我用低保真原型测了5个用户，包括5种使用我们产品的典型用户，有新的，有老的。并收集了反馈意见。发现了很多设计小组想不到的问题。但是改不改呢？设计过程中，焦点小组的讨论结果令我忙的团团转。而且没有流程完整的原型测试的效度就很低。没有时间安排高保真原型的制作和测试。有些研发部门坚持的就改了，在技术开发完成之后。当然，这 少不了抱怨。很多很多的抱怨。研发人员偶尔也会主动调整需求，跟着是交互原型的变化。这是个大团队，协调显然是不那么容易的。每个人都在 抱怨变更，我也不满意设计出来的结果。
前期没有可用性测试也许看起来是节省了时间，但是从整个产品的开发效益来说，我认为这是个很有风险的事情。
六、 设计回顾，优化
原型公开发布后，陆续收到 销售，内部HR，研发人员，设计人员，测试人员的反馈意见。
比如搜索结果没有标红，用户根本无法得知自己的搜索状态。
比如某些功能实际上完全没有必要，但由于旧产品有，所以虽然上会N次，仍然不肯去掉。
比如菜单呈现方式，坚决要求按逻辑排列，导致整个菜单本来一共6项，结果差点被分成3个层级。由于分层太多，还有些鸡肋功能，导致界面很复杂。产品经理很不满意，反复更改。但是导致复杂的根本原因却不能动。
老板说安排了两个月的优化时间，满怀期望。准备了一堆改进意见列表，结果开发改进时间超过24H/人的，就都被cancel。
很重要的列表问题，搜索结果问题都不能改
有些调整问题倒是通过审批了，不过3次上会审批了，每次都确定了改的责任人，却没有被领导安排在开发人员的月度计划里。结果每个月都被要求重写一次改进建议也没实施。（因为不同阶段要改的点不一样。需求和设计都被变动了）
随着产品的开发完成，一级菜单变成12个（产品只有六个，支撑模块却增加了3个，甚至业务部门要求增加待售广告链接）。在1024分辨率下，几乎就是一串文字。但是要改动菜单结构真是件大事情。需求方又拽着我们订好的旧规则，产品必须列在上面。
突然要换平台STYLE。原因是视觉设计不够“令人眼前一亮” 。重头开始美术设计，重头开始套皮肤。工作量刚好2个月左右。
个人认为一个新产品第一阶段的重点是核心功能。连最基本的功能还没完成，就象一个人才生下来，胳膊腿还没出来，就开始频繁化装换衣服了是个丢了西瓜拣芝麻的行为。
从商业宣传上考虑，这时候换STYLE价值也不是很高。作为一个后台应用系统
关于风格改进：
一个全新的系统上线的头一年，随着用户反馈，和功能完善，布局和设计都会有很多变动。所以这个时候调整的风格，框架，很有可能会在半年后，随着功能的增加和改进，被推翻。
尤其是视觉上标新立异的设计，视觉疲劳的风险就更大。
所以第一期产品设计，风格尽量简单。除非是你有个象苹果那么牛的设计师，还有足够的经验。
我计划了一个启发式评估调查。
用的是《启发性可用性评价量表(PHUE)》。根据WEB应用系统的特性，我自己改编了一下，并且撰写的量表说明。但遗憾的是，由于担心对用户骚扰过度，这个评估被取消了。我很担心，因为我认为：用户体验的好坏，不能是某个人说了算，或者是内部某几个人说了算。应当是由用户反馈给我们意见。并且收集反馈意见是有技巧的，不是简单的问，你对这个系统满意么就能得来的。好的调查方法，可以更好的指导交互设计如何改进，从哪方面下手改进。
不过后期已经计划要做上线后的可用性测试。用户观察。用来做进一步改进的基础。
方法参照《用户体验度量》及《用户体验面面观:方法工具与实践》
七、结案陈词（一些想到而没有做到的）
首先，第一阶段花了太多精力做规范。以后第一阶段只列提纲，规范详细内容随控件开发逐步补充。
第二，框架不能定的太早太死，随着对业务的逐渐深入了解，框架要变可能是无法避免的事情
第三，详细原型不能在概要需求阶段就出，会分散产品经理的注意力。
第四，详细需求出了以后，原型要尽早出，尽早做用户测试。要写设计日志，把每次重大变更记录下来，并附自己不同意见。通过这两方面同产品经理建立信任感。
第五，产品设计初期，要抓典型用户，不能覆盖面太全。功能要筛最重点的核心功能。否则设计的产品就会“散而无神”。
第六，早点让测试人员帮你看原型，他们的方法能测出很多隐含的逻辑错误。
第七，优化也要分重点，不能因为哪个快就做哪个。要看哪个功能更核心，对用户影响的最大。
第八，设计追踪很重要，上线后要假装成培训师，亲自看用户怎么使用产品。
第九，尽量能出整套高保真原型，UE和UI核对高保真原型。测试和开发根据高保真原型复核。
第十，一些重大的改进问题，经过讨论，不能马上改，要记下来，挂在明显位置。找机会安排进月度计划
最后，一个未解决的问题，产品经理，老板都很有想法。经常关怀过度。比如文字的位置，跳转的方式都会给“强烈建议”怎么办捏。
PS：有人告诉你先按最好实现的方式实现功能，然后在上线前优化设计方案。别信，那样会导致开发和测试人员抱怨交互方案老改。而且本来已经开发好的页面，改成全新的方式等于重写。那么还不如之前少实现几个次要功能。
