UI设计师要具备哪些技能？

如题所述

说起产品UI设计通常的认识就是“图形界面的设计”而产品的交互设计往往被忽略！一个好的交互设计对产品的成功起着很关键的作用。UI所做的就是用户最先接触到的东西，也是一般性的用户唯一接触到的东西。用户对于界面视觉效果和软件操作方式的易用性的关心，要远远大于他对底层到底用什么样的代码去实现的关心。如果说程序是一个人的肌肉和骨骼，那么UI设计就是人的外貌和品格！都是一个成功软件产品必不可少的重要组成部分！对我而言程序懂得不多所以只是从UI设计与软件产品整体的关系和如何才能使软件产品得到最佳的UI设计角度来谈。

现在我们的软件产品存在的一些问题有技术方面的问题，但是更多的问题来源于各个部门、各个项目小组的之间的配合。我们现有的开发流程一般都是由市场部门提出客户需求，产品设计人员提出产品设计报告，开发部门设计开发计划，由各个小组分别开发一个模块，最后整合成为一个完整的软件产品。在这些流程之间UI设计应该参与那一个部分，每一个部分应该做到什么地步才可以使产品得到最好的UI设计效果呢？下面我们会在每一个部分具体分析。

首先分析一下现在的问题所在，在一些软件业比较发达的国家软件产品的UI设计过程贯穿了软件开发的自始至终，而且是必不可少的。而在中国产品UI设计并没有被广泛接受，就算是已经有了UI设计师的一些企业也没有对产品的UI有着足够的重视，一般来讲他们大都会把重点放在如何使用代码实现所需要的功能，在我看来这只是一个成功软件产品的一个部分。一个优秀软件产品的开发过程应该是由四个部分组成：
1.软件产品的设计（业务建模）
2.系统的设计（技术建模）
3.分单元的开发（把软件各个部分拆分分单元编写代码）
4.测试（分为单元测试、系统集成测试和产品功能测试），这些是由软件研发部门做的工作。
除去以上软件开发过程的四个部分还有用户需求和用户验收测试，这两个过程是由市场部门和产品用户一起完成。所以说用代码实现产品功能（coding过程）只是软件开发的一个步骤。现在我们回到UI设计的角度来看，作为UI设计人员我们需要全程参与到软件开发过程中，而不只是在某一个步骤参与，现在在大多数软件企业里UI设计师只是在产品的coding过程的时候才实质性的参与到软件开发过程里，而在其它几个步骤里只是参加甚至根本没有参加（在这里我要强调“参与”和“参加”是两个词的不同概念，“参与”指的是完全加入到开发行列开始进入设计阶段，而“参加”指的只是旁听会议或者提出一些简单的意见并没有开始进入设计阶段），这样就会大大降低软件产品的开发效率使开发成本成倍上升甚至导致整个产品的不成功！这并不是危言耸听，下面我们分析一下在一个软件产品的开发过程中UI设计应该怎么做、做到什么地步才能避免上边提到的那些问题？

下面我会根据软件开发的过程解释上边的问题，刚才我提过软件开发过程的几个步骤：
1.产品建模
2.技术建模
3.分模块开发
4.测试，那么我们也分为这四个部分进行讨论：

一.产品建模时期：

我们首先来了解一下“输入”和“输出”，在UI设计里是很重要的两个概念，经常会有人过来对我说“我们有一个软件产品需要美化一下”然后再也没有什么深入的解释了，仅仅这句话我的工作就要开始了，然而这个软件是给谁用的？是干什么的？我们却一无所知！成功的UI设计首先要有完整的“输入”，怎么才能叫做完整的“输入”呢？也就需要UI设计师从整个软件产品的策划阶段就开始介入，在产品用户（也就是客户）向市场部门或者产品部门提出产品需求的时候就要开始参与到产品策划开发过程中来，这一部分对于UI设计师而言就是第一个输入阶段，并且在这个阶段里UI设计师也需要提出一些对产品交互设计的意见，以便产品部门在做产品设计的时候更多的考虑到产品的交互性和功能的简单表现原则，有很多软件在设计阶段就被加入了许多并不是用的附加功能，其实一个好的软件设计就是要用最简单的结构实现用户的想法，一些可有可无的功能看上去很花哨往往会影响用户的判断能力，这些就是产品优化的一些概念了在此我需要简单的提一下如果想要深入研究可以看一些有关于产品优化的书籍甚至是心理学的书籍，有很多人认为软件的优化就是代码的优化（用最少的代码实现产品功能），在我看来这只是程序的优化是针对程序员而言的而不是整个软件产品的优化，产品优化包含了交互设计在现在的多数软件企业没有专门做这一部分的交互设计师所以往往这一部分被忽略，我认为这一部分应该又UI设计师承担起来，从文章的开头我就说过UI设计不只是图形界面的设计，就算是有企业里边有这样的优化人员或者交互设计师他们也要和UI设计师一起配合完成产品交互设计，作为UI设计师产品的交互性和易用性是在做设计的时候必须考虑的！
言归正传，产品设计人员经常不会过多考虑简单易用原理也就是产品出来用什么样的组合形式体现给用户，这也是UI设计师考虑最多的事情，所以UI设计师一定要在产品建模期间参与设计，给产品设计师一些意见。作为一名优秀的UI设计师我们还要在了解了产品的需求之后更深入了解这个产品的使用环境和用户群体的使用习惯。我们还需要了解市场上的同类软件产品的设计方案，研究他们的优缺点，以便在我们设计的时候吸取它们的长处避免它们的错误。在产品建模之后一般的都会由产品设计人员给客户做一次功能设计讲解，往往这样的讲解只是文字性质的需要让客户想象着理解，这就会造成很大的隐患有的客户根本无法理解你的讲解甚至对这样的讲解根本不认真听，因为他们根本不懂，在讨论过程中他们经常会同意产品设计人员的一切设计想法但是产品测试的时候他们又会提出种种不满意，我想这是一般的软件公司都会遇到的也是最最头疼的事情，但这并不能怪客户我说过客户只会关心视觉效果和软件的操作而并不会去关心我们是怎么实现这一切的。这种情况带来的直接后果就是产品的反复修改开发成本成倍上升，怎么避免呢？这就要靠UI设计师了，俗话说“眼见为实，耳听为虚”，所以需要UI设计师做出一个产品整体效果的demo。这个demo用图片的形式表现就可以，我们只需要将要体现的产品界面做一个拼凑就可以了，因为这并不是产品的最后样子，只是协助产品设计人员给客户讲解产品设计。产品建模时期UI设计师要了解客户的要求想法和产品设计人员对产品功能的要求深入了解产品，采集用户的使用需求、使用环境和使用习惯，了解市场同类产品的设计分析它们的优缺点。协助产品设计人员完成产品建模过程并制作产品展示demo模拟用户对主要功能的操作过程和界面呈现，生成交互原型（基本上产品的交互性和易用性问题都需要在产品建模的时期解决）。如果时间允许我们甚至可以提出一份“UI设计分析报告”，这份报告可以附在产品设计说明后，更有效的帮助客户了解我们的产品设计并且帮助开发人员更好的遵循UI的整体要求来完成开发工作。这个时期的关键是“交互设计”。

二.技术建模时期：
在这个时期作为UI设计师我们已经了解了软件产品的功能需求并且拿到了一份产品设计人员的产品设计说明，可以进入界面样式的设计过程了。这个时候我们应该考虑更多的应该是产品的整体风格和界面的设计，通常我们也会做出几份方案给客户选择。有些客户会要求产品遵循一个整体的VI设计标准，那么我们就需要按照一个整体的已定的风格去设计软件的界面，要与客户公司的企业形象吻合。在这个时期软件的UI设计进入到了美术设计阶段，我们需要制定整个软件的风格，塑造软件的整体形象，并且具体的描述每一个界面中的元素和布局、文字字体等信息。在这个阶段我也不应过多的说什么，主要是每个UI设计师各自发挥你们的艺术专长用最简洁、最漂亮的界面表现软件产品。需要注意的就是在我们设计整体风格的时候一定要深入了解这个产品的理念，看看它是干什么用的。不同的产品要有不同的风格，这里边有很多的细节注意，不同的产品、同类的产品不同的内容、不同的传播介质，这些都会决定UI设计的风格。1.不同的产品：比如一个游戏产品就需要将界面做的花哨一些或者用大的图片充斥；如果要是一个应用软件就需要突出使用方便和强大的功能设计要简洁。2.同类不同的内容：比如一个可爱的游戏产品（像是卡通类游戏）就需要将界面做的活泼生动可爱一点；如果是一个角色扮演的战斗类游戏（像是枪战闯关类游戏）就要做的酷一点深沉一些。3.不同的传播介质：我们要做的软件产品有的需要在网络上传播那么就需要我们考虑到网络速度的问题；有的就是利用光盘当作介质那么这样的软件就可以做一些比较花哨的效果。所以说不同的产品还需要单独考虑，这也需要UI设计师多多了解产品，保持与客户交流。还需要重点注意的就是我们在做图形化设计的过程中千万要贯彻在前一个阶段做好的交互设计，始终注意产品的交互性和易用性。在设计过程中我们一定要做出每种结构每一个步骤的效果图，不能只提供图标、按钮、背景图等图片，这样的话程序员根本不知道往那放这些东西，在这个时期我们就要最终确定软件界面的呈现形式。技术建模一般是由高级程序员完成的，他们会将整个软件开发分为一个一个功能模块，分配给一个一个的开发小组。但是这些负责技术建模的高级程序员考虑更多的往往是如何将整个设计用代码实现、怎么才能更有效的复用以前已有的模块等等，而不是软件是什么模样会有什么样的风格，所以作为UI设计师我们必须主动出击，多多和他们交流以保证我们的想法能够完整的实现，如果有技术实现的问题我们还要及时做出修改。有时候我们还需要根据客户或者产品的特定需求做一些延伸性的设计（也叫UI产品设计的外延），包括：软件的安装导航界面、产品的演示宣传动画、一些附带的桌面壁纸或者屏幕保护、代表软件的卡通小精灵、有时还会被要求设计软件的logo和广告banner等等。技术建模时期的关键是“风格和界面设计”。
三.分模块开发时期：
这个时期软件开发过程进入实现阶段，也是需要人力最多的时期，这样就会分散UI设计师的精力。软件会被切分为若干个小的模块进行代码编写，最后整合成一个完整的软件产品。对于一个程序员来讲他们大多根本不会考虑到产品应该是什么样子应该有什么整体风格，他们所考虑的只是如何用代码实现设计的要求，而且在现在的软件企业多都实现了模块的复用，这样会大大节约人力成本，那么程序员只是对原有模板进行修改使之适应新的软件产品，这样就会对UI设计的最终贯彻和实现带来很大的麻烦。做出的每一个模块虽然已经能够使用但是都是“各自为政”没有统一，因此我们也需要主动的协助和监督程序员完整的实现UI设计的要求，如果有技术无法实现的问题需要及时沟通改正设计方案。有的时候有些模块需要有单独的风格，比如一些已有的软件产品需要集合到某一个新的产品中去，这样就会加大了设计师的设计难度，我们必须要在保证产品整体风格不变的情况下将原有产品的设计风格集合进去，使之更加适合新的产品表现形式。如果我们仍旧保持原有产品的风格那么当各个模块集合起来之后往往会使新的产品感觉很松散，进入每一个功能都会觉得是另外一个软件，使人对软件的印象不深刻。在这个阶段我们还是要主动一些，跟进各个模块界面的实现。现在很多软件企业都存在很多UI设计师和程序员的协作问题，不是程序员做不到UI设计的要求，就是UI设计师坚持一些自己的想法不能改动，还有的时候经常会有人过来没头没尾的说帮我做点东西吧！

当软件集成到一起再一看，就是很多不同风格的东西堆砌到一起，从头到尾都不舒服，领导或者客户看了以后极度不满狂批一阵，最后得出结果UI设计做的不到位。有人说UI设计师就要背着软件不成功的黑锅，因为人们根本看不见代码怎么写的，功能是怎么实现的，他们只知道对软件的样子和使用进行评论。让一个用户评论一个软件他们只会说这个软件好用看上去也不错挺漂亮的，但是做为一个普通用户决不会有人说这个软件程序写的不错。这么一看我们会联想到现在软件开发之中主要的冲突在UI设计师和程序员之间，其实这只是表面的表现形式。实质上这个现象体现了现在软件企业的一个通病就是这个开发组之间的协作关系混乱，程序员和UI设计师之间是平级协作关系，程序员是不会对产品负责的，这样看来UI设计师只应该听项目经理的，无论对设计做什么样的改动或者增添什么样的东西，都应该由开发项目经理和产品经理协商之后决定，只有他们可以对最终的产品负责。这样也可以避免很多程序员和UI设计师之间的争执和矛盾。但是现在大多说软件企业的产品经理和开发项目经理没有做到这一点，他们也根本不了解UI设计师和程序员的工作，也无法把握他们的工作量，这样无序的管理会造成很麻烦的后果。其实可以建立一些合理的流程管理制度，就算企业没有作为UI设计师也可以自己起草一份适合自己和企业的“UI设计需求申请单”，里边应该列出我们需要的“输入”内容、工作时间、最终的“输出”结果等等栏目（可以自己根据要求灵活决定）。这样形成一个有参与人、有依据、有存底的工作流程，出现问题或者争执的时候我们有据可依，这只是一个习惯性的东西因不同的企业而议不一定都要建立需求单。在分模块开发时期UI设计师应该做的是，在模块开发的前期做出产品每个模块的效果demo（可以用图片的形式表现）要求程序员按照demo的样式进行模块开发，协助和监督程序员严格按照UI设计要求生成最终产品，把握各个模块的统一，经常了解程序员的工作进展及时对不合理或者难以实现的设计进行讨论设计出新的方案。分模块开发时期的关键是“协助和监督程序员生成最终产品”。

四.测试时期的输入和输出：
软件产品的测试会分为三个测试阶段，第一个是分模块开发完成之后每一个模块进行的单元测试；第二个是将各个单元集成为一个整体的产品进行集成测试；第三个就是整个产品在交付使用前进行的整体测试。在测试过程中UI设计师的任务相对会轻松一些，我们只需要跟着测试人员走几遍流程，如果在其中发现没有按照UI设计要求的部分及时要求改正就好了。我们还会经常遇到客户在测试过程中突然觉得那里不合适需要修改，这也是最最头疼的事情了，有的时候他们说的并不一定对，只要我们设计的每一个步骤都有一定的道理能够说服他们就一切ok了。如果他们执意要修改设计方案，那么我们没办法只能按照客户需求修改。但是如果前边按照本文的流程走下来我想这样的可能性不大就算是修改也不会是大动干戈。在修改过程中我们还是需要先做出效果图，让客户确定再具体实施，这样也会避免很多麻烦的。测试时期的关键是“检查整个产品发现问题及时改正”。

如今软件的越来越多的考虑到人的因素，“以人为本”的设计理念贯穿了整个软件产品开发的始终，因此软件产品的UI设计过程最重要的两个部分就是行为和构造，也就是交互设计和界面设计。上面我们按照软件开发的四个阶段，逐个的分析了每个时期UI设计的任务。由此我们可以看出UI设计并不完全是一个美术设计的过程，还有很重要的一个部分就是交互性和易用性的设计。我们要时刻把自己放在软件的用户角度来考虑，设计出最简单易用，界面友好的软件产品。

另附

温馨提示：内容为网友见解，仅供参考

当前网址：https://11.t2y.org/zz/f8m7f82s.html