在这个行当,不做程序员也得懂技术 | KyXu Tech

2,181 阅读7分钟

先来捋一捋思路,关于各个岗位合作打造(移动端)产品的一点想法:

声明:
本人是程序员,截止到目前,我用的设计都是自己设计的,我用的产品策略都是自己的思考。
本人并非专业设计师或 PM,如果勘误,欢迎指正。
本文并非对设计师和 PM 的吐槽,但如果您觉得您作为设计师或 PM 或其他职业者被冒犯了,我只能说我并无此意,请您立刻关闭此页面。

为什么只有程序员是不够的


首先要消除一下歧义,我们见过无数的一人独挑大梁完爆数十人团队的例子,所以事实证明,只有一个程序员,某些时候是足够的。不够背后隐含的是,这个程序员做了很多非程序员岗位的事情,这种情况下其实相当于是一个 Product Creater 在做东西,他(她)不仅仅是程序员这么简单。

即便是在移动端出现之前,大家在 PC 上用软件,也是需要有人来做设计,有人来思考产品的。

用户完成一个操作,需要做几次操作,需要做什么样的操作,PC 上是鼠标左击、右击、滑动还是其他,移动端是滑动、点按、长按亦或重按。这个产品解决了什么样的问题,用什么方式解决的,其他产品解决了这个问题吗,它们是怎么解决的,你和它们相比有什么不同……这款产品有自己的设计风格吗,如果是依照平台的风格,那么有什么地方没遵循平台的规范吗,能不能先破再立,开创一个新的形态……

类似的问题太多太多,于是有了【程序员+设计师+PM】的模型。

最近想明白了一件事情:为什么身边好多人我明确地知道他们代码写的比我好,但是做不出好东西?

去年 8 月份我做了自己的第一款在 App Store 上架的 App,花了 12 天,2000 行 Swift。这个项目如果是现在做的话,从 0 到打包 ipa,两天以内,最多 800 行代码就可以搞定。然而就是这份臃肿不看、风格丑陋的代码,带领这个 App 杀进了 App Store 中国区付费榜 Top 50。

还有就是现在的编码能力相比从前有了十足的进步,面向协议编程、函数式编程也都有了了解,对可以重构的项目大刀阔斧地更改,改代码的时候心潮那叫一个澎湃啊,觉得自己写出了多么多么厉害的代码。等写完了,冷静一看,原来不过如此。代码是变了,App 表现起来和原来并没有什么区别,这种努力用户是看不见的。

所以逐渐开始认识到,代码和产品是多么割裂开的事情。当然好的程序员可以把这些事情想办法联系起来,融会贯通,知道什么样的 App 导航模式可能对应背后什么样的设计模式(举了个不好的例子)。但说到底这是完全不同的两件事。

如何做一个好的非程序员


做外包的经常觉得甲方很蠢、各种难沟通,所谓隔行如隔山,甲方或许会说出 “这个设计看着不大气啊” 或者 “我想做一个淘宝那样的网站,得多少钱” 这样的话,然后乙方就在内心嘲笑人家,但是身体上还要表现的无所谓,最终把钱搞到手。

但其实真的没必要这样,因为对方是来提出需求的,假如让我进入一个完全没有概念的领域,比如说挑选木材,我也只能说我想要像什么什么一样的木材,我叫不上名字的。所以甲方这样无可厚非。但同时我们也知道,一个好的甲方,我们可能希望他懂技术、懂设计、懂产品,和我们交流起来纵享丝滑。

程序员、设计师、PM 三方对接的时候,其实就是这么个甲乙方的关系,而理想状况下,这三方中的任何一方充当甲方的时候,都应该是一个可以进行无障碍对接的甲方。

比如说颜色,设计师眼里的颜色是这样的:
KUWAZOME
同样的东西在程序员眼里是这样的:

let kuwazomeColor = UIColor(red: 100/255, green: 54/255, blue: 60/255, alpha: 1)

那么好的设计师应该是以这样的方式把这个颜色传递给程序员的:

# 颜色
KUWAZOME: R 0.39 - G 0.21 - B 0.23

而不是:

KUWAZOME: #6B4449

作为设计师,你可以不会写代码,你可以不知道什么是 UIColor 什么是 CGColor 什么是 NSColor,但是你要知道用你的东西的人此时此刻是以 RGB 或 HSB 的方式用的,而不是 CSS HEX,这是非常基本的要求。再甚者你还应该知道你的程序员使用的 IDE 可能不会帮他补全 /255 这一内容,所以为了让他不再打出无数个 /255 ,你给他的值应该是 R: 0.39 而不是 R: 100

那么作为程序员,你应该能看得懂 #6B4449 是什么意思,并具有把它转换成 RGB 或 HSB 数值的能力,这样可以保证你在遇到了相对糟糕的设计师的时候,也能完成任务。

好的设计师应该把程序员培养成设计领域的废人,程序员指定图片名,设计师这边把相应图片导出,名称、尺寸分毫不差,并附带 1x、2x、3x 给 iOS,各种 dpi 给 Android。而程序员这边即便只拿到了 .psd 或 .sketch 文件也能把项目做完。

另外,无论是程序员、设计师还是 PM,都应该了解大家共同面对的这个平台,依然拿 iOS 举例。

UIAlertController

上面这个是 iOS 系统提供的控件 - UIAlertController,这个东西在程序员眼里表现起来是这样的:

let alert = UIAlertController(
    title: "A Short Title Is Best",
    message: "A message should be a short, complete sentence.",
    preferredStyle: UIAlertControllerStyle.ActionSheet)

alert.addAction(UIAlertAction(title: "Cancel",
    style: UIAlertActionStyle.Cancel,
    handler: nil))
alert.addAction(UIAlertAction(title: "Choice One",
    style: UIAlertActionStyle.Default,
    handler: nil))
alert.addAction(UIAlertAction(title: "Choice Two",
    style: UIAlertActionStyle.Default,
    handler: nil))

所以程序员此时需要的信息是:

# UIAlertController
title: "A Short Title Is Best"
message: "A message should be a short, complete sentence."
Action: "Cancel" - Cancel
Action: "Choice One" - Default
Action: "Choice Two" - Default

这样就足够了。当然你可以把上面那张图也做出来给程序员预览,防止出错,但是你要明白这个东西是 iOS 系统提供的,UIAlertController 是现成可调用的 API,你要做的是只是提供调用这个 API 需要的参数,而不是做一个一模一样的 UIAlertController,还把图片裁成 1x、2x、3x 以为这个东西是程序员手动做的。如果这个东西真的是程序员手动做的,那么显然你应该把 Cancel、Choice One、Choice Two 这三个东西分开提供图片资源,否则怎么可能会有三个可点击的地方?!

又或者说某个可点击控件被点击之后的效果,iOS 有自己的 Human Interface Guidelines,Android 有 Google 提供的 Material Design,你只要给 Button 提供里面的 Image 资源就可以了,告诉客户端开发的程序员阴影模糊几像素、向右偏移几像素、向下偏移几像素是极其不专业的行为。同样的,作为设计师,你可以不懂 UIButton 怎么创建,但是你要搞清楚 “iOS 里面的 Button” 或者 “Android 里面的 Button” 到底是什么,了解你的设计应该以怎么样的形式被融入到程序员的工作中,这才是设计,否则只是美工,更何况连图片资源都不能正常提供,连美工都算不上。

类似的例子太多太多了……

或许这篇文章的标题还可以改成:

  • 在这个行当,不做设计师也得懂设计
  • 在这个行当,不做产品经理也得懂产品

不想吐槽,只想分享一点自己的看法,我觉得真正的专业,不仅是把自己份内的事做好这么简单,因为常常和你合作的人并不能把他份内的事做好。