UI设计,仅是画张图吗?

                                                   UI设计,仅是画张图吗?

uploads/200702/08_014739_uide.gif

很多时候,当别人问及你是做UI设计,会随口说:“哦,美工!“。象这样的称呼,很多有UI比较早的公司(比如金山,讯腾等),都已经改变了认识,但现实生活中却存在诸多对UI工作的误解和轻视。
在此仅举例谈一点日常生活中对UI误解的现象,并给出说明来,目的在于UI能更好的与软件开发的各部分协调。

UI自己的认识
一个做UI的新手,当参与产品前期的策划时,面对产品经历或者策划师的构想,几乎插不上嘴,理解这些构想就很困难,更不用说提炼出自己的任务来。
一个做UI的新手,当与程序员沟通时,发现自己完全不懂编程原理,以至于认为自己根本不懂软件,只好任由程序员摆布,甚至嘲笑。自己也懊恼不如程序员,程序员对软件什么都懂!自己后悔不会编程,甚至产生要做程序员的想法。
一个做UI的新手,只为了作图而作图;大部分的UI新手让大家感觉UI的苍白无力!

别懊恼!UI是一项很重要的工作:
1、UI设计是用来平衡用户需求与产品实施之间的矛盾的,它在开发的工作中贯穿整个过程。
2、UI表现了策划师的构想,编程实现并支撑着UI表现。

不信请看现在的软件开发流程
需求调查,用户研究 UI参与---->商业模型 策划 UI参与----> 交互设计 GUI设计 体验---->UI协调功能设计 编程实施 ---->UI参与 可用性测试 程序测试 体验 ----> 不断完善 (包括UI的改进)

软件开发是需要UI做很多工作,交互设计和GUI是两大主题。

老板眼中的UI
当前很多老板谈及软件开发,认为编程序才叫开发,UI就是画皮罢了,根本不把UI纳入开发流程。但开明的老板开始意识到UI好坏直接关系到产品在商业上的成功,于是开始注重UI设计,但很少有了解UI具体工作的,直观的说就是设计的好看,好用。老板嘛,能开明就很不错了!

策划师,产品经理眼中的UI
策 划师和产品经理很少关注编程的质量,他们用业务逻辑和形象描述来表现产品,进而实现商业模型;他们关注的是软件使用效果及软件的形象;虽然他们自身并不做 具体的软件交互及GUI的具体工作,但把大部分的期望都交给了UI。所以在做软件交互之前策划师和产品经理会把业务逻辑及产品的样子描述出来,随后便对 UI体现充满童憬!

程序工程师眼中的UI
入门级程序员说,我要实现软件,要编程序,让美工(指UI)配合我画几张图来。在与UI的沟通中,认为UI太弱智,不懂程序,于是就根据具体的实现随意窜改UI,到头来认为自己很牛气!署不知自己颠倒了顺序,UI设计应该来指导或者约束编程才对。

高级程序工程师在做编程之前会找UI沟通,索要i需要的UI元素,实现时尽量减少产品和设计的误差。产品获得用户的喜欢,程序工程师也实现了自己的价值。大家是协作的不可分割的团体。

UI在工作中给同事的感觉
因为UI的工作结果基本上不是文档就是设计图,所以给不太了解UI的同事感觉UI就是画图,也没什么的嘛!编程序多牛!UI也就是画几张图给程序用。

同事都直观的认为UI是画图的,那么在社会上流传起来难免会认为UI=美工了。

对于用户,UI是他接触的全部
因为UI是前台表现,所以用户看到的只有图形界面。使用软件的过程实际就是根据UI表现与计算机交互,以达到操作软件的目的。用户会根据使用的感受选择自己喜欢的产品,而不去关注代码是否写的优化,实际根本看不到代码,也看不懂。

一般意义上,很多用户认为图形界面也是编程,会忽略设计的过程。但不管怎样,只能看到界面、体验界面。

### 绘制 UML 表的方法 #### 用例 (Use Case Diagram) 用例用于描述系统的功能需求,通过参与者和用例之间的关系来展示。创建用例的关键在于识别系统中的主要角色及其目标。 ```plantuml @startuml actor User as user participant "System" as sys user -> sys : Register\n(注册) @enduml ``` [^1] #### 类 (Class Diagram) 类展示了系统的静态结构,包括类、接口以及它们之间关联的关系。设计良好的类有助于理解程序架构并促进团队沟通。 ```plantuml @startuml class Car { -engineType: String +drive(): void } @enduml ``` [^2] #### 对象 (Object Diagram) 对象表示特定时刻的对象实例间连接的具体情况,是对类的一种补充说明方式。它通常用来解释复杂概念或验证模型的一致性和完整性。 ```plantuml @startuml object car1 : Car{ engineType="Electric" } @enduml ``` #### 构件 (Component Diagram) 构件描绘了组成应用程序的不同模块及这些模块间的依赖关系。这对于分析大型项目的内部工作原理非常有用。 ```plantuml @startuml package "Business Logic Layer" { component BLL } node "Data Access Layer" as DAL BLL --> DAL @enduml ``` #### 部署 (Deployment Diagram) 部署显示物理硬件节点上运行的软件组件分布状况。这可以帮助规划服务器配置和支持运维管理决策制定过程。 ```plantuml @startuml node ServerA { artifact MyApp.war } @enduml ``` #### 序列 (Sequence Diagram) 作为交互之一,序列强调消息传递的时间顺序,适用于表达操作流程和服务调用链路等场景下的逻辑控制流。 ```plantuml @startuml Alice -> Bob: Hello, how are you? Bob --> Alice: I'm fine thanks. @enduml ``` #### 协作 (Communication Diagram) 另一种形式的交互——协作则更关注于参与交互的对象本身的位置布局而非时间轴上的事件发生次序;适合展现多实体协同工作的模式。 ```plantuml @startuml participant "User Interface" as UI participant Controller UI -> Controller : Submit Data @enduml ``` #### 状态 (State Diagram) 状态定义了一个有限自动机的状态变迁机制,能够清晰地呈现事物生命周期内的各个阶段转换条件与动作响应规则。 ```plantuml @startuml [*] --> State1 State1 --> [*] @enduml ``` [^3] #### 活动 (Activity Diagram) 活动类似于传统的流程,但增加了分支判断、并发执行路径等功能特性,可以很好地模拟业务处理步骤或是算法实现细节。 ```plantuml @startuml (*) --> A A --> B split B --> C B --> D split again C --> E D --> F merge E --> G F --> G G --> (*) @enduml ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值