胜博发登录 博发娱乐手机版 详解完美像素使用手册之设计与支出篇,设计师与程序员和睦相处的7个建议

详解完美像素使用手册之设计与支出篇,设计师与程序员和睦相处的7个建议



这本纪念碑谷团队出品的《完美像素使用手册》,有设计师说是她见过的最全面,最毫无保留,最生动有趣的界面设计指南,而且不止是设计,还包括和程序员的合作经验,AI、PS的操作小技巧等等。现在终于有中文版了,强烈建议收藏阅读。

原文译自:Medium

原文标题:7 things I wished designers did more of when working with
developers

原文作者:Valinda Chan

文章翻译:村长道哥

只要涉及到可视化编程,程序员和设计师之间就会出现矛盾。当谈及一些程序开发问题时双方就会产生分歧,尽管我们都知道在创建有效的应用程序时两个团队成员都很重要。设计师看到最初的设计版本与最终的版本不同时总会感到失望;而程序员则会抱怨说是设计师设计问题(有点鸡蛋里挑骨头)!

今天是第三章节:易用性篇

图片 1

许多冲突源于两者之间缺乏理解,这也是导致设计师/程序员产生分歧的原因。为了两者之间的和平,本文总结了一些经验教训,作为设计师/程序员不妨学习下,知己知彼,方能百战百胜。

设计与开发

设计师和开发人员之间的合作对于打造优秀的产品是至关重要的。每个公司对设计人员和开发人员都有着不同的组织架构。有些公司里这两个角色是在两个独立的团队之中。有些开发团队也可能会把开发人员分散到各个子团队中。例如,前端开发人员和后端开发人员可能就组成了两个小团队。而在有的公司中,设计师和开发人员可能在同一个团队中。但不管怎样,设计师和开发人员之间的协作对于项目的成功是至关重要的。

图片 2

对于发布一个产品来说,设计和开发一样重要。之前这两个过程是割裂的,但通常会产生一些不大理想的结果。所以之后就更强调团队协作了,也更重视怎样省时省力地完成,从设计到开发的过渡。

从开发的角度来看,我参与过设计过程,从启发设计到构建设计的全过程(包括我并不喜欢的活)。我也做过设计师,从头脑风暴到建立原型。因为两边的活我都做过,所以我想分享一些让设计师可以更好地与开发人员合作的建议。

设计师说:我们并不是有意为难

图片 3

1 从一开始就让程序员参与设计工作,并且要经常参与

我发现在启动会议和任务交接之外与设计师接触好处多多。参与到定义产品功能的讨论中,这让我有机会在不可挽回之前能够给出正确的输入规范。设计其实是共同创造,开发人员和其他人一样都是不可或缺的。如果是小团队的话,让开发团队的项目经理参与设计就足够了。项目经理会根据需求邀请其他团队的成员。参与感的确立对于建立良好的合作关系,以及优秀的产品是非常重要的。

我遇到过很多设计师和前端开发人员,他们都能胜任对方角色的任务。许多设计师能自己写代码,许多程序员也可以参与线框图、原型设计和视觉设计。

当设计师们拿不准的时候,我希望他们能够过来咨询我和我的团队成员。我们程序员并没有那么可怕好吗!有的设计师曾经向我咨询过其他项目中有关输入的问题,我在开发的同时也会去画
low-fi
的线框图。很多经验丰富的开发人员都有着大量的知识和有价值的见解。如果开发人员已经产品上投入了一定的时间,那他们就会提出一些你可能没有想到过的问题。

图片 4

如果四个月后发现某些功能涉及到了非必要的技术难题,或者某些功能与你期望的大相径庭,这就着实很难办了。从客户的角度来看,如果他或她已经签署了设计方案,但后来被告知不能完成,或者团队正在考虑另一种设计,这对团队来说是极其影响信誉的。

我们努力做好工作,我们并不是有意为难。

关键点(沟通)

2 事无巨细的标注

标注和文档能够帮助我确保不会遗漏任何东西,尤其是涉及到交互是如何工作时。你可以创建自己的专有注释,或者使用
Sketch Notebook
这样的工具。通过标注可以指定按钮在不同的状态下是什么样子,以及创建图表等等。

下面是当我拿到一个关于搜索结果列表的设计时脑中出现的一些问题:

* 我们是否会在当前结果列表下面动态加载相同数量的搜索结果?

* 在加载结果时,我们是否使用动画?

*
只剩最后一个搜索结果应该会发生什么?我可以去掉这个“加载更多”的按钮吗?

* 当加载结果时,使用spinner吗?

如果你是设计师的话,那么上面的一些问题对你来说可能是比较简单的。作为一名设计师,我有一种感同身受,那就是轻易地假设每个人都应该知道某件事该怎么做。如果我觉得有不确定的地方,我会试着去添加一些简短明确的标注。

如果我没有拿到任何标注,也没看到产品中已经存在类似的功能,而且设计师都没空的话,我就自己做主,或者与他人一起商量一下,这样我才可以推进工作。我会对自己说:“我希望这就是他们的意思,因为我就是这么做的!”接下来,我需要和一位设计师确认一下。然而,这些问题本来可以在标注中得到解答,我就不用花时间去确认或者做一些本可以避免的返工了。

在开发产品时,样式指南还可以帮助确保产品的一致性。然而,我的大多数团队成员都只会l撸起袖子开干,只有在需要的时候才会去看样式指南。

无论改动有多么小,都要确保标注反映了最终更改的内容细节,这样可以避免将来任何混乱的发生。

图片 5

设计师需要维护开发者们的声誉,在你们看来我们更喜欢形式功能,但事实并非如此。设计师努力尝试做出最适合的功能,以便这些功能都能被采用。

首要就是要沟通。

3 尽可能用原型而不是静态的线框图

有时候这么做是行不通的,但在可能的情况下尽量地创建原型或交互动画。原型和交互动画可以以最直接的方式向人们展示工作,这样误解的机会就会更小。如果你使用的是静态的线框图,那么请确保你做好第2点和第4点。

“如果一张图片价值1000个字,那么一个原型价值1000次会议。”

——Tom & David Kelley

越来越多的设计师开始注重用户体验(user-experience)而非平面设计。在进行设计之前了解用户需求这有一点对于设计师来非常重要。有时我们会尝试添加一些漂亮的图形,希望用户有更好的用户体验。

图片 6

4 给演练、提问和复审留出足够的时间

开放的沟通对于确保项目顺利进行非常重要。记住,每个人的思维方式都是不同的,对同一件事情的优先级也不同,所以沟通对于确保每个人都能达成共识是很重要的。即使设计师和开发人员在公司内部是处在不同的组织中,开放的交流也是可行的。一些和我共事过的程序员都讨厌打电话和开会,有的程序员最受不了网络延迟。找出适合每个人最好的沟通方式以及对你有帮助的工作方式。

图片 7

程序员说:我们并不想有意为难

关键点(合作)

5 根据需要调整流程

花时间主动来学习所使用的过程并适应这个过程。参加 sprint 的计划,在 JIRA
上面做记录,这样和你一起工作的每个人都可以知道正在开发的功能是什么。

当我们编写代码时,完成项目只是其中的一部分,应用程序会随着时间的改变而改变,我们要做的是确保这些变动能轻易地进行更改。我们需要编写代码来测试自动化测试框架。当程序员从设计师那请求修改产品时,无论是HTML格式、文件命名或者目录结构,所做的一切都是为了确保该产品在将来测试能够保持更佳地灵活性。

不要固执己见,要合作。如果需要开会讨论方案,那你也得把负责开发的人拉进来。不仅可以提供不同的视角,而且他们也知道什么样的设计在技术上可行。归根到底,每个人投入得更多,那设计出来的产品也会更好。

6 好好组织文件

作为一名程序员,我会通过电子邮件的附件获得一些图标文件,而有的人则通过带有文件地址的即时消息来获得这些文件。有时我不得不翻遍文件夹来寻找最新的图片文件。能不能让我们程序员更方便些!

当我拿到一个命名清晰并且组织良好的设计文件集时,我的开发工作就会变得更省时省力。以简单一致的方式来给文件命名和排序,并把这些文件集中存放在一起。当我和多个设计师一起工作,而他们每个人都有自己的命名方法时,这一点就变得特别重要了。

别担心,我们不会要求过多的灵活性。创建灵活性是非常珍贵的,我们懂得“YAGNI”适可而止的设计(这个原则简而言之为——只考虑和设计必须的功能,避免过度设计)。我们尽量避免这种情况。

图片 8

7 与开发人员进行用户调研并分享你的发现

图片 9

产品团队中的每个人都应该或多或少参与到调研的过程中。参与的形式可以是听电话录音和观看录像,或者是阅读文字记录。这看起来似乎是在浪费宝贵的工作时间,然而,参与了一些调研的过程可以帮助建立了对用户的理解。

即使作为一个开发人员,我认为和用户对正在开发的产品产生共鸣非常重要。这让我对需要先做什么以及为什么要做的理由有了一个全面的理解,进而产生出一种更强烈的参与感和创造感。

设计师说:形式问题影响功能

关键点(了解别人)

结论

共鸣、沟通和组织是实现团队愿景的关键因素。记住,设计是共同创造的工作。如果你越是觉得在和其他人一起打造一个产品——而不是仅仅你自己的设计——你和同事的关系以及最终产品的质量就会越好。请记住,每个人都有一个共同的目标,那就是打造一个优秀的产品,并且和你一样都想要达到这个目标。

“志同道合是成功的基础,保持团结才能不断发展,共同努力就会走向成功。“

—— 亨利∙福特

图片 10

形式不追随功能,形式可以赋予功能特征。程序员可以设计某些功能让你轻易获得所需。如果我们想要用户点击某个按钮或者执行某个动作,图形和布局就能帮助用户知道或者进行猜测如何获取他们想要的结果。

团队合作会让你更了解其他设计师的想法,或者你自己的设计弱点,这样才有机会修正。只有这样的心态,你才不需要总是问别人:我的设计行不行啊?行不行啊?因为你知道什么是可行的,或者更确信自己的选择,知道为什么得这么做。

经验告诉我们设计出一款特定的方式尤其适用于在线应用程序。即使是简单的设计包括按钮,表单或者照片选项,当作出选择时我们使用了明智的决策方法。通过位置、颜色以及视觉显示即可告诉设计师某人正在参与互动,但前提是你需要创建一个互动环境。

图片 11

举个例子,世界上首屈一指的品牌导航,下图是保时捷分层导航的屏幕截图。简洁、良好的结构设计功能可以使用户产生愉悦感!

关键点(现实一点)

图片 12

设计师和开发人员之间的绊脚石就是——最初设想和成型的APP长得不一样啊!然而团队合作可以完美解决这个问题。但是设计师也要务实一点,与其花时间纠结,不如把时间花在修改或者纠错上。设计得漂亮却很难用或者经常崩的APP你要它做甚?

程序员说:命名事宜

图片 13

当我们构建一个应用时有许多不同组件需要跟进。除了网页、图形、源代码文件、数据库列表、列还有许多其他组件需要管理。而一致的命名是我们的第一要务。

准备(规格)

当一个设计师在文件系统GUI中拖放文件时,如果该文件命名为submitButton.gif或submit-button.gif或许无法区分两者。我们从数据库领域到文件名到CSS类几乎所有都采用了标准命名。这就表示编码部门有了标准或者他们遵循了不成文的规则,有了一致的命名使工作更加轻松。

设计开始前,要先了解使用平台。屏幕大小、分辨率、屏幕能呈现多少颜色,或者影响交互、动画的因素。也要考虑程序能不能实现,比如说,可以用多大的字号呈现出效果怎样等等。

我们旨在让命名更加具有描述性和可预见性。相似的命名项目明显是某个命名的重要组成部分。比如名为submit1.gif和submit2.gif无需解释两张图片之间的差异,但submit-green.gif和submit-red.gif就不同了。

图片 14

设计师说:规则有助于我们了解

准备(能实现什么东西)

我们可以学习规则,但这只是有助于我们了解。规则我们可遵循也可不遵循。开发者有时会和我们讨论编程语言但我们并不理解,就如同设计师有时在讲开发你们也难以理解一样。一旦设计师和开发者都能理解了,最大的获益者便是用户。

有些规格的确定是要以程序能否做得出来为基准。格式用PNG,PSD还是矢量图?如果要用代码呈现,对颜色和效果是不是有限制?要不要用九宫格?这些信息一开始就掌握好,设计才能有的放矢。

上面提到使用文件命名的例子,只是想告诉我们应该遵循什么样的标准。我可以向你保证,如果我们知道了这是正确的方式,我们会以某种组图方式或者以小写字母方式命名,我们很乐意这么做。

图片 15

设计师本质上并不会反抗,因为大多数情况下非常喜欢程序员。我们喜欢做自己想做的事情,也没有人告诉我们应该怎么做,我们属于乐天派。

准备(工作流程)

设计师们在训练时就知道无需遵循条条框框,要有创新理念,但这并不是说要为难开发者工作。一旦设计师遵循了规则,那么她可以将创新凌驾于规则之上,而不会让功能更加困难。他们会因图片能否运用得当而起争论。

标签:, , , , , , , , , , , , , , , , ,

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图