还原"活"的设计 · kejun

"活"的设计(Living Design, 简称LD)

活相对于死。PRD是“死”的、设计稿是“死”的、规格说明是“死”的。实现一个“死”的东西毫无价值

还原设计，并不是还原设计稿！最终目标是实现一个活的产品

定义：LD是由有组织的UI元素构成，能适应不同的使用环境，响应用户的行为，灵活适配内容，可以扩展和继承的设计。

LD的基本特征: 1.组织性、2.扩展性、3.适配性、4.响应性。

还原LD的前提 - 做出转变

"不变则罔，不进则退"

1. 协作关系的转变：设计师和前端工程师关注点不同，为了同一个目标
2. 传统实现流程的转变：设计师非形而上
3. 传统设计实现理念的转变：迭代设计和系统设计

"可以说，转变是由问题倒逼而产生，又在不断解决问题中而深化" -- 习大大

打破传统的产品实现流程

1.产品目标 > 2.设计问题 > 3.构思模型 > 4.设计实现(IDxVD) > 5.代码实现 > 6.真实的产品

1. 交付物驱动
2. 沉浸在各自的专业圈子里，交集越来越小
3. 效率低，加人？人多不是协作，沦为劳动密集型，问题没解决导致恶性循环
4. 只对上面负责

改进：回到产品实现的根本目标上，产品实现的"黑盒"。

LD的实现思路(1) - 迭代设计

简而言之，围绕目标 • 边验证 • 边设计 • 边开发

迭代1：验证结构调整

迭代2：基于前面，强化视觉

如何让迭代转的更快？

LD的实现思路(2) - 系统设计

平面的？静态的？

有层次 x 有规律 x 有变化

系统设计(建立秩序，体现组织性)

例子:

如果简单按设计稿还原，会在开发最后阶段甚至上线后暴露出一些问题(有些时候可能颠覆设计)：

1. 大多数时候商品名会很长拆行
2. 真实图片的比例多样，现有缩略图的尺寸不符
3. 左边button有的是链接，有的带交互
4. 有些情况下没有评论内容
5. 时间显示规则：一小时内?一天内？一年内？

设计是设计某种秩序，秩序是总体和局部的构成

纵向解构，分开考虑元素的属性和行为：

轻松转化到Mobile版(RWD)

小结 - 面向设计师

提出一个观念："活"的设计(LD)

LD的概念和如何理解它

实现LD的前提: 建立协作关系，流程的转变，思路的转变

LD的实现思路：迭代设计和系统设计

还原LD - HOWTO

1. 设计师要有LD的设计思维(前面所讲)
2. 再造协作流程
3. LD背后的开发观念
4. 必备基础设施：组件化的静态文件管理系统
5. 超越传统响应式开发

还原LD - 再造协作流程

案例分析: A项目(项目名称不便透露)的协作过程。

1. PM写了一份简要的PRD，PM x Designer x Engineer Review
2. 确定M1的目标，M1定义了MVP，Engineer准备基础服务
3. 根据M1，Designer出Wireframe，PM x Designer Review
4. 根据Wireframe，FE x BE做出第1版原型。(有测试数据，无样式，尽可能少写JS/CSS，同步的流程)
5. 基于原型，VD x ID开始系统设计。分块递交。PM能看到“生长”过程
6. M1的开发着重架构设计，分层、分块实现
7. 不陷在某个复杂的设计实现里，前面所述的迭代设计
8. 阶梯式进展
9. 好的协作：多种角色间，不断抛出问题，解决问题的过程
   马赫的共同演化设计实现模型

LD背后的开发观念

前端工程师的"三观"依然是底蕴

1. (内容/样式/行为)三层分离
2. 渐进增强原则(Progressive Enhancement 1.0/2.0)
   
   (by Nicholas Zakas)
3. 优雅退化(Degrade with Grace) / 浏览器分级支持(GBS)

10+ years。依然有效，继续践行!

还原LD - 组件化的静态文件管理系统(1)

必备的基础设施。把"细胞"组织在一起，健康与否取决"新陈代谢"(后期维护)

组件化，不单纯是模块化

A项目(不便透露)中最复杂的部分......其实是一个"button"

<%include file="/widgets/btn_publish.html" args="gallery=gallery" />

<%block filter="collect_css">
/* 1. 依赖的CSS */ 
${istatic('/css/ui/overlay.css')|n}
${istatic('/css/mod_publish.css')|n}
${istatic('/css/tips.css')|n}
...
</%block>
<%block filter="collect_js">
// 2. 依赖的Javascript 
Do.ready(function() {
${istatic('/js/upload_pic.js')|n}
});
</%block>
<script type="text/template" id="tmpl-publish-picture">
// 3. 依赖的Javascript模板 
</script>
<!-- 4. HTML -->
% if request.user:
  % if not gallery.is_member(request.user):
<a href="#" class="btn a_show_tips">发图</a>
    ${self.tips('只有xxx才能发图。')}
  % else:
<a href="${url()}add_picture" class="btn btn-publish-picture">发图</a>
  % endif
% else:
<a href="${url()}add_picture" class="btn a_show_login">发图</a>
% endif

还原LD - 组件化的静态文件管理系统(2)

一个静态文件管理系统的"刚需"：

1. 实现组件化 (想想完整组件的含义)
2. 依赖管理
3. 自动打包
4. 部署方式
5. 支持CSS的预处理(SCSS/LESS/Stylus)
6. 包管理

还原LD - UI的组织性

CSS的结构化组织思想，参考OOCSS、SMACSS、BEM等。原则：取其精华，弃其糟粕。

A项目的CSS组织：兼容层 + 抽象UI层 + 组件层 ＋ 业务层

|-- libs.scss 基本的mixin库
|-- reset.scss 为这个应用订制的css reset(你会发现通用文件越来越难hold住全站，原则是拆解、定制)

|-- buttons.scss 通用UI元素－button
|-- font_icons.scss 通用UI元素－字体icon。适配性更强
|-- item.scss 通用UI元素－条目。
|-- progress_bar.css 通用UI元素－进度条
|-- tips.scss 通用UI元素－Tips
|-- list.scss 通用UI元素－列表
|-- layout_col2.scss 结构
|-- ui JS组件的样式文件
|   |-- overlay.scss
|   `-- tag_input.scss

|-- mod_create.scss 通用业务模块: mod_开头
|-- mod_edit_desc.scss
|-- mod_gallery_info.scss
|-- mod_gallery_intro.scss
|-- mod_gallery_list.scss
|-- mod_nav_list.scss
|-- mod_picture_list.scss
|-- mod_picture.scss
|-- mod_publish.scss
|-- mod_upload.scss
|-- member_list.scss 特定页面用到的业务代码
|-- user_profile_head.scss
`-- ui.scss 这个应用的全局css文件

还原LD - 针对用户的使用环境设计和开发

分析用户的使用环境：

1. 浏览器: 高端浏览器 > 低端浏览器

2. 操作系统: 设计师不能只看iMac里的效果

3. 屏幕分辨率: 转变成多元化

4. 移动端设备: iOS略高于Android，tablet略高于phone

还原LD - 响应式开发(1)

超越传统响应式开发

还原LD - 响应式设计

响应式设计(Responsive Web Design, WD)不仅仅局限于响应屏幕。本质上更好适应用户的使用环境。

比如：上传图片

设计图片上传

1. 多文件上传。如, 豆瓣广播的发图

高级feature: 原生MultipleUpload, DragDrop, Paste, 环形进度条

基本：SWFUpload + 基本UI

2. 单文件上传。A项目的发图

高级feature: 原生的单文件上传, 本地预览(ObjectURL), CSS3动画进度条

基本：iframe上传 + 基本UI