论坛首页 综合技术论坛

介绍一种好的设计方法——在软件设计前先画界面图

浏览 70593 次
该帖已经被评为精华帖
作者 正文
   发表时间:2005-02-05  
我也用过,比拿着Use case给客户看要好多了,不用解释什么。

不过我一般拿word画,巨不爽。应该有工具划界面,再生成代码,html,swing都支持。让uml case tool见鬼吧
0 请登录后投票
   发表时间:2005-02-05  
plutomonth 写道
我也用过,比拿着Use case给客户看要好多了,不用解释什么。

不过我一般拿word画,巨不爽。应该有工具划界面,再生成代码,html,swing都支持。让uml case tool见鬼吧

很多开发者对于 Use Case 的理解都存在着误区,误以为 Use Case 就是 UML 图,Use Case 就一定应该是图形化的。以前 ozzzzzz 和我都曾指出过这个错误,看来这个问题我们还需要反复澄清。Use Case 的历史其实比 UML 还要长的多。Use Case 图是 UML 图中的一种,但是最基础的 Use Case 并不是图形化的,而是基于文本的。建议仔细读一下《编写有效用例》这本书。

而界面设计,跟 Use Case 有很大的关系,但是不能混为一谈。界面设计相当于 Use Case 的具体实现。在《面向使用的软件设计》中,界面设计是整个交互设计过程中比较靠后的一个阶段。
0 请登录后投票
   发表时间:2005-02-12  
dlee 写道

在《面向使用的软件设计》中,界面设计是整个交互设计过程中比较靠后的一个阶段。

界面设计比较靠后的思路不一定正确吧。一个能够抓住用户的产品在功能和别的产品相差无几的时候,界面可能是制胜的利器。
0 请登录后投票
   发表时间:2005-02-12  
那又在什么时候,定义产品功能呢?
又怎么知道你的产品功能和别的产品功能相差无几呢?
0 请登录后投票
   发表时间:2005-02-16  
tuti 写道
那又在什么时候,定义产品功能呢?
又怎么知道你的产品功能和别的产品功能相差无几呢?

我这里说的功能是使用者眼里的功能。
比如论坛,基本都提供发帖子和回帖子的功能。
功能相差无几的意义就在于这些有的论坛可以加头像,有的论坛能够以树型浏览帖子,但即使没有这些功能使用者也可以容忍,这些功能就属于相差无几的范畴;但要是连回帖功能都没有,那就不能忍了。功能相差无几就是这个意思:没有的功能,使用者能忍。
0 请登录后投票
   发表时间:2005-02-18  
我们在最新一个项目中是这样进行的:
使用UML完成业务模型,和逻辑模型;
然后根据分析结果,开始做界面流程图,和效果图;
与客户交流时多使用这些界面流程图和效果图;
当需要修改和完善需求时,同时改动UML和这些图:用户需求驱动UML分析设计,UML分析设计驱动图的设计,图的设计也会影响到UML的分析设计。
其实说了这么多,最终是能够与客户在业务理解上达成一致。
0 请登录后投票
   发表时间:2005-02-18  
ddd 写道
界面设计比较靠后的思路不一定正确吧。一个能够抓住用户的产品在功能和别的产品相差无几的时候,界面可能是制胜的利器。

界面设计在整个交互设计的过程中确实是很靠后的一个阶段。为什么是这样呢?因为面向使用的软件设计着眼于怎样使用户更有效地完成他真正想要完成的任务。面向使用的软件设计是以任务建模为核心来设计系统的。我来举个例子:比如你设计一个取款的应用,如果你马上进行界面设计,你肯定会想到应该有一个键盘和一个屏幕,用户插卡进来,敲入密码,认证成功后敲入金额,然后支付给他相应的钱,最后退卡。你这样想也没有什么大问题,因为这就是传统的 Use Case 所完成的工作。但是这样想就把你的思路局限住了,因为在这里用户真正需要完成的任务是什么?是验证身份和取钱本身,而不是敲入密码。用户只想得到他的钱,他并不想敲键盘。

这种传统的用例在《面向使用的软件设计》中被称为具体用例。这种具体用例有什么问题?作者写道:
引用
对于用户界面设计人员来说,这种拘泥于具体表达形式的做法构成了传统的具体用例对设计活动的一种严重限制。在某种意义上来说,关于用户界面形式和功能的某些设计决策已经被确定,并且已经以隐含的方式被嵌入在用例的表述中。

在这本书中,作者提出了一种新的基本用例的概念,可以支持我们在更高层次上考虑用户使用系统的问题。
引用
基本用例描述了交互操作,而并不涉及有关技术或实现机制的任何明显或隐含假设。
在某种意义上,后一种用例是一种基本模型:它是对问题的一种抽象、理想化和与技术无关的描述,最低限度地涉及特定解决方案的假设。因此,与场景和具体用例相比,这种形式的用例更接近于关于用户使用系统真正意图的直接描述。
因为基本用例是“基本的”,所以基本用例对于实现一个合适的用户界面留下了更多的选择余地。
场景、具体用例和基本用例是相互联系的任务模型,它们具有不同的抽象、简化和一般化程度。从场景到具体用例,再到基本用例,我们越来越接近于对用户的需要和意图的纯粹和理想化的描述。由于基本用例是对系统必须提供能力的简化描述,因此它们也为建造更小、更简单但能满足用户需要的软件指出了一条途径。

面向使用的软件设计的核心就是任务建模,采用这种设计方法,首先需要明确用户真正想要完成的任务(采用基本用例来描述),然后才去确定具体采用何种实现来支持用户所要完成的任务。采用这种设计方法,只要技术条件许可,用户就不一定非要敲键盘才能验证自己的身份,他也可以使用指纹识别或者虹膜识别等等舒服的多的方式。可能他只需要在验证完身份后说一声:“兄弟,我需要 1000 元花花。” 然后 1000 元就出来了。其实用户的真正目的不过就是取钱,如果你真的能实现这些新的人机交互方式,用户肯定会非常满意的。

界面设计相当于具体用例的实现,这就是我说的界面设计在交互设计中是比较靠后的阶段的原因。
详细内容可以看看《面向使用的软件设计》的第 5 章。
0 请登录后投票
   发表时间:2005-02-19  
dlee 写道

界面设计在整个交互设计的过程中确实是很靠后的一个阶段。

详细内容可以看看《面向使用的软件设计》的第 5 章。

您说的这些思路我认为是典型程序员思路,抓住最核心的东西,抓住功能,这本身倒谈不上错误。
我感觉很多程序员是沿着这种思路过来的:能完成功能就行了,至于如何完成功能,我说了算,不管用户用起来是不是有点麻烦这种,后来随着经验的丰富,能够预先的设计交互,并为用户考虑很多。
思路基本就停到这里了,我觉得还不够,因为这基本是瀑布型,第一起始设计就是开发方为主的,第二在交互设计过程中和用户交互少。
实际项目中很少考虑用户的真实感受,所以现在交互设计我觉得基本是粗线条的,同时导致开发方对交互设计并不那么重视,库珀在哪本书提过这些东西。

直接回答您的问题就是验证身份这种核心功能一定要实现,以什么方式实现都行,但如果要做到让用户很轻松就能在一个没见过的机器上操作,界面设计要优先。
关于用例,我认为从根本上不解决易用性问题。

《面向使用的软件设计》没看过,不知道里面是否解答我说的问题。
btw:基本用例的概念感觉上没什么太多新意,有可能仅仅是创造出来的一个词汇。
0 请登录后投票
   发表时间:2005-02-19  
ddd 写道
实际项目中很少考虑用户的真实感受,所以现在交互设计我觉得基本是粗线条的,同时导致开发方对交互设计并不那么重视,库珀在哪本书提过这些东西。

这确实是一个很大的问题,因为这种倾向直接导致了生产出来没有吸引力的产品。现在国内的软件公司还是处在一种粗放式的竞争环境之中,能够把产品做出来就能赚到钱吃饱饭(软件能顺利跑起来并且很稳定就自以为很牛x了)。等到将来竞争达到更高的阶段,我想会有越来越多的公司开始重视这些问题的。因为这直接关系到生产出来的产品卖不卖的掉的大问题,不关心钱的人似乎是少数吧?即使程序员不关心,老板也会强迫他关心的。
Cooper 的那个观点应该是在《The Inmates Are Running the Asylum》这本书中提到过。

《面向使用的软件设计》这本书还是蛮有新意的,其中的很多观点我没有在其它任何一本关于交互设计或者软件工程方面的书中看到过。得到 Jolt 的 product excellence 大奖也是有道理的。我觉得还是值得一读的。我不是书托,是否值得一读各人有各人的看法。

ddd 写道
btw:基本用例的概念感觉上没什么太多新意,有可能仅仅是创造出来的一个词汇。

个人意见,你的这个判断是错误的。基本用例和具体用例的差别还是很大的。我曾经专门为这个问题和国内的用例专家 ozzzzzz 讨论过。
0 请登录后投票
   发表时间:2005-02-20  
您有一点跑题了
我更关心"界面设计是整个交互设计过程中比较靠后的一个阶段"是否正确。
我说那一大堆的意思是要说明一个问题:将界面设计放到最后是一种程序员惯性思维带来的。
而要为用户着想的话(也应该这么做),界面设计不能靠后。

关于基本用例,没看过那本书,基本没发言权。
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics