Littleyang

一、 设计交互规范

这头几天，我一直在熟悉这个产品，但是我始终没分清“弈衡”“弈择”“锐图”这几个产品是干什么的，从我这个非专业角度来看，都是对某一类人进行网络心理测评。
还需要对一个叫BSP的平台进行易用性分析。貌似是管理员后台。维护各企业的帐户信息，权限等等。难道这公司就非得把产品名字起的这么晦涩么？由于对产品不了解，我只能对产品很浅的交互设计问题提些建议。其实整个系统是如何运做，需要在这个系统上完成哪些任务，如何完成我还都不太清楚。

由于各部门同事成立。产品经理还在业务需求初步调研期。我们有点空闲。领导要求写份交互规范，目标：一致性最重要。
根据以前的项目经验，我认为连需求还不了解，不知道会用什么控件。交互规范的制订还为时尚早。于是从其他地方拽过来一套现成的。略加改动。

交互规范包含：

   1. 用户体验交互设计规范——基本原则
   2. 通用交互的规范
      链接，按钮，文字，表格的典型交互状态，规则描述
   3. 基本控件交互规范
      文本输入框，按钮，复选框，单选按牛，下拉列表，列表框，分组框
   4. 扩展控件交互规范
      翻页控件，气球状提示，表单提示，工具提示，
   5. 信息提示规范
      错误信息，警告信息，确认信息，提示，树形视图，选项卡，滑块，进度条，联想搜索，折叠层控件
   6. 导航规范
      引导，菜单
   7. 页面典型视图规范
      列表，表单，文档
   8. 窗口规范
      弹出窗口引用，布局，样式
   9. 文本规范
      语气及文字定义


这样一份长长的文档，在我还不知道要做一个什么东西的时候来确定，并且要Share给个部门，我怀疑是否有意义。而且前期，在这上面花很多心思没价值啊。

我倒想，这个作为提纲，每次讨论完细节后，把结论记进来，还是个不错的方法。

我们还确定了产品的框架布局，并且经过几次争论顺利通过评审（我得说，这是由于我们的经验不足，在这个阶段评审这个基本上会被颠覆）。

二、 了解需求

公司安排了两周的培训，从测评原理，到系统功能。我终于知道我们的产品具体要做哪些事情了，不过我还是分不清那几个产品的名字。对此，我在会上提了我的意见。虽然领导当时没点头（毕竟是他们创业之初好不容易确定的啊）不过后来我发现在新产品的开发中，这种代号消失了。

了解产品需求，就需要做用户访谈，不过这样可能会骚扰客户。所以我们抓了几个内部HR，资深销售，和长期接触HR的培训师做放谈，并记录了他们常用软件的使用轨迹进行分析。

放谈前列了提纲：

   1. HR访谈问题：
      HR日常工作职责有哪些？那些是重要的？那些是要费大量时间的？
      HR日常工作职责有哪些？那些是重要的？那些是要费大量时间的？
      工作中使用的HR辅助系统有哪些？使用情况是？业界其他HR会使用那些？
      工作中使用的软件有哪些？用途和使用情况是？
      招聘、选拔人才的难点是什么？
      那些职业类别的人才更难以把握？
      如果有可能，是否需要工具来辅助目前的工作?是那些?
   2. 销售访谈问题：
      以往发布的都是怎样一些产品？解决了用户哪些需要？那些需要没能解决？
      以往的客户中不同规模企业的比例是多少？
      不同企业对测评产品的需求差异是那些？我们满足了那些？不能满足的是？
      企业中购买我们产品的决策者在企业中一般是什么角色？
      吸引这些决策者购买产品的有哪些因素？
      老客户续签率有多少？没有继续使用我们服务的客户一般有哪些因素？
      目前企业中使用我们产品的人员在HR中是什么角色？
      用户通常在工作中的什么环节使用系统？前后关联的工作还会有哪些？用户工作中还会使用那些软件？信息系统？
      你认为什么样的产品或改进能够带动业绩增长？
   3. 访谈客服，主要是看客服记录
   4. 分析数据库，比如一些自定义功能，用户都是如何使用的

 

三、 设计原型

接下来被安排做一个很匪夷所思的任务，设计整个平台的“系统设置”模块。天！我都不知道平台上需要哪些服务，怎么设计“系统设置”的原型呢？经过争论，变更了我的任务，对以前开发过的系统设置进行优化设计。领导说，先搭个架子，以后优化。

研发计划是开发一个平台，平台上将承载和整合几个业务模块。 第一个业务模块的概要需求出来了，我开始加入焦点小组进行讨论。

产品经理们凭空讨论有点别扭。于是我开始画原型以供讨论（这是一个让我后悔不已的决定）。于是焦点小组的讨论点转移了，本来应该讨论用户是否需要一个导入功能，以及这个功能的开发优先级如何。现在变成了：导入功能这样实现是否合理。资源管理的菜单应该放在哪里。等等。于是我被牵着不停的改原型。经过无数次的小组讨论，原型终于初步确认。上会评审！！

在我设计的同时，前端的同志开始做控件开发，和几个典型高保真原型。但八十个人的研发团队，我们只有两个前端工程师的配置，要前端又开发控件，又开发高保真原型，工作量可是相当大的。我们可是3个交互设计师同时出产品。把所有高保真原型都做出来，实在是个太不靠谱的梦想了。 （前端页面发给开发工程师后，还要配合套页面，调BUG）

四、评审原型

老板和开发经理提了几个问题，诸如：“在这个场景下用户不使用这个功能是否可以顺利完成任务”“实现这个功能在8月前上线可能么？”我得说，我们确实在这方面的的讨论不充分。OK，重新更改。但是同志们看到原型还是不知不觉的讨论实现细节。

由于开发时间点的限制，原型被迫评审过了。

但比如说，页面框架结构不适用（由于框架已经评审过了，所以不能改）  列表控件有些功能无法实现  这样的问题已经无法改了。导致设计上有点尴尬，只是控件元素的堆砌。

开发的周期安排的很紧，原型才评完，开发就开始了（这倒是很正常）。但问题是我们没有来得及安排太多的用户测试。

产品的原型都通过了，系统设置这个支撑模块的设计很多都要改了。建议以后这个可以放在后面点再做。

五、 可用性测试
没有高保真原型了，没有。技术用 低保真原型来开发，没有 美术设计了，没有。前端直接照原型出典型的页面。开发已经开始了，然后再套页面。（前端人数确实是不够完成这样的工作量的 ）

我用低保真原型测了5个用户，包括5种使用我们产品的典型用户，有新的，有老的。并收集了反馈意见。发现了很多设计小组想不到的问题。但是改不改呢？设计过程中，焦点小组的讨论结果令我忙的团团转。而且没有流程完整的原型测试的效度就很低。没有时间安排高保真原型的制作和测试。有些研发部门坚持的就改了，在技术 开发完成之后。当然，这 少不了抱怨。很多很多 的抱怨。研发人员偶尔也会主动调整需求，跟着是交互原型的变化。这是个大团队，协调显然是不那么容易的。每个人都在 抱怨 变更，我也不满意设计出来的结果。

前期没有可用性测试也许看起来是节省了时间，但是从整个产品的开发效益来说，我认为这是个很有风险的事情。

六、 设计回顾，优化

原型公开发布后，陆续收到 销售，内部HR，研发人员，设计人员，测试人员的反馈意见。

比如搜索结果没有标红，用户根本无法得知自己的搜索状态。

比如某些功能实际上完全没有必要，但由于旧产品有，所以虽然上会N次，仍然不肯去掉。

比如菜单呈现方式，坚决要求按逻辑排列，导致整个菜单本来一共6项，结果差点被分成3个层级。由于分层太多，还有些鸡肋功能，导致界面很复杂。产品经理很不满意，反复更改。但是导致复杂的根本原因却不能动。

老板说安排了两个月的优化时间，满怀期望。准备了一堆改进意见列表，结果开发改进时间超过24H/人的，就都被cancel。

很重要的列表问题，搜索结果问题都不能改

有些调整问题倒是通过审批了，不过3次上会审批了，每次都 确定了改的责任人，却没有被领导安排在开发人员的月度计划里。结果每个月都被要求重写一次改进建议也没实施。（因为不同阶段要改的点不一样。需求和设计都被变动了）

随着产品的开发完成，一级菜单变成12个（产品只有六个，支撑模块却增加了3个，甚至业务部门要求增加待售广告链接）。在1024分辨率下，几乎就是一串文字。但是要改动菜单结构真是件大事情。需求方又拽着我们订好的旧规则，产品必须列在上面。

突然要换平台STYLE。原因是视觉设计不够“令人眼前一亮”  。重头开始美术 设计，重头开始套皮肤。工作量刚好2个月左右。

个人认为一个新产品第一阶段的重点是核心功能。连最基本的功能还没完成，就象一个人才生下来，胳膊腿还没出来，就开始频繁化装换衣服了是个丢了西瓜拣芝麻的行为。

从商业宣传上考虑，这时候换STYLE价值也不是很高。作为一个后台应用系统

关于风格改进：

一个全新的系统上线的头一年，随着用户反馈，和功能完善，布局和设计都会有很多变动。所以这个时候调整的风格，框架，很有可能会在半年后，随着功能的增加和改进，被推翻。

尤其是视觉上标新立异的设计，视觉疲劳的风险就更大。

所以第一期产品设计，风格尽量简单。除非是你有个象苹果那么牛的设计师，还有足够的经验。

我计划了一个启发式评估调查。

用的是《启发性可用性评价量表(PHUE)》。根据WEB应用系统的特性，我自己改编了一下，并且撰写的量表说明。但遗憾的是，由于担心对用户骚扰过度，这个评估被取消了。我很担心，因为我认为：用户体验的好坏，不能是某个人说了算，或者是内部某几个人说了算。应当是由用户反馈给我们意见。并且收集反馈意见是有技巧的，不是简单的问，你对这个系统满意么就能得来的。好的调查方法，可以更好的指导交互设计如何改进，从哪方面下手改进。

不过后期已经计划要做上线后的可用性测试。用户观察。用来做进一步改进的基础。

 
方法参照《用户体验度量》及《用户体验面面观:方法工具与实践》