你不应该错过的技术&设计知识点

本篇内容笔者总结了工作中，通过接触不同设计岗位、技术岗位人员，了解和学习掌握的相关设计与技术知识，以及沟通交流的经验与技巧，希望能对各位有所帮助！

一、设计知识点

1. 概要

作为产品工作者，与设计师协作，是产品建设过程中必不可少的一环。

笔者结合工作中与UI设计师、交互设计师等合作的经验与感悟，分享一些与之友好、高效协作，并提高对你认可度的“诀窍”。

2. 笔者的“诀窍”

1. 了解设计理论知识；
2. 熟悉设计的交付件；
3. 掌握各端设计规范。

以上做到，不仅能使你在产品设计时更具审美高度，人机交互意识；同时也会让你在与UI设计师和交互设计师等进行沟通时，如鱼得水，如虎添翼，容易得到较高的认可与信任！

3. 了解设计理论知识

每个行业都有相应的行业理论知识，UI设计和交互设计都有相应的设计理论知识，这些知识是作为产品设计人员的你&我应该了解的。

不仅能帮助我们在思考产品时有的放矢，更能帮助我们同设计同事达成一致，更好、更快的推进产品进程。

那么，都有哪些作为产品设计人员需要了解的设计理论知识呢？

笔者总结如下：

1. 平面设计理论知识：logo（标志）设计、配色设计、字体设计、图文布局设计等；
2. 界面设计理论知识：web端设计、移动端设计等；
3. 交互设计理论知识：web端交互、移动端交互等。

现在信息通达，资源丰富，有很多的书籍和网站可以学习和了解以上设计理论知识，在此列举一些笔者读过的相关书籍和常用的设计网站资源：

1. 平面/界面设计书籍：《标志设计》、《色彩设计》、《字体设计》、《Grid systems 平面设计中的网格设计》、《品牌至上》、《西文字体》、《写给大家看的设计书》、《写给大家看的设计书》等
2. 交互设计书籍：《触动人心：设计优秀的iphone应用》、《点石成金：访客至上的网页设计秘笈》、《方寸指尖：移动设计实战手册》、《在你身边，为你设计》、《用户体验要素》、《设计心理学》、《瞬间之美》、《锦绣蓝图》、《About Face3 交互设计精髓》、《UCD火花集》、《交互设计沉思录》、《情感化设计》、《简约至上》、《赢在用户》等
3. 设计网站资源：Dribbble、Behance、站酷、UI中国、花瓣、Iconfont、千图网、昵图网、海洛创意等

通过了解这些知识，在实际工作中，能给我们产品工作者带来哪些帮助呢，笔者总结如下：

1）建立一套相对丰富的、成体系的设计理论知识

能够帮助自己在做产品设计的时候，从无到有的整个进程中，都能够做好设计层面的把控；从界面到交互，都有自己基于理论知识的理解与思考。

这样保证设计的产品是有理论支撑的，首先能够让自己信服。

2）增加信任感

产品设计人员交付的原型或者是在与不同阶段的设计同事进行沟通时，都能够站在专业的角度，与之平等交流。

比如：产品人员交付的原型、界面间的链接逻辑、功能间的跳转等交互、界面的基本布局等。

为什么会这样设计，大到整个产品，小到一个控件，都能够道出相应的缘由和设计依据。有足够的理论知识支撑，将会更加让人信服，而不会给人一种臆想般的自嗨感。

3）与平面设计同事（有的公司没有单独的平面设计岗位，由UI设计兼任）交流时，主要是关于产品logo设计，产品相关宣传册设计，宣传海报设计等

如果你了解平面设计的一些理论知识，那么你在和对方交流时，就不会信息不对等，显得不专业。

比如：交流logo设计时，可以提出一些设计参考。

参考的依据可以是：

色彩搭配和谐，贴合产品定位和行业属性，是需要图形logo，图文结合型，还是文字logo；交流宣传册设计时，可以提出对封面（首页）设计，版式，主题色选取，内容页排版风格，图文搭配比例等的思考；宣传海报的设计，清楚不同场合的尺寸要求，风格和版式等有较为明确的需求。

当然能够引导设计师发挥能力，创作出超出预期的作品，也是需要基于设计理论探讨出来的。

4）与UI设计同事交流时，主要是关于产品界面配色，界面布局等

如果你能够了解web端和移动端以及其它硬件终端的UI设计理论知识，那么你和设计的沟通效率，执行效果都将会提高很多。

比如：对于web端的UI设计，你能够对web页面的配色、不同字体大小、不同网站布局风格、网格系统理论、格式塔原理等都有所了解；并结合自己对产品的理解，有一定的设计思路。

对于移动端的UI设计，不同端的字体设计单位、模块间的间距规律、按钮大小、行间距、元素间距等、闪屏页、广告banner、网格系统、格式塔原理等设计知识有所了解。

5）与交互设计同事交流时，主要是关于产品界面间的交互逻辑，控件间的交互逻辑等

如果你能够了解web端和移动端的UI设计理论知识，那么你和设计的沟通效率，执行效果都将会提高很多。

比如：对于web端的交互设计，是基于鼠标的点击、滚动等操作。

页面的滚动方式、模块的滚动方式、按钮的默认、悬浮、点击的不同状态、控件点击后的反馈形式（弹窗、Toast、定位、新页面等）的设计，产品设计人员需要有一定的了解；对于移动端的交互设计，是基于用户手指的滑动、点击、长按等操作。

页面的滑动，模块的切换方式，按钮的不同状态（默认、点击、长按、禁用等），控件点击后的反馈形式（弹窗、Toast、定位、新页面等）的设计，产品设计人员需要有一定的了解。

4. 熟悉设计的交付件

同产品设计岗位一样，各个设计岗位也有对应的需要产出的设计交付件。笔者准备阐述的不仅仅是结果性的交付件，也包括与设计合作过程中，一些过程性的交付件。

对此，笔者总结如下：

1）结果性交付件

UI设计视觉稿。

UI设计师根据产品设计人员提供的原型图，进一步美化设计的文件，包括配色、布局、控件、弹窗、banner以及不同内容字号的设计等内容。

作为产品设计人员，你需要熟悉这些元素，并能够同自己在设计的原型文件时进行的表现层的思考结合，分析出UI设计师产出的视觉稿交付件是否达到预期，是否有超出预期的地方。

这些判断能力都是必要的（UI设计师需要配合输出视觉设计规范，产品设计人员可以就此文件与设计人员进行深入探讨）。

2）结果性交付件

交互设计稿。

UE设计师（用户体验/交互设计师）会根据产品设计人员提供的原型图和需求文档进行交互设计（也有可能产品人员兼任交互设计的情况）。

包括页面间跳转、跳转方式、跳转等待期间的动效设计；跳转失败的提醒设计、页面滚动或滑动形式、弹窗动效；页面加载动效、控件点击动效等。

这一系列的动效设计，除了看其表象（呈现样式），还需要深入了解实现方式和具体参数。

比如：一张图点击后，放大查看的动效，虽然都是点击后放大的样式；但是实际上，UE在设计的时候，花的心思往往是你不易察觉的。

同样是点击放大查看效果，不同的动效节奏和运动曲线，造成的细节体验区别会是很明显的。

你需要同交互探讨动效组成部分，每个部分的意义，运动曲线是怎样设计的，缓进缓出各自所用时间等；甚至自己能够在结合理论知识的基础上，通过动效网站，动效设计软件进行效果模拟，同UE深入交流。

3）过程性交付件

图标资源。

不管是web端还是移动端，图标资源都是必须产出的。

从图标样式是否符合产品主题、风格是否统一、图标形式是面型还是线型，以及不同终端图标的输出格式（移动端一般需要五种不同倍数的图标用于适配）。作为产品人员，对这些的要求和评估都需要足够熟悉。

4）过程性交付件

点9图。

点9图是一种移动端设计中比较特殊的产出文件（研发人员也有点9图制作工具），一般用在需要保证元素纵向或横向拉伸不变形的情况下，比如：非规整的聊天框，随着字数的增多会拉长或拉宽，如果不做成点9图，那么就会造成变形、边缘模糊等。

所以掌握点9图知识，知道怎么制作点9图，或者自己会制作点9图，也是不错的技能。

5. 掌握各端设计规范

各端都有属于对应的设计规范，该设计规范交付件一般会由UI设计师产出，产品设计人员能够熟悉这些规范，对协作和评估规范严谨性是大有裨益的。

根据不同终端属性，可以分为web端UI设计规范和移动端UI设计规范等，而设计规范一般需要包含：

1）色彩设计规范

所使用的色彩种类，主色与辅色的搭配；

2）文字用色规范

所使用文字的颜色，不同的应用场景应该搭配相应的颜色、一级标题、二级标题、内容、提示、备注等；

3）文字字号规范

所使用文字的字号（大小），不同的应用场景应该搭配相应的字号、一级标题、二级标题、内容、提示、备注等；

4）ICON（图标）规范

所使用的icon设计规范、不同的应用场景、ICON的不同用色、是面型还是线型，都需要相对统一、成体系；

5）控件设计规范

包括输入框、按钮、滑杆、页卡、开关等控件，同一类型的控件，需要统一设计规范，形成一套体系；

6）间距设计规范

不同页面，同类型间距的尺寸需要统一，符合规律；

7）交互设计规范

包括滚动，滑动（上下/左右等），点击反馈，弹窗动效等的交互设计，同一场景的交互样式，需要保持统一。

二、技术知识点

1. 概要

时至今日，作为产品工作者，如果还在疑问产品需要不要懂技术？

那么笔者可以肯定的答复你：需要！

为什么？

产品的idea或者用户的需求能够实现，都依赖于技术的实现。没有技术，idea就是空中楼阁，更谈不上后期的运营等等；从技术的重要性，我们也能体会到，懂技术是多么重要且必要的一件事情。

产品在工作过程中，要将idea、需求等落地到技术实现，就必定要同不同终端的技术人员协作，这其中包括：前端研发人员、后端研发人员、数据库设计人员、算法工程师、数据工程师、运维人员、架构师等。

需要协作的技术人员越多，你需要了解、学习、掌握的相关技术知识也就越多，笔者结合工作中与以上这些技术工程师们合作的经验与感悟，分享一些作为产品工作者，应该掌握的技术知识。

2. 笔者的理解

1）了解相关技术知识

2）总结技术交流思路

3）“越俎代庖”不可取

以上做到，不仅能使你在产品设计时，思维发散的同时，兼具技术实现视角考虑问题；在面对领导或客户对于技术实现或工期预估的疑问时，能够结合团队技术实力，给出具有可行性、可靠性的方案.

同时也会让你在与各端研发工程师进行沟通时，不仅能从产品设计角度把控方案，更能从技术实现方式、方案等方面进行深入探讨；包括技术方案的可行性，对有实现难度的地方能够评估是否可突破和采取备选方案等！

3. 了解相关技术知识

各端技术都有自己的开发语言、框架、工具等，这些开发语言、框架、工具就像是工程师手中的刀与剑，助他们攻城略地。

工作中，笔者接触到的各端工程师及其相关技术知识有：

• web前端技术知识：开发语言（Html、Css、Js、Ajax、js等），技术框架（jQuery、Bootstrap、Vue、nodeJs等），开发工具（IDEA、Webstorm、Sublime、记事本等等）；
• 客户端技术知识：开发语言（C#、C++等），技术框架（WPF），开发工具（Visual Studio）；
• Android端技术知识：开发语言（java），开发工具（Android Studio）；
• Ios端技术知识：开发语言（Objective-C、Swift），开发工具（Xcode）；
• 后端技术知识：开发语言（PHP、Java、Shell、go、sql等），数据库（Mysql、Sqllite、Postgres、Redis等），技术框架（Mybatis、Springboot等），开发工具（IDEA、eclipse、Maven、gradle等）；
• 大数据技术知识：Hadoop、Hive、ZooKeeper、HBase、Kafka、Scala、Azkaban、Python、Docker等；
• 其他技术知识：接口调试（postman）、CI/CD（jenkins、gitLab）、虚拟机（VmWare）、Markdown、GitHub（代码托管服务平台）、码云（云端软件研发协作平台）、Linux、git/svn。

以上列举的这些技术相关知识（并未完全列出），并不是要求产品人员做到能够像研发人员那样，通过编译器进行实际性的编码工作。而是希望能够对这些知识有所了解，知道是用来做什么的、解决什么问题；最好是能够看懂简单的代码，熟悉一些语言和工具。

比如：

1）有些web前端代码，通过F12调试工具，可以自行进行简单的代码调试和代码查看、理解，甚至分析出现的问题，即使看不懂，也可以反馈给研发人员定位分析；

2）有些后端代码设计逻辑，你能够做到通过查看研发人员编译器里的源码，同研发人员一起分析在产品设计层面的思路，落地到研发实现环节出现不一致的地方，定位问题，进行修正；

能够通过编写常用的sql语句进行数据查询与分析（复杂的也能够通过渠道快速解决），比如：一些简单的数据统计，用户总人数，日活跃/月活跃人数等。

虽然现在可以通过第三发数据统计平台、自建统计系统等方式实现各类数据的统计与分析。但是从数据库层面直接获取数据信息的能力是一项不错的能力，尤其是产品初期这些现成的可视化分析平台都没有接入或建成的时候。

3）了解一些语言之间的差异性，在做技术选型、技术评估的时候，能够知其然也知其所以然；

比如在决定是选择Mysql数据库还是Sqllite数据库的时候，就能够同研发人员一起结合实际情况进行评估。

Sqllite数据库对于小数据量的数据处理效率较高，但因为是单线程处理方式，数据量较大时处理效率降低明显，远不如Mysql数据库的多线程处理效率。

4）了解大数据量、高并发场景下数据处理技术；

比如消息处理，Kafka就是一种高吞吐量的分布式发布订阅消息系统，其在大数据研发应用上的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

5）了解git和svn的差异，git是分布式的版本控制系统，是按元数据方式进行存储，现在很多互联网公司的研发团队都是采用git进行版本控制。

svn是集中式的版本控制系统，是按文件方式存储，分支也与git不同，现在也有不少企业使用svn做版本控制，也包括团队内部文档版本集中管理。

当然，需要了解的技术知识远远不止笔者上面提到的这些，以上仅仅只是举例说明而已。

那么，我们能够通过哪些渠道去获取相关的技术知识呢？

现在信息通达，资源丰富，有很多渠道可以学习和了解以上各端技术相关知识，在此列举一些笔者常用的技术网站资源（读过的书籍就不列举了，各位可针对不同的语言查询相关书籍学习）：

1. 学习类网站：w3cschool、菜鸟教程、慕课网等；
2. 工具/资料类网站：掘金、StackOverFlow、知乎、博客园、CSDN、V2EX、开源中国等。

通过这些网站，你可以快速、系统化的了解一门语言及其相关应用的基本知识和最新发展动向。

在实际工作中，遇到一些在与研发人员交流沟通过程中新的知识点或者技术问题，可以默默记下来，通过这些网站查找相关技术帖子，获取相关知识；既能增加自身的技术知识储备，也能不断拓宽和加深与技术交流的内容广度和深度（全面和细节）。

透过这些技术帖子，了解技术前沿知识，扩充技术视野的同时，跟进研发人员技术触角。

三、总结技术交流思路

产品岗位需要接触很多不同终端的研发人员，与之交流，这些交流可能是发生在不同的场景下：比如技术选型、技术方案探讨、技术实现与产品设计有出入时、技术复盘、技术分享等情况下。

这些交流思路看似零散，实则有其相关性，每个人的理解可以能不一样，总结的思路或许也有所出入。

此处笔者仅分享个人的理解，总结如下：

1. 牢记“交流定式”

同下围棋一样，再复杂多变的棋局也有它的一些套路，围棋里称为“定式”。笔者将之沿用到与技术交流的过程中，也有一些作为产品人员，在交流之前就能考虑到的一些“交流定式”。

这些“定式”包括针对类似问题的解决思路，以及对于出现的问题能够做的相关思考部分。

比如：

当出现技术实现逻辑问题时，我们可以向技术反馈该问题，并提出问题是否出在代码实现的逻辑有误的想法，帮助技术快速定位问题；

当输入内容校验有误时，我们可以推测出现问题的原因可能是校验规则有误或不完善，甚至是正则判断待优化等引起，可以提供给技术人员相关思路；

当每次加载页面资源都需要等待逐一加载完成时，可推测技术实现没有利用缓存机制或异步加载机制；

登录访问失败时，如果不是网络问题，可推测是否接口挂掉或是后台服务器出了问题；

页面加载信息资源，没有数据返回，可推测是该数据请求接口出了问题等。

2. 找准“高手助阵”

学会借势是工作中不可或缺的能力，此处仅分享与研发人员交流时如何借势，借势即假借高手的“势”来帮助自己解决问题。

有些时候，我们在与研发人员交流过程中，难免碰到“硬茬子”，不全是指研发人员，更多时候是指问题棘手的情况，自己所理解的那点技术知识完全cover不了对方；这个时候为了打破僵局，你得学会找到能够解决该问题的人，可能是项目经理，技术Leader等。

但是到底谁能解决，就看你平时对他们技术能力和涉及领域的了解程度和关系处得怎么样了，这些在这种关键时候都是派上大用途的！

3. 跳出“死锁状况”

工作中不是所有问题都能在第一时间给出解决方案的，很多时候都需要经过之后的深思熟虑，多番探讨后才有结果。

与研发人员沟通不外如是，不管是在正式会议，还是在针对性解决问题的时候；遇到讨论后，短时间给不了解决方案的情况，一定要能够及时跳出来，脱离“死锁状况”，释放资源，将该问题纳入后续待解决的“池子”。

四、“越俎代庖”不可取

切记：千万别越俎代庖！

别认为自己对相关技术知识有所了解，就将重心倾斜到技术向。这样做不仅会让共事的研发反感，认为你在他专业领域插手太多，指指点点，也会让你在做产品思考时，不自觉的被团队技术能力所限制。

所以，把握好分寸更为关键、重要。毕竟了解技术知识是为了帮助我们更好的做好产品，和研发更好的共事服务的。这些都需要在实际工作中，大家灵活应对。

五、总结

以上就是笔者关于——“你不应该错过的设计&技术知识点”的分享内容，希望对各位有所帮助。

总而言之，就是希望各位能够多迈出一步，去了解对方行业相关知识，提高工作效率的同事，提升协作双方的满意度。

作者：nickChen，微信公众号：薪火杂记

本文作者 @nickChen

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！