本篇内容笔者总结了工作中，通过接触不同设计岗位、技术岗位人员，了解和学习掌握的相关设计与技术知识，以及沟通交流的经验与技巧，希望能对各位有所帮助！ 笔者结合工作中与UI设计师、交互设计师等合作的经验与，分享一些与之友好、高效协作，并提高对你认可度的“诀窍”。 以上做到，不仅能使你在产品设计时更具审美高度，人机交互意识；同时也会让你在与UI设计师和交互设计师等进行沟通时，如鱼得水，如虎添翼，容易得到较高的认可与信任！ 每个行业都有相应的行业理论知识，UI设计和交互设计都有相应的设计理论知识，这些知识是作为产品设计人员的你&我应该了解的。 不仅能帮助我们在思考产品时有的放矢，更能帮助我们同设计同事达成一致，更好、更快的推进产品进程。 现在信息通达，资源丰富，有很多的书籍和网站可以学习和了解以上设计理论知识，在此列举一些笔者读过的相关书籍和常用的设计网站资源： 平面/界面设计书籍：《标志设计》、《色彩设计》、《字体设计》、《Gridsystems平面设计中的网格设计》、《品牌至上》、《西文字体》、《写给大家看的设计书》、《写给大家看的设计书》等 交互设计书籍：《触动：设计优秀的iphone应用》、《点石成金：访客至上的网页设计秘笈》、《方寸指尖：移动设计实战手册》、《在你身边，为你设计》、《用户体验要素》、《设计心理学》、《瞬间之美》、《锦绣蓝图》、《AboutFace3交互设计精髓》、《UCD火花集》、《交互设计沉思录》、《情设计》、《简约至上》、《赢在用户》等 设计网站资源：Dribbble、Behance、站酷、UI中国、花瓣、Iconfont、千图网、昵图网、海洛创意等 能够帮助自己在做产品设计的时候，从无到有的整个进程中，都能够做好设计层面的把控；从界面到交互，都有自己基于理论知识的理解与思考。 产品设计人员交付的原型或者是在与不同阶段的设计同事进行沟通时，都能够站在专业的角度，与之平等交流。 为什么会这样设计，大到整个产品，小到一个控件，都能够道出相应的缘由和设计依据。有足够的理论知识支撑，将会更加让人信服，而不会给人一种臆想般的自嗨感。 3）与平面设计同事（有的公司没有单独的平面设计岗位，由UI设计兼任）交流时，主要是关于产品logo设计，产品相关宣传册设计，宣传海报设计等 色彩搭配和谐，贴合产品定位和行业属性，是需要图形logo，图文结合型，还是文字logo；交流宣传册设计时，可以提出对封面（首页）设计，版式，主题色选取，内容页排版风格，图文搭配比例等的思考；宣传海报的设计，清楚不同场合的尺寸要求，风格和版式等有较为明确的需求。 如果你能够了解web端和移动端以及其它硬件终端的UI设计理论知识，那么你和设计的沟通效率，执行效果都将会提高很多。 比如：对于web端的UI设计，你能够对web页面的配色、不同字体大小、不同网站布局风格、网格系统理论、格式塔原理等都有所了解；并结合自己对产品的理解，有一定的设计思。 对于移动端的UI设计，不同端的字体设计单位、模块间的间距规律、按钮大小、行间距、元素间距等、闪屏页、广告banner、网格系统、格式塔原理等设计知识有所了解。 如果你能够了解web端和移动端的UI设计理论知识，那么你和设计的沟通效率，执行效果都将会提高很多。 页面的滚动方式、模块的滚动方式、按钮的默认、悬浮、点击的不同状态、控件点击后的反馈形式（弹窗、Toast、定位、新页面等）的设计，产品设计人员需要有一定的了解；对于移动端的交互设计，是基于用户手指的滑动、点击、长按等操作。 页面的滑动，模块的切换方式，按钮的不同状态（默认、点击、长按、禁用等），控件点击后的反馈形式（弹窗、Toast、定位、新页面等）的设计，产品设计人员需要有一定的了解。 同产品设计岗位一样，各个设计岗位也有对应的需要产出的设计交付件。笔者准备阐述的不仅仅是结果性的交付件，也包括与设计合作过程中，一些过程性的交付件。 四川挖出50米大蟒蛇 UI设计师根据产品设计人员提供的原型图，进一步美化设计的文件，包括配色、布局、控件、弹窗、banner以及不同内容字号的设计等内容。 作为产品设计人员，你需要熟悉这些元素，并能够同自己在设计的原型文件时进行的表现层的思考结合，分析出UI设计师产出的视觉稿交付件是否达到预期，是否有超出预期的地方。 这些判断能力都是必要的（UI设计师需要配合输出视觉设计规范，产品设计人员可以就此文件与设计人员进行深入探讨）。 UE设计师（用户体验/交互设计师）会根据产品设计人员提供的原型图和需求文档进行交互设计（也有可能产品人员兼任交互设计的情况）。 包括页面间跳转、跳转方式、跳转等待期间的动效设计；跳转失败的提醒设计、页面滚动或滑动形式、弹窗动效；页面加载动效、控件点击动效等。 比如：一张图点击后，放大查看的动效，虽然都是点击后放大的样式；但是实际上，UE在设计的时候，花的心思往往是你不易察觉的。 你需要同交互探讨动效组成部分，每个部分的意义，运动曲线是怎样设计的，缓进缓出各自所用时间等；甚至自己能够在结合理论知识的基础上，通过动效网站，动效设计软件进行效果模拟，同UE深入交流。 从图标样式是否符合产品主题、风格是否统一、图标形式是面型还是线型，以及不同终端图标的输出格式（移动端一般需要五种不同倍数的图标用于适配）。作为产品人员，对这些的要求和评估都需要足够熟悉。 点9图是一种移动端设计中比较特殊的产出文件（研发人员也有点9图制作工具），一般用在需要元素纵向或横向拉伸不变形的情况下，比如：非规整的聊天框，随着字数的增多会拉长或拉宽，如果不做成点9图，那么就会造成变形、边缘模糊等。 各端都有属于对应的设计规范，该设计规范交付件一般会由UI设计师产出，产品设计人员能够熟悉这些规范，对协作和评估规范严谨性是大有裨益的。 根据不同终端属性，可以分为web端UI设计规范和移动端UI设计规范等，而设计规范一般需要包含： 所使用文字的颜色，不同的应用场景应该搭配相应的颜色、一级标题、二级标题、内容、提示、备注等； 所使用文字的字号（大小），不同的应用场景应该搭配相应的字号、一级标题、二级标题、内容、提示、备注等； 所使用的icon设计规范、不同的应用场景、ICON的不同用色、是面型还是线型，都需要相对统一、成体系； 包括滚动，滑动（上下/左右等），点击反馈，弹窗动效等的交互设计，同一场景的交互样式，需要保持统一。 产品的idea或者用户的需求能够实现，都依赖于技术的实现。没有技术，idea就是空中楼阁，更谈不上后期的运营等等；从技术的重要性，我们也能体会到，懂技术是多么重要且必要的一件事情。 产品在工作过程中，要将idea、需求等落地到技术实现，就必定要同不同终端的技术人员协作，这其中包括：前端研发人员、后端研发人员、数据库设计人员、算法工程师、数据工程师、运维人员、架构师等。 需要协作的技术人员越多，你需要了解、学习、掌握的相关技术知识也就越多，笔者结合工作中与以上这些技术工程师们合作的经验与，分享一些作为产品工作者，应该掌握的技术知识。 以上做到，不仅能使你在产品设计时，思维发散的同时，兼具技术实现视角考虑问题；在面对领导或客户对于技术实现或工期预估的疑问时，能够结合团队技术实力，给出具有可行性、可靠性的方案. 同时也会让你在与各端研发工程师进行沟通时，不仅能从产品设计角度把控方案，更能从技术实现方式、方案等方面进行深入探讨；包括技术方案的可行性，对有实现难度的地方能够评估是否可突破和采取备选方案等！ 各端技术都有自己的开发语言、框架、工具等，这些开发语言、框架、工具就像是工程师手中的刀与剑，助他们攻城略地。 以上列举的这些技术相关知识（并未完全列出），并不是要求产品人员做到能够像研发人员那样，通过编译器进行实际性的编码工作。而是希望能够对这些知识有所了解，知道是用来做什么的、解决什么问题；最好是能够看懂简单的代码，熟悉一些语言和工具。 1）有些web前端代码，通过F12调试工具，可以自行进行简单的代码调试和代码查看、理解，甚至分析出现的问题，即使看不懂，也可以反馈给研发人员定位分析； 2）有些后端代码设计逻辑，你能够做到通过查看研发人员编译器里的源码，同研发人员一起分析在产品设计层面的思，落地到研发实现环节出现不一致的地方，定位问题，进行修正； 能够通过编写常用的sql语句进行数据查询与分析（复杂的也能够通过渠道快速解决），比如：一些简单的数据统计，用户总人数，日活跃/月活跃人数等。 虽然现在可以通过第三发数据统计平台、自建统计系统等方式实现各类数据的统计与分析。但是从数据库层面直接获取数据信息的能力是一项不错的能力，尤其是产品初期这些现成的可视化分析平台都没有接入或建成的时候。 比如在决定是选择Mysql数据库还是Sqllite数据库的时候，就能够同研发人员一起结合实际情况进行评估。 Sqllite数据库对于小数据量的数据处理效率较高，但因为是单线程处理方式，数据量较大时处理效率降低明显，远不如Mysql数据库的多线）了解大数据量、高并发场景下数据处理技术； 比如消息处理，Kafka就是一种高吞吐量的分布式发布订阅消息系统，其在大数据研发应用上的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。 5）了解git和svn的差异，git是分布式的版本控制系统，是按元数据方式进行存储，现在很多互联网公司的研发团队都是采用git进行版本控制。 svn是集中式的版本控制系统，是按文件方式存储，分支也与git不同，现在也有不少企业使用svn做版本控制，也包括团队内部文档版本集中管理。 现在信息通达，资源丰富，有很多渠道可以学习和了解以上各端技术相关知识，在此列举一些笔者常用的技术网站资源（读过的书籍就不列举了，各位可针对不同的语言查询相关书籍学习）： 在实际工作中，遇到一些在与研发人员交流沟通过程中新的知识点或者技术问题，可以默默记下来，通过这些网站查找相关技术帖子，获取相关知识；既能增加自身的技术知识储备，也能不断拓宽和加深与技术交流的内容广度和深度（全面和细节）。 产品岗位需要接触很多不同终端的研发人员，与之交流，这些交流可能是发生在不同的场景下：比如技术选型、技术方案探讨、技术实现与产品设计有出入时、技术复盘、技术分享等情况下。 同下围棋一样，再复杂多变的棋局也有它的一些套，围棋里称为“定式”。笔者将之沿用到与技术交流的过程中，也有一些作为产品人员，在交流之前就能考虑到的一些“交流定式”。 当出现技术实现逻辑问题时，我们可以向技术反馈该问题，并提出问题是否出在代码实现的逻辑有误的想法，帮助技术快速定位问题； 当输入内容校验有误时，我们可以推测出现问题的原因可能是校验规则有误或不完善，甚至是正则判断待优化等引起，可以提供给技术人员相关思； 学会借势是工作中不可或缺的能力，此处仅分享与研发人员交流时如何借势，借势即高手的“势”来帮助自己解决问题。 有些时候，我们在与研发人员交流过程中，难免碰到“硬茬子”，不全是指研发人员，更多时候是指问题棘手的情况，自己所理解的那点技术知识完全cover不了对方；这个时候为了打破僵局，你得学会找到能够解决该问题的人，可能是项目经理，技术Leader等。 但是到底谁能解决，就看你平时对他们技术能力和涉及领域的了解程度和关系处得怎么样了，这些在这种关键时候都是派上大用途的！ 工作中不是所有问题都能在第一时间给出解决方案的，很多时候都需要经过之后的深思熟虑，多番探讨后才有结果。 与研发人员沟通不外如是，不管是在正式会议，还是在针对性解决问题的时候；遇到讨论后，短时间给不了解决方案的情况，一定要能够及时跳出来，脱离“死锁状况”，资源，将该问题纳入后续待解决的“池子”。 别认为自己对相关技术知识有所了解，就将重心倾斜到技术向。这样做不仅会让共事的研发反感，认为你在他专业领域插手太多，指指点点，也会让你在做产品思考时，不自觉的被团队技术能力所。 所以，把握好分寸更为关键、重要。毕竟了解技术知识是为了帮助我们更好的做好产品，和研发更好的共事服务的。这些都需要在实际工作中，大家灵活应对。 总而言之，就是希望各位能够多迈出一步，去了解对方行业相关知识，提高工作效率的同事，提升协作双方的满意度。 ①本网所有内容均来自互联网或网友，目的在于传递更多信息，并不代表本网赞同其观点或其内容的真实性，不承担此类作品侵权行为的直接责任及连带责任。其他、网站或个人从本网转载时，必须保留本网注明的作品来源，并自负版权等法律责任。 ②如相关内容涉及版权等问题，请在作品发表之日起一周内与本网联系，我们将在您联系我们之后24小时内予以删除，否则视为放弃相关，读者热线 。
|