关于设计品质保证(DQA)的几点想法
<p class="pageview"><P align=left>出差到了中国雅虎,这里的风格和淘宝很不一样。和雅虎一比,淘宝的办公环境就是个菜市场,闹哄哄,到处是人,在走道里狂奔乱窜,在每个会议室争得面红耳赤……</P>
<P align=left>感觉确实不一样,这里很技术,很工程师风格。在这种安静的环境下,刚好给我一些时间记录下最近一直在思考的问题:DQA(Design Quality Assurance)。</P>
<P align=left>如果现在搜索DQA,是可以搜出不少的,但似乎只局限在传统制造行业。比如这家<A href="http://www.aaeon.com/A_About_Content_F5947A4134854B3BA6_BIG5_big5.html" target=_blank>中国台湾的硬件制造公司</A>介绍了他们的DQA:</P>
<P align=left><STRONG>DQA </STRONG>- Design Quality Assurance starts at the conceptual stage of a project and covers the product development stage to ensure quality is designed-in by quality engineers for reliability. All AAEON products must pass safety and environmental testing by a laboratory to ensure the product meets the requirements of CE/UL/FCC/CCC standards. Moreover, it also is required to go through an extensive and comprehensive test plan for compatibility, function, performance and usability.</P>
<P align=left>注意几个关键词:test、requirement、standard、compatibility、function、performance、usability。</P>
<P align=left>仅从这家公司看的话,他们主要是用测试的手段,根据需求与标准,来评价产品的兼容性、功能、性能与可用性。</P>
<P align=left>看上去似乎可以直接延用至保证Web产品设计品质的活动中,那事实是否如此呢?让我们来作个简单的分析。</P>
<P align=left><STRONG>对象</STRONG><BR>首先要明确品质保证的目标对象。我觉得不仅仅局限在界面设计,而应该扩大到产品设计上。互联网产品的设计有一个明显的特征:界面设计完了,产品就成形了;产品设计好了,界面也八九不离十了。所以在很多互联网公司中,UI/UE和产品经理在工作职责和内容上都有不同程度的重合,在某些公司还成为某些矛盾的根本来源。这件事留作将来再表,我想说明的是,互联网产品的设计品质,是由界面与功能设计一起决定的,而且目前还没有很好的区分它们的办法。</P>
<P align=left>所以,在这种情况下,不如放弃费神费力(还不讨好)想把界面和功能分开评估的想法,就把它们当作一个整体。这个整体就是<STRONG>产品</STRONG>,我们要保证品质的,就是<STRONG>产品设计的品质</STRONG>。</P>
<P align=left><STRONG>指标<BR></STRONG>那么产品设计的品质由哪些指标来评估呢?上面提到的这家公司的评估指标包括:requirement、compatibility、function、performance、usability。用大白话说,就是产品设计有没有达到需求的要求,兼容性是不是好,功能是不是完备,性能有没有问题,是不是好用易用?</P>
<P align=left>我们没有在这里看到商业上是不是成功、市场接受程度是不是高这样的指标,这是必须明确的一点,品质保证只保证产品<STRONG>设计</STRONG>的质量,而不保证产品的成功。如果这一点不明确,品质保证就承担了不可承受之重,也是不可能开展的。</P>
<P align=left>所以就互联网产品<STRONG>设计</STRONG>来说,我觉得要保证的品质指标可能有这么几方面:需求质量、功能完备性、可用性、艺术一致性。</P>
<P align=left>·<STRONG>需求质量</STRONG>。即在产品设计最初的阶段,我们提取的需求是否是用户真正的需求,是否是用户最大的需求,是否是我们当下要满足的需求? <BR>·<STRONG>功能完备性</STRONG>。需求有了,那我们的功能是否满足了这些需求呢,是否以正确地方式满足了这些需求? <BR>·<STRONG>可用性</STRONG>。不用多说了,做界面设计的同行们都了解。也是目前大多数公司和团队在做的方面。 <BR>·<STRONG>艺术一致性</STRONG>。互联网产品设计是一件有艺术参与的活动,所以设计师在早期常被称为美工。但艺术是否可以评估高下呢?我觉得high level的部分是不行的。但在low level的部分,比如一致性上,是可以评估的。而一致性对互联网产品设计来说,是非常非常重要的一环,所以我把它也列作了一个指标。 </P>
<P align=left>我没有提兼容性和性能,因为我认为它们(无论前端还是后端)属于软件工程的范畴,应该由SQA(Software Quality Assurance)而不是DQA来保证。</P>
<P align=left><STRONG>标准</STRONG><BR>要评估一样东西,必须有相应的理论支持,依某种标准来进行。否则评估就成为一种主观的活动,而失去了<STRONG>保证</STRONG>的客观性与一致性。</P>
<P align=left>在这里插几句,对一些艺术性占更大比例的行业,特别是一些创意行业(比如广告行业),品质保证在很大程度上就是通过主观方法来进行的,而且还用得挺好。“首席设计师”制度就是这些行业最好的品质保证体系。有很多互联网企业也有“首席设计师”制度,但对互联网产品设计来说,艺术性所占的比重毕竟没有广告行业这么大,所以在“首席”之外,再加上一定的客观制度还是很有必要的。</P>
<P align=left>在谈DQA之前,我们先看看SQA。SQA的主要理论基础是<STRONG>软件工程学</STRONG>,这是一个已经发展了好几十年的学科。经过全世界这么多科研机构与企业的发展、实践,已经非常完善而完备了。标准方面就有CMM、CMMI、ISO、6SIGMA等等标准,所以在开展SQA活动的时候,有理论支持,有标准可遵循。</P>
<P align=left>反观互联网产品设计,我们目前可以利用的理论似乎只有<STRONG>可用性工程学</STRONG>,以及软件工程学的一小部分。而标准部分,也没有一个国际性的标准。可以说,我们已经踩在水里了,但前方还是需要摸着石头过河。</P>
<P align=left>OK。我们碰到难题了!这是个让人兴奋的事,每当难题出现的时候,就给了我们突破的机会。</P>
<P align=left>针对“指标”一节提出的四个指标,我们可以从各自的公司和团队入手,先制定基于实践的,简单可行的标准。比如《用户界面设计指南/规范》、《可用性检查表》、《用户需求检查表》等等。我们不求大而全的标准,我们只考虑短平快、切实可行的标准,具体应该怎么制定,怎么设计一个体系性的标准,现在我也没有头绪,先走出第一步再说吧!</P>
<P align=left>当然,如果有什么组织从更大的范围来考虑这些事,至少我是极其欢迎的。</P>
<P align=left><STRONG>活动<BR></STRONG>那么,除了标准,目前我们可以进行哪些设计品质保证的活动呢?</P>
<P align=left>借鉴SQA,我觉得至少可以包括这些活动:</P>
<P align=left>1. 产品概念阶段:<BR>通过用户研究的方法(问卷调查、访谈等)挖掘需求、验证需求完整性; <BR>2. 产品设计阶段:<BR>通过可用性测试的方法,来评估可用性状况。 <BR>3. 整个过程中:<BR>通过对设计活动过程的管理、监督,来保证设计过程的合理有序,保证设计交付物的完整齐备。 <BR>4. 设计完成后:<BR>通过对设计过程的总结回顾,改进设计过程、完善设计交付物的形式、完备设计过程文档模板。 </P>
<P align=left><STRONG>后语</STRONG><BR>昨晚与一饿着肚子的同行(^_^)交流,当他听说我要提DQA这个概念的时候,大呼:别,千万别,现在的设计行业已经够乱了!很有道理,现在各种概念已经多到让新人害怕、令高手厌恶。</P>
<P align=left>概念起起落落,但背后的目标都是不变的:做更好的设计,做更有价值的设计。</P>
<P align=left>为什么我要提DQA这个概念呢?</P>
<P align=left>从淘宝的实践来说,我们吸收了很多其他的概念,UCD/UI/UE/UR/Usability/Accessability等等等等,我们也从自己的角度多多少少地将它们应用到了平时的工作中。但这种应用是不成体系的,处于游击队的状态。这个项目的交互复杂,就做个可用性测试;那个项目的用户群不熟,就做个用户调查;这个项目的成员很多,我们的设计文档要更详细些,让大家随时可查。当然这样做很高效,我们可能还会继续这么做。但从长远来说,我们需要有一套成体系,有理论支持的方法论支持所有这些活动。</P>
<P align=left>如果把所有这些活动放到DQA的高度和体系里来,一切都很顺理成章,可以更好地推广UCD,也有可能把设计和设计团队的价值从“口碑”提升到“事实”的层面上。相信经历过这些痛苦又对SQA有一定了解的同行们,一定能理解这其中的蕴涵的能量。</P>
<P align=left>原文链接:<A href="http://ued.taobao.com/blog/2007/11/16/dqa/" target=_blank>http://ued.taobao.com/blog/2007/11/16/dqa/</A></P></p>
页:
[1]