如何从用户获得GUI需求？（09-03-23）（获奖名单已公布）

默默巫

你是如何从用户获得GUI需求的？请大家畅所欲言！

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	rolei	当当购物卡50元	5#
二等奖	贝贝酷	300论坛积分	23#
三等奖	jackc	100论坛积分	10#

believe

1.若先前有软件情况，熟悉并分析用户已有的软件的GUI
2.熟悉行业特点
3.分析用户群的特点
4.分析同行的产品

wolsion

学习中，等待高手回答。。。

EasyZhou

了解用户的需求，把要生成的软件，先画个界面给用户了解了解。

rolei

1、最好是提供给客户个DEMO，由客户确认系统的整体风格；
根据行业特点，DEMO当然还要借鉴当前行业流行的软件的GUI设计方法，还有当前流行的界面设计方式。
如：客户会要求设计出类似XP的界面　：）

2、实施类似XP开发的开发，并在第一版本（越早越好）发布给用户基本的功能。
针对使用用户不同角色进行讲解、培训，收集结果，不断的进行改进。
收集的结果有一部分就是客户的GUI需求。
一般来说最终端的使用者，会非常关注GUI方面的东东：操作流程和界面搭配。毕竟他们要经常的操作和使用。

3、邀请行业专家参与GUI设计。
行业专家是一个行业流程的制定者和领导者，因此他们的操作习惯和特点会影响到其它人的应用，并且十分有说服力。

4、有时间、有机会多跟终端用户聊一聊，关注他们的工作特点，也就是站在用户角度理解系统、理解用户。
比如：如果工作需要长时间面对显示屏的，界面设计的比较花哨，怕是谁的眼睛也不能长时间忍受；
如果操作流程比较复杂，每人、每日的工作量又很大，系统不设计快捷键，怕是用户很快就烦了；
..............................

5、当然不论收集什么样的需求都要有一定的技巧，掌握基本的沟通、交流方式是必要的，可以看看这方面的资料。

[ 本帖最后由 rolei 于 2009-3-23 22:16 编辑 ]

archonwang

好久没来答题了。前段时间小忙，本次赶场子。

luna_jia

很久没来，凑个热闹。
1、了解用户的角色、业务，这个决定他们使用系统的关注点。比如录单员要求录入要快，这样就要有快捷的录入方式。而管理者可能更常做查询，要求查询的内容要明了，有针对性，这个对界面字段的排列要求就高些。
2、看客户以前用过的系统，了解他们的操作习惯。如果客户以前没用过系统，更好办些，因为养成习惯比改变习惯要容易得多。
3、试用，可以很快发现GUI中存在的问题。

imutou

5楼说的有道理。个人觉得，先由一个初步框架，那样给客户做DEMO的时候；就可以得到反馈，而且要求更有针对性，具体化。

drwei123

做一个最基本的给客户看，尽量和其确定详细的功能
结合该项目的特点,给客户以意见(但最终确定权还是在客户)如:业务上,技术上的
需求组或者开发组的任何一个细节(如:页面输入长度的限制)上的变更,都需要通知测试组的人,更新自己的 TEST CASE
做好客户需求和开发项目组之间的桥梁

最好能有个数据字典,开发那边能有个页面的输入限制的统一规范(当然了,该规范只是大众的,至少有个初级标准)

Jackc

偶简单总结一下，大致是以下两点：
1、GUI设计先行
在需求定义初期与客户共同确定GUI主体框架。当然融入行业专家和用户的建议的GUI设计，可以提供更高质量的GUI需求，但是需要注意质量和时间比例。
2、需求的修改
结合更多方面的信息（专家、市场、用户等渠道），通过与客户良好的沟通，最终完成“合适”的需求。

achong252159676

觉得看起来爽，而且操作不会混淆就差不多了
更高一层次的就是看起来美观，符合大多数人的审美观就行了

yetties2005

首先要与客户进行详细沟通确认GUI需求,其次做个DEMO界面与客户二次确认。

lwen

新手学习中啊~目前我们公司有自己一套自动化测试框架，UI是成了一个基本的分析要素。。。

test_fairy

5楼说的没有错,
根据我以前的工作经验看,终端的客户是最关心GUI 的,而参与或者说是与设计者
直接进行交流的人员往往只是中间的人员,他们最终可能与系统毫无关系,只是他们是领导者或者是了解微机而已
所以说要想了解最终的,或者是最为直接的需求,应该绕过这些人,直接去询问那些
真正的使用者,这样设计出来的产品来能够更加符合需求,获得更加好的评价.
举个例子:
ERP估计大家都知道一些,开发者们估计对这个产品也是相当的得意,但是在实际的工作过程中
我发现根本不是这么回事,我以前使用过这个,也带着别人用过,但是有很多方面并不
符合实际的需求,搞的应用人员怨声连连,当然评价就会打折扣,而这些真正的需求并不一定
会反映到开发者那里去,因为开发者联系比较多的是非专业人员.
呵呵,一点想法而已.

单尾鱼

LSD几位都分析得很好了，偶学习下！

peterz

我们先是做个设计稿，一般来说就是页面，但是页面上的数据都是假的，让客户有个感性认识。然后让客户去想。一般是1-3天时间。我们根据收集回来的信息。在重新设计页面，再进行沟通。反复几次。或者定一个截止日期。然后我们就可以根据这个进行开发了。当然除非是大问题，否则我们不会接受新需求

lanbiers

这其实也是一个迭代过程

1、用户提出需求说明
2、项目经理分析需求
3、UI人员界面开发
4、开会讨论界面
5、记录讨论结果
6、需求变动或界面修改
7、反复直到基本确定

ducan

1.从客户交流中，这应该很重要的
2.如果客户交流中很少的话，可以从以前的版本里面提取出来
3。还有就是从同行业的同类型产品里面找了

测动未来

我们测试，用户的需求都是零敲碎打，看哪里不顺眼，哪里提出来

1.了解用户的使用程度，比如如果是文化较低的使用。就要尽量从简练上考虑测试。
2.了解用户的工作量。如果是使用本软件工作量很大的。就从尽量从快捷上考虑。
3.行业习俗，习惯。
4.美观
5.

搂搂兔

嗯。问他们好了。这个我们测试人员真没法自己来定