《需求设计:构建用户想要和需要的产品》——2.5 用户界面设计

2.5 用户界面设计

用户界面设计指的是对应用程序的终端用户界面和服务的编程接口所做的设计。
对于在线应用程序来说,用户界面由应用程序所要显示的各种画面组成。在设计用户界面的时候,笔者不会详细地设计这些画面的布局或风格,因为这些内容可以稍后再做,而且最好是有专业的图形设计师帮着做。笔者在该阶段要做的是逻辑画面设计(logical screen design),这种设计用来确定每个画面上应该显示哪些数据、用户可以在画面中执行什么操作,以及这些画面之间如何切换,也就是说,用户是怎样从一个画面转到另一个画面的。图2-8以一个联网的银行业应用程序为例,演示了其中的一部分用户界面设计。图中的方框表示画面,连线表示画面之间的切换。左上角的虚线框表示菜单条,它会出现在应用程序里的每一个画面之中。
这种用示意图来展示用户界面设计的办法,有一个缺点,那就是有可能要画许多张图,每张图只演示整个界面之中的某一小块。假如把这些全都用一张大图来表示,那就太乱了。
我们还可以用文本形式来简单地表示画面之间的切换,这样做还可以包含更多的细节,例如,画面中应该显示的数据、用户输入数据所用的字段,以及单击按钮的效果和该动作与数据库之间的联系等。这些详细信息,通常可以从情境设计方案之中复制过来。实际上,笔者觉得一开始最好是以文本形式来展示用户界面的设计,因为这种形式编辑起来比较方便,等到要把这些信息拿给别人看的时候,再去绘制图表。第8章将会更详细地讨论这种文本形式。

之所以要从逻辑上进行用户界面的设计,其主要原因是想强调易用性。易用性比画面的视觉效果重要得多。用这种轻便的方式来展示设计,可以使大家把注意力放在与视觉效果无关的那些方面,而且也使得设计者更愿意去讨论各种替代方案,因为他们无需在界面的显示效果上面投入过多的时间。
如果能够保证情境设计之中的每项功能,都在用户界面的设计之中有着对应的部分,那么这套用户界面的设计方案就是完整的。
在评估易用程度的时候,还有很多其他的问题需要考虑。你应该请项目的利益相关者也参与到设计过程之中,这不仅可以很好地检查用户界面,而且还能够判断出早前的情境设计是否有效。
服务与在线应用程序不同,它没有终端用户可言,对它来说,别的程序就是它的用户。对服务所做的用户界面设计,指的是设计该服务的可编程接口。我们通常要考虑的问题是:应该把服务数据放在一条大的消息里面,还是应该分成许多条小的消息来提供。这种设计所需的技能与技术知识,与设计屏幕画面时所需的知识完全不同,我们将在第7章中详细地讨论服务设计。

时间: 2024-09-21 02:40:55

《需求设计:构建用户想要和需要的产品》——2.5 用户界面设计的相关文章

《需求设计:构建用户想要和需要的产品》——3.3 用例

3.3 用例 在前面几节之中,笔者对敏捷开发做了批评.除了敏捷开发,目前还有一种比较流行的做法,那就是通过编写用例来捕获需求.这一节要讨论用例与情境设计之间的区别. 用例,本质上是用一系列带有序号的步骤,来对场景进行简单的文字描述,就此而言,我们可以在各种详略不同的层面上撰写用例.此外,还有一些用例图可以展示每位参与者所使用的用例,以及用例之间的扩展关系,这里所说的参与者(actor),与情境设计之中的用户组有些相似.笔者稍后会讨论什么叫做"扩展".用例图与笔者所说的情境图看起来很像,

《需求设计:构建用户想要和需要的产品》——2.9 小结

2.9 小结 笔者以业务应用程序为重点,展示了IT应用程序的设计轮廓.本章概述了每一种设计所要做的事情,以及这些设计之间的信息流动情况,这为后续各章打下了知识基础.情境设计的输出物,显然是情境设计方案本身.用户界面设计的成果,是逻辑用户界面以及服务接口描述.数据库设计的成果是数据库的schema,而技术设计的成果,则是一份提供给程序员及利益相关者的简报,以及一个可以运作的系统测试应用程序,该应用程序能够接收由程序员所编写的实现代码.在这些设计制品(design artifact)之中,除了情境设

《需求设计:构建用户想要和需要的产品》——2.8 这样做真的是工程化的设计吗

2.8 这样做真的是工程化的设计吗 笔者提出的六框设计模型,与经典的工程组件分解图并不完全相同.因此,有人会问,这样做真的能像第1章所说的那样,实现工程化的设计吗?这个问题不能简单地用是或否来回答.在建筑学和机械工程学之中,宏观设计图与组件设计图的绘制方式是相同的,都需要确定一些形状及表面,而且所有的组件都有其尺寸及重量.此外,从顶层设计到底层设计之间的层数,是没有限制的,换句话说,可以把组件分成子组件,再把子组件分成更小的子组件,这种划分可以多次执行.然而,对IT软件开发所做的设计,却不是这样

《需求设计:构建用户想要和需要的产品》——2.3 集成设计

2.3 集成设计 集成设计的主要目标是: 把任务划分到各个应用程序与服务之中. 决定数据表与数据库之间的指派关系. 以应用程序之间所传递的消息为视角,来定义集成方面的需求. 对于其他更为详细设计的来说,集成设计确定了这些设计的范围.用户界面设计可以针对每个应用程序或服务分别来做(对于服务来说,其用户指的是另一个程序),数据库设计可以针对每个数据库分别来做.尽管技术设计也可以针对每个应用程序或服务分别来做,但是在大多数的公司里面,我们都可以令多个应用程序与服务共用同一套技术设计.图2-5演示了如何

《需求设计:构建用户想要和需要的产品》——2.4 技术设计

2.4 技术设计 集成设计之下的那一层,可以分为三个领域:技术设计.用户界面设计与数据库设计.本节讨论技术设计.技术设计有两大目标:1.设计出可以满足非功能型需求的解决方案.2.设计出可以尽量简化功能编程的解决方案.非功能型的需求,是指那种与业务工作并没有直接支持关系的需求.它们包括: 所应满足的吞吐量及响应时间. 可用性方面的目标. 灾难恢复方面的要求. 安全设计.你需要知道应用程序的安全漏洞.修复这些漏洞的办法,以及系统监控与系统管理工作的执行方式与执行地点. 系统操作和系统管理的易用性.

《需求设计:构建用户想要和需要的产品》—— 导读

https://yqfile.alicdn.com/6ec696e3acab5ead903c7f9a25ac9ef090aeb814.png" > 前 言Designing the Requirements: Building Applications that the User Wants and Needs在对IT应用程序开发思考了大约15年之后,我终于写出了这本书.20世纪90年代后期,我开始做IT架构,当时写了一本名叫<IT Architecture and Middlewa

《需求设计:构建用户想要和需要的产品》——第1章 情境驱动设计入门1.1 对需求进行设计

第1章 情境驱动设计入门 本书讲的是如何设计IT应用程序.笔者写这本书,是想建议大家采用与原来不同的办法去做设计,尤其是想进行下列三项变革: 要使人意识到自己并不是在收集IT应用程序的需求,而是在设计它们.对应用程序所做的设计工作,正是建立在这样一种认知之上. 要把程序的设计做得像工程学一样,特别是要在实现之前先对设计进行分析,并寻找其中的缺陷. 要确保当前所开发的应用程序能够与现有的或同时开发的其他应用程序协同运作,以创建出一套连贯的IT架构. 本书要谈论如何思考应用程序的设计,以及如何对设计

《需求设计:构建用户想要和需要的产品》——第2章 设 计 体 系2.1 为什么应该建立设计体系

第2章 设 计 体 系 第1章说过,要想做工程化的设计,就必须有一套设计体系.那么本章我们就来看看能不能为IT软件的开发工作构建出一套具有工程学水准的设计体系,并且看看我们是否值得去构建这样的体系.本章分为三个部分.2.1节从下至上检视整个设计体系,以解释我们为什么应该建立该体系.接下来的2.2节-2.7节,用从上至下的方式来观察这套体系,使大家对设计之中的信息流动情况有所了解.把这套体系中的所有部件都展示出来之后,笔者会在2.8节之中回到本章开头所提出的那个问题上面.最后的2.9节是对本章所做

《需求设计:构建用户想要和需要的产品》——1.2 什么是设计

1.2 什么是设计 设计是个很常见的说法,没有几个人会深挖它的含义,但如果仔细想一想IT应用程序的设计与一般的设计的区别,你就会发现,IT应用程序其实是很特殊的.这种特殊性促使我们思考一个问题:应用程序的设计真有这么特殊吗?或者说,我们是不是将它看得太过特殊,以致忽视了一些最为基本的共性? 首先,我们来定义设计这个词.设计,是对想要构建的事物或系统所做的概念化处理.设计(design)既是名词,又是动词.刚才定义的是名词,现在我们给出动词的定义:(作为动词的)设计,就是指创建设计方案. 笔者故意

《需求设计:构建用户想要和需要的产品》——3.2 逆向设计

3.2 逆向设计 总的来说,笔者不太喜欢敏捷方法,但是这种方法也是有好处的.在个别情况下,这种方法可以奏效. 例如,笔者有一次需要编写一款做业务评审的应用程序,该程序对报表提出了要求,其中某些报表很容易就能从用户需求之中确定出来,但还有一些报表则无法这样确定.特别是该应用程序需要对业务方面遇到的限制进行记录,也就是把阻碍员工达成其目标的那些外部因素记录下来.项目的主要利益相关者要求这款应用程序能够提供某种分析功能,以便从描述这些限制的全部文字之中,找到一些共同的主题,他对我说,他知道一位朋友的朋