###UI设计
UI
用户界面是系统和用户之间进行交互和信息交换的媒介，它实现信息的内部形式与人类可以接受形式之间的转换。用户界面定义广泛，包含了人机交互与图形用户界面，凡参与人类与机械的信息交流的领域都存在着用户界面。来自wiki
移动端或者web端的UI设计是视觉至上的同时需要考虑输入输出，点击触摸等各种事件产生的反馈，人和软件是如何互动的。不再单单的只是纯粹的设计一个封面海报等可以用一个静态画面描述的场景。点击什么控件，触发什么功能，软件是如何回馈的，界面上如何呈现，UI设计是一个动态的完整系统的设计。除了像国外的一些大公司可能有细分视觉设计和交互设计这两种职能，国内当前的UI设计师一般是在视觉设计的基础上还需要懂点互动设计方面的。一般关于大部分的互动方面的设计我们公司一般是由产品提出的。产品人员补充着UI设计师不擅长互动设计的缺陷。不管市场行情怎么样，一个全面的UI设计师（）应该是要有视觉设计（Visual Designer）和交互设计（Interaction Designer）两方面的技能。国内听说过测试驱动开发，但是还没听过设计驱动开发，我觉得一个好的产品的出现是这三者完美配合才会促成。好的设计也可以驱动开发这是我一个开发的观点。
User Experience Researcher 这个职位必须提一下，这是一个产品功能原创的保证。好的交互设计必然需要研究，交互设计需要用户体验的保证，某种程度减少摸着石头过河的不确定体验，不确定用户是否能接受。
ps：其他岗位
SA (System Analyst) 系统分析师
SD (System Designer) 系统设计师
RD (Research and Development engineer) 研发设计工程师
PG (Programmer) 程序员
PM (Project Manager) 项目经理（产品经理）
DBA (Database Administrator) 数据库管理员
MIS (Management Information System) 管理咨询系统（网管人员）
QA (Quality Assurance) 质检工程师（测试人员）
Sales 销售
###产品流程
- User Story(阐述什么人在什么情景下需要做某种事或者遇到什么问题，这时候需要某种功能能快速便捷的帮他解决问题)
- Functional Map（用来组织和划分功能模块）
- Flow Chart（确定流程的完整性和流畅性，检测逻辑漏洞，我们公司是用的）
- UI Flow－ a. Table of Contents文字版的 UI Flow b. 图片版的 UI Flow
- Wireframe（我们公司的原型图一般会标明触发，反馈，状态变化，界面跳转） a. 文字说明才是 Wireframe 的重点。
- Mockup a. Grid 和 Guideline b. 切图 c. 标注文件
###多种原型设计
- 纸上 Prototype
- Wireframe
- Mockup
- Web
- Code
Prototype
使用工具：POP - Prototyping on Paper 即兴讨论或思考时使用，不推荐流程性使用，一般直接参考其他应用的相似功能。因为这种草图不够直观，全面，细节不够完整，一般做这样的图会花一定的时间，但是效果不好，开发一般不喜欢这种图，经常让产品和开发不在同一个聊天频道，作为开发的我觉得这种图可以用来讨论大模块的功能需求，真的不如去找一个其他应用已经实现的效果来讨论来得直观。
Mockup
使用工具：InVision 比较常用的原型，推荐使用，使用者或者被宣讲者都能看得懂，容易上手，可以团队协作。
Web
使用工具：Hype3 可以用来测试用户体验的原型，可以实现动态效果，短时间内不需要写代码就可以产生想要的效果，供开发者参考。不好的地方就是需要学习使用工具才能学会制作出以假乱真的原型。我感觉最大的好处就是可以尽快看到使用者的反馈，提前预知使用反响，减少功能需求更改，功能的确定更快更准。不是所有公司都会做，我们公司就没有，最多只是到Mockup层级的原型，但是这种类型的还是挺普遍的，见过很多的设计或者产品会使用这样层级的原型制作。
总结：最推荐使用的是Mockup 和 web 这两种类型。
###页面状态（设计师交互层面的考虑）
点击某个控件，做某种操作，软件如何反馈给用户，界面是如何展示的。接下来我们会来描绘各种场景。
Ideal State 理想状态
出现预期的效果的界面展示。
Empty State 空白状态
界面上一般是不允许有空白界面的，因为不能让用户不知道该怎么操作，当某个界面没有数据，必须提示用户，是用户本身没有制造数据，还是其他原因没有展示数据。降低用户使用app的紧张焦躁感，让用户知道他当前的操作状态，现在在哪一步，下一步可以干么，可以放心操作的感觉，很多种感觉形成了整个软件易用的体验。
Maximum State 极限状态
关于极限状态的提示有很多场景。
场景1:声音的调整有进度条给用户查看已经调整到最大值了，继续按也不会再增长了，用户就会停下按声音调整按钮。
场景2:微信未读消息数量已经达到最大值界面上会显示99+也就是说只能精确的统计99条未读消息。超过99条的临界值不需要使用过多的界面去描述，因为这种状态已经很多了，99+已经可以准确的告诉用户，有很多消息没读。
场景3:电池的多种状态提示是一种多层级的状态提示，可以说是每个层级极限状态的处理，20％电量的状态提醒，10%的电量状态提醒，没电的直接关机等。
Error State 错误状态
错误状态在开发中最常见的算是网络请求的错误提示，各种各样的状态码对应的错误状态导致的请求不到数据，或者各种用户不预期的操作错误。
常见的情景有：
场景1:数据库异常
场景2:输入的密码需要至少6位的以大写字母开头混合数字组成的字符，这些状态下如何和用户交互，界面上如何展示给用户，给用户反馈。
Loading State 加载数据状态
网络状况不好的情况下，加载数据是一个漫长的过程。如何在这个过程中给予用户反馈，消除用户等待的焦虑感。
这有一段挺漫长的改进过程
阶段1:刚开始的软件没有任何提示，用户在不知所措中等待或者操作。
阶段2:提示用户，正在加载数据中，有时候时间长，用户不知道该不该继续等待。
阶段3:显示加载进度，告诉用户加载到什么程度了，但是有些明明就是停止了加载，但是用户无法取消，只能杀掉进程，重新打开应用，中断刚才可能已经完成了90%的操作，简直快崩溃的心理。
阶段4:各种样式的加载动画，和加载进度，提供给用户取消加载的操作。
通常一个事件的反馈可以是上述的几个状态整合而成。比如说下载音视频时，
1.下载结果：理想状态就是完整的下载完，可以播放。错误状态下，就是下载不完全
2.下载过程中包括开始下载时是否出现空白状态，下载状态如何表示，下载100%的时候界面如何变化。
我还在学习当中，所有的资料都是来源于网上学习和自我归纳总结，今后我会总结下我学习的对象。