还原"活"的设计 · kejun

还原"活"的设计

=== Designer X Engineer
=== 核心价值

Kejun ( @kejunz )

Web 1.0 (02年某门户)

 >  网页制作

 >  展现&浏览

Web 2.0 (05年一拍/雅虎)

 >  前端工程师

 >  使用&体验

Mobile (09年豆瓣)

 >  前端工程师?

 >  ?


引自: http://redmonk.com/dberkholz/2013/12/16/the-year-developers-and-designers-collided/

前端工程师的基本职责:还原设计还原"活"的设计

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

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

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

LD vs. 生命体基本特征

  1. 体内平衡 ············ 这种自动调节指适配性。适配内容变化(文字长度、图片尺寸)、屏幕等各种情况
  2. 组织性  ············ UI可解构为UI元素的系统构成(如原子设计卡片设计)
  3. 新陈代谢 ············ 新的UI元素不断替代旧的元素。保持整体设计的活力
  4. 生长   ············ 从最小可用形态(MVP),跟随需求、不断迭代、持续完善
  5. 适应性  ············ 能适应用户的使用环境(如响应式设计)
  6. 反应性  ············ 能响应用户的各种操作,反馈各种状态
  7. 繁殖   ············ 基于现有的生态体系,快速孵化新产品

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

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

契约-交付式设计

  • 实现线框图
  • 定制
  • 多版本
  • 颠覆式
  • 串行
  • "外包"模式

LD

  • 实现产品目标
  • (从系统设计中)衍生
  • 单版本
  • 进化式(迭代)
  • 并行
  • 协作模式

还原LD的前提 - 做出转变

"不变则罔,不进则退"

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

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

打破传统的产品实现流程

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

PM
交付PRD
Designer
交付设计稿
FE
交付模板
BE
交付上线
User
  1. 交付物驱动
  2. 沉浸在各自的专业圈子里,交集越来越小
  3. 效率低,加人?人多不是协作,沦为劳动密集型,问题没解决导致恶性循环
  4. 只对上面负责

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

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

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

产品目标:提高发图量

迭代1:验证结构调整

迭代2:基于前面,强化视觉

如何让迭代转的更快?

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

平面的?静态的?
有层次 x 有规律 x 有变化
系统设计(建立秩序,体现组织性)

例子:

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

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

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

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

适配性的实现

4 + 5 + 6的对齐关系,垂直居中:

图片展现,截图:

轻松转化到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)
  3. 优雅退化(Degrade with Grace) / 浏览器分级支持(GBS)

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

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

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

组件化,不单纯是模块化

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

可简单部署到任何场景(page)下:
<%include file="/widgets/btn_publish.html" args="gallery=gallery" />
内部:完整的组件不单单是JS、CSS、HTML
<%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的结构化组织思想,参考OOCSSSMACSSBEM等。原则:取其精华,弃其糟粕。

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

兼容层x抽象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

制作东西,需要付出耐心和毅力,也在赋予物体以生命,可以说是一项崇高的工作,工作时更有触摸着实物而感受到活着的充实感。

- 安藤忠雄

谢 谢!

Q & A

Sorry! 暂不支持你的浏览器,请用Chrome打开...