标签： 设计

互联网 patron No comments

iOS平台的设计原则

iOS平台设计原则
美学正直 – Aesthetic Integrity（不但要设计感，还要匹配功能）
连贯一致 – Consistency
直接操控 – Direct Manipulation
显性反馈 – Feedback
联系隐喻 – Metaphors
用户控制 – User Control

了解详情：iOS Design Principles

UI设计注意事项
格式化内容（以适应屏幕显示） – Formatting Content
使用UI组件（让交互简单自然） – Touch Controls
按钮别太小（最小44ptx44pt） – Hit Targets
字体别太小（不要小于11pt） – Text Size
对比要明显（字体颜色和背景） – Contrast
间隔要足够（以提高易读性）- Spacing
使用高清图（以保证Retina）- High Resolution
图片别变形（要原比例裁切）- Distortion
组织好内容（要易读易操作）- Organization
元素要对齐（要关联要整齐）- Alignment

了解详情：UI Design Do’s and Don’ts

互联网 patron No comments

UCD七原则

1. 匹配用户模型（确保易理解）
2. 简化任务结构（确保易操作和用户控制）
3. 注重流程可视（确保会操作）
4. 建立正确匹配（确保不困惑：意图/行为；行为/结果；实际状态/感知状态；感知状态/意图）
5. 利用限制因素（确保路径明确）
6. 考虑人为差错（确保出错引导）
7. 将一切标准化（无法做到以上的话，确保用户学习一次后，可操作系统）

互联网 patron No comments

在Facebook工作学到的设计评审4要素

作者 Tanner 译 肇春来

评审是产品设计流程非常重要的一部分，无论你在团队中工作，还是独自工作。从正式的评审中，你可以获得反馈，跳出自我，做出更好决定，突破更多障碍，练就更强技艺。

确实，刚加入Facebook时我也担心，每周例行的两小时评审会浪费时间，而我们本可以把它用在设计工作上。因为在我之前的工作中，评审往往会陷入两个困境。

  • 团队成员太害怕被批评以至于不想展示他们正在做的东西。
  • 团队成员对评审没有清晰认识最后只是浪费时间辩论争吵。

我在Facebook的评审经验则有点不同，整个会议更多在基于事实的进行评议，而很少直接批评或对议程施加压力。

我们采用的很多评审方法来自Jared M. Spool的“Moving from Critical Review to Critique”。Spool关于评审的看法，让我深刻理解，是什么让评审值得做，特别是在Facebook工作后。所以现在，我开始拥抱这一理念，每周花几个小时进行评审，毋庸置疑，对每个参会人员都有价值。

我的团队在Facebook是这样进行设计评审的。

1. 设立明确角色

在评审中，每个人都有自己的角色，我们目前的角色有：报告人，聆听者，促成者。

报告人是分享工作的个人，他们的角色是：

  • 简洁描述正需要解决的问题（或正需要探寻的想法）。
  • 展示他们给的设计或内容解决方案。

报告人的工作不是展示PPT，或向大家证明自己的能力。每个报告人要提前一天花15-30分钟与评审促成者进行沟通（有时更多为促成者考虑）。

聆听者是不需要做工作展示的人，他们的角色是：

  • 理解问题所在，及前因后果。
  • 问大量问题。

聆听者最强有力的工具便是他们问的问题，以此或发现相关想法，或帮助引导决定。对解决特定预先知道的问题，问对问题比尝试直接找到答案更有效。比如，追问初始问题的范围，能帮助报告人（或团队）对问题分出轻重缓急，而询问确认刚刚的共识能使团队语言保持在一个理解水平下，同时也为团队推进了创意设计的决定。

促成者的工作是：

  • 为每次评审提前做好议程时间表（谁将报告什么内容，具体什么时间？）。
  • 确保参会的每个人都在议程上。
  • 在评审时做会议记录。
  • 询问报告人：“你将采取哪些关键步骤来向前推进工作”，并且记录回应。

促成者角色最重要的一个方面就是保证每个人的陈述都在自己的角色中。也就是说聆听者主要问问题，而报告人要在展示工作方案时，理清他们的目前的问题或挑战。

在我的团队，我们通常有固定的促成者来管理每周的评审会议。如果你没有合适的人来担当此任（比如产品经理，项目经理），其实参加会议的任何一人都可以充当促成者，当然，促成者人选也可以每周轮换。

 

2. 确保每个人理解并同意要解决的问题

在开始评审前，重申确认需要解决的问题非常重要。

讲明问题和来龙去脉（为什么这个问题或想法值得第一时间处理）将会帮助获得更有效的反馈。问题陈述格式可以这样：

  • 我正在展示【早期/中期/后期】阶段的工作。
  • 关于【这个问题】。
  • 因为【为什么它是问题】。
  • 我正在寻求反馈，关于【具体哪方面的】。

在评审中，报告人应该准确的说出他/她不关注哪些反馈，又关注哪些反馈。例如，“我不寻求项目细节审美方面的反馈，我需要的是如何通过动画过度让用户体验更有粘性”，问题陈述一旦确定，就要让每个人都充分理解它。报告人或促成者应该问整个参会人员下面的问题以确保问题完全明确。

  • 这个听起来是个有效的问题吧？
  • 问题陈述是否混乱令人困惑？
  • 还有什么可能被漏掉了吗？
  • 大家同意这个问题就是我们当前应该解决的？

一旦所有人都理解并同意问题陈述时，就该分享设计解决方案或探索了。

 

3. 关注反馈，而不是批评

知道有用反馈和无用批评的不同非常重要。

在Jared Spool的“什么让评审有价值”工作基础上，我的设计团队也从Judy Reeves那里获得许多关于评审的见解，他在一本书中分享了非常有价值的看法，“Writing Alone, Writing Together; A Guide for Writers and Writing Groups”。设计师Greg Lindley经常借用这本书向我们团队解释这个很好的观点。

  • 以问题形式提出想法，设计师不会防御性辩解，相反，会客观推理论证。如果没有想到这个特别的点，他们会记录下来，并体现在下次产品迭代中。

除了关注问题的反馈，我们还鼓励评审人员发现设计方案里好的点，并以此作为反馈的开始。比如，“我喜欢你处理这一部分设计的方式，你计划如何把这种方式应用到其他部分”。

为了确保反馈有用，我们需要知道什么样的反馈才算评审，而不是批评，Reeves给我们一个简单的叙述来判断二者的不同。

  • 批评做审判，评审提问题。
  • 批评找毛病，评审找机会。
  • 批评是主观的，评审是客观的。
  • 批评是模糊的，评审是具体的。
  • 批评在拆毁，评审在建立。
  • 批评以自我为中心，评审是利他的。
  • 批评是对抗的，评审是合作的。
  • 批评贬低设计，评审改善设计。

如果评审目标是为了推进设计解决方案，反馈就应该以探索性问题和引导性问题的形式提出，大家就应该抱着改善工作的目的和团队合作的态度，而不是批评报告人。

  • 评审不应服务于助长任何人的自负或私利。

Facebook还有一条评审规则值得提及……

 

4. 关闭手机和电脑

评审的要义是发现问题，孕育想法和发展团队，主要是问问题和听问题。如果不断地查看手机或电脑，你不可能完成评审目标。只有两种情况例外，其他的任何人都应该关闭手机和电脑。

  • 一是促成者可以打开电脑，因为他们需要为团队做会议记录。
  • 一是个人展示工作情况时，可以打开电脑。

总之，在评审中，下面这七个问题，可以拿来问你和你的团队。这些问题的答案将帮助你辨识评审，以使会议更有价值和效率。

  • 有既定的工作议程可以查看吗？
  • 有明确的角色分工吗？
  • 促成者有很好地让会议一直在议程上吗？
  • 报告人有明确地说明问题的范围吗？
  • 参加会议的每一个人都理解问题所在了吗，是否足够以针对性地提出问题？
  • 反馈是以问题的方式进行？还是批评的方式进行？
  • 整个评审是大家合作共同努力解决问题吗？

评审是团队合作，不是个人秀。当所有参会人员一起，基于共识，辨识机会，探索和推进合作项目时，评审才变的真正有价值。

 

原文链接：

https://medium.com/facebook-design/critique-is-an-important-part-of-any-design-process-whether-you-work-as-part-of-a-team-or-solo-ef3dcb299ce3