软件研发中的交互设计(TechED Beijing 2008 DEV314)

再一次深深感谢冒着室外严寒室内酷热来听我课程的同仁。传统的交互设计对流程和非体验部分不够深入，希望经过我们共同努力裁剪过的六册交互设计能给更多的用户和产品带来助益。同时祝愿更多的朋友设计出让用户为之倾倒的软件。

相关课件在此下载https://files.cnblogs.com/msdpe/张大磊RayZhang_软件研发中的交互设计.pdf

下面是PPT中的文字版大纲：

软件研发中的交互设计
张大磊
Ray Zhang

Know each other…
Ray Zhang
Microsoft
Blogs.msdn.com/think

We’ll not cover   
Business factor of product success
Design Patterns
Specific IxD tools/skills
Detail dev/test design and implementations
SDLC

主 要 内 容
我们的软件怎么了?
如何才能做的更好?
交互设计介绍
在软件研发中融入交互设计
相关问题

我们的软件怎么了?－示例1
我们的软件怎么了?－示例2
我们的软件怎么了?－示例3
我们的软件怎么了?－示例4
我们的软件怎么了?－示例5
我们的软件怎么了?－示例6


我们的软件怎么了?
主 要 内 容
我们的软件怎么了?
如何才能做的更好?
交互设计介绍
在软件研发中融入交互设计
相关问题

如何才能做得更好？

用户体验三要素

操作机制简单自然
用户完成操作容易、快捷
产品Usability是基于一些原则的:
Discoverability: 第一次即可轻松找到并完成一项任务
Learn ability:用久之后熟悉相关操作并能正确猜测到类似操作
Efficiency: 为熟悉产品的用户提供高级操作支持
例子: Windows Vista 开始菜单

用户体验三要素

Windows XP开始菜单
Windows Vista开始菜单

某些设计原则是软件界面，代码，现实物品共通的
这样的设计成品比较易用:
可供操作的控件放在明显位置
用户操作符合用户期望
用户操作立即得到反馈，操作结果与附带效果显而易见
用户体验三要素

用户体验三要素

Window management
Glass window frames
Dialogs and Wizards
System Tray
User Experience Tenets

产品设计三要素


让基本的功能简单，高级的功能能用 (80/20)
一定要为每个主要功能定义最常用的场景


产品设计三要素

Simplicity

# 1:  产品必须协助用户完成任务
# 2:  产品不能让用户感觉愚笨
# 3:  产品不能让计算机显得愚笨
# 4:  KISS
# 5:  不要有互相冲突的内容或信息
# 6:  产品具有统一的风格
# 7:  大体上产品颜色属同一色系
# 8:  在不同屏幕或界面中，导航必须功能相同、位置相同
# 9:  避免UI、图标中出现 比喻(metaphor)


产品线中向前兼容、向后兼容
与业务目标一致
差异化!

主 要 内 容
我们的软件怎么了?
如何才能做的更好?
交互设计介绍
在软件研发中融入交互设计
相关问题


Useful
满足用户某种需求
解决某类问题
Usable
操作自然顺畅
付出最小努力即可完成任务
Desirable
人们乐于使用或想拥有该产品
Useful / Usable是desirable的基础
Feasible
能否实现该产品?
是否与业务目标相一致?
是否有足够的人力、经费、时间

用户需要什么?
可以假定用户有哪些技巧?
他们能使用鼠标吗？会不会使用右键？会不会按住shift再点右键？
我们可以基于什么数据做出以上假设?
我们的软件产品能帮用户做什么?
找到一切可以利用的数据
统计调查表
市场研究
采访用户
来自Usability engineers 和Product planners的真实数据

用户可能想要做很多东西
我们必须聚焦在少量几件事情上
采取措施:
创见一个基于真实数据的用户需求排序表
每次release只作一小部分
找到数量/质量的平衡点

 使用纸、笔、白板均可
 分析出基本组件
 收集这些组件的详细信息
 思考如何交互
如何从A到B
如果点这里会发生什么
如何体现出B与C之间的关系呢?


发散思维
如果这个工具栏在左边会怎么样？上面呢？右边呢？
使用可移动位置的应用做实验
作出决定的最好顺序是什么?
什么是做决定的主要依据?


Scenario
从用户的角度描述用户感受
不能显示或隐式地定义解决方案
应该有多种可能的解决方案
应与相应的target persona相联系
收集各种end-to-end的用户场景，按重要程度进行排序
思考: “user story”


Personas
基于真实数据的带有上下文的user story的主角
代表目标客户的最深层次需求与愿望
提供目标客户对产品的公共理解，他们的语言也应该成为研发团队的公共语言
对在软件生命周期中始终聚焦目标用户和确定功能优先级非常重要
Personas are not:
每一个可能的客户或客户群体


Concept Prototype
表述远景与方向
不是一个spec，不一定被最终采用
目的在于集思广益

Low-fidelity
一人扮演计算机，让可用性测试对象基于纸的界面完成一个真实任务
在投入精力实现之前提供及时的用户反馈
加速快速原型迭代开发
促进研发团队内部沟通
不需要牵涉具体的实现技术
鼓励创新
由于低仿原型看起来”尚未完成”，可以产生更多的深度用户反馈

Low-fidelity 工具
记号笔
索引卡
纸
可擦除的双面磁带/CD/DVD
二次贴
半透明胶带

High-fidelity
脱胎于低仿原型，包括详细的任务流程故事板、用户场景与典型用户分析
可用于复杂系统交互规格说明书的可视化部分
可作为纸质规格说明书的有益补充
迭代几次，为最终的功能规格说明书收集用户数据


Usability testing
轻量级的非正式测试
任务列表
原型
记录手段 (纸、录像等)
耐心与倾听
尊重用户
因地制宜安排后续测试与随访


非功能性需求:
性能
可靠性
本地化、全球化
安全
维护性与可扩展性


The risk of data
所有数据都可能被误读
甄别有效数据，去除无效数据非常重要
Bad data is
不是系统收集的
基于错误的假设
使用特定人群的小样本量
“一个程序员观察一个用户”的故事

Avoiding the risk
专人负责可用性设计(至少是专人负责交互设计)
雇佣专业交互设计公司外包服务

评估用户与设计
启发式提问
采访
交互问询
可用性研究
拜访客户
兴趣爱好组
调查表
实验研究

User study & feedback


System Testing

主 要 内 容
我们的软件怎么了?
如何才能做的更好?
交互设计介绍
在软件研发中融入交互设计
相关问题

观念转变
角色合并
组织结构压力
用户群选择
保密
进度压力
相关问题

内容回顾
我们的软件怎么了?
如何才能做得更好？
交互设计介绍
在软件研发中融入交互设计
相关问题

疑问和解答