博客分类：
这是我亲身经历的项目，并且是项目负责人，该项目只有10个左右核心页面，七人，一个半月。
而几年前，我做过的两个项目，技术难度比这大，功能模块比这多，却只需要一个人，一个月。
问题在哪里？大家一起来分析一下。
先描述一下这两个成功的项目。
项目一 南开BT联盟(简称：BT)
项目背景 南开BT联盟是我03年底在校内部署的一个BT网站，采用一个免费的BT服务器(PHP)。半年后，也就是04年秋，发展成南开校园内几乎最热门的下载站点，我爱南开BBS的BT版成为年度十大热门板块(网站运营是另外一帮哥们，我只负责幕后技术)。因为校内注册用户超过5000，并且种子数超过1万，于是出现了定制化开发的需求。但是，该BT服务器是免费闭源，PHP是加密过的，没法改。于是，05年年初，也就是寒假那一个月，我没有回老家，从零开始，一个月写了一个Java版的BT服务器，开学后，就替换了原来的，运行一个月后，反应良好，晚上高峰期，上千人同时下载，。
功能模块
内核：BT客户端和Server端通信(编码解码器)，torrent种子文件解析，种子状态更新、下载流量统计。
附加约8模块：种子列表、详细，站内信，简易BBS，种子上传、管理，用户管理，用户注册登录，排行榜、求种、系统管理等。
开发技术：JavaBean+Servlet+JSP(eclipse3.0+Tomcat5.0)
代码量：50多个JSP，约三万行Java代码
项目二 报表展现（简称：Report）
项目背景 该网站约有两百个复杂报表，现在，因为整个大系统统一用Java开发，所以主要是技术升级。项目经理估算是10个人月，所以把活丢给我就没管了，慢慢开发吧。我分析了两天后，告诉他，我可以两周出一个版本，他大吃一惊，很有信心，就不过问我了。
我根据需求，自己开发了一套适合报表的框架（定制化的MVC框架）。另外，将sql统一到几个配置文件，以便将报表查询和程序分开(DBA和开发人员分开)。说实话，真正有难度的是sql，反正我看不懂。
开发了一个月后(两人，一个月)，交工，客户很满意(50万合同额)。后来有近两个月的维护期，基本一周花半天就可以了，反正那段时间我特闲，专心啃技术。
实际情况是，我两周开发框架，两周开发业务。
项目三和四 当前的项目(简称：新B2C)？
项目背景 该项目(老B2C)04年，一个程序员一个美工，一个来月就上线了。其后几年，每年几十万的毛利。但项目几年没维护，页面陈旧，内容过时，当然，产品和价格总在更新。
于是准备改版，核心页面总共10个左右，如首页、频道首页，产品详细页，预订表单。
技术5人，业务2人(负责网站内容)。技术人员中，一个(我)负责需求和原型，一个负责后台(另外一个辅助)，一个负责前台，一个设计师。其中有技术高手，比如我，却搁浅搞业务，一个电子科大的技术牛人，一个原来开发老版本的开发人员。
花了一个半月，约8人月。
技术：前台JSP+JavaBean+WebWork，后台用Flex+Hibernate+Spring。前台让开发人员选用自己的熟练地技术，后台技术也是熟练的，基本上进度阻力并不在技术。
改版后，Google统计数据和实际订单量表明，并不成功。
--------------------------------------------------------------------------------------------------------------------------------------------
问题在哪里？
下面是我的分析和比较，但我认为项目的决定性因素总是那些方面，只不过哪一方面突出些。
1、原型开发(需求分析)
BT：基本没有，因为业务非常简单，主要是老版本技术升级。
Report：基本没有
老B2C：有，主要是抄袭，业务简单。另外，两个人，一拍即合。
新B2C：开发完原型后，给业务人员确认，修改，反反复复。老板当时不看，过几天会突然提出修改命令(小企业，老板没那么多事)。
最后确定下来的，是第三个版本，已经花掉了约两周。
2、内容建设
BT：不需要内容，只做平台。
Report：不需要内容，主要是处理数据
老B2C：内容抄袭，美工、开发人员一起抄。
新B2C：内容重新整理，只要出结果就行。
不过，出哪些内容，也就是一级大纲我出，包括原型上要求的内容，我都要截图出规范，配合很死板。小团队协作，通过文档规范来解决，已经是下下策了，但没办法，已经没法推进了。
3、界面开发
前三个项目，界面都很简单，直接Dreamweaver开发。
新B2C，一位高级设计师，新来的。因为原型中已经大体确定了布局，另外，可能我对界面干涉较多，所以他来后极不适应，因为以前做网站都是自己一人说了算，经常是到下班六点，就开始做自己的个人网站，不把工作放在心上。后来差不多做完，就离开公司了。
界面开发了约一个月，其中首页开发了半个月，后半个月都是赶，所以质量很差。因为界面设计都是先PS做效果图，后切片做HTML，工作量大。
我的问题：交互设计师(我)和界面设计师的职责不明确，导致设计师失去热情。后来我想到解决方案：1、设计前先给设计师仔细讲解业务，为什么我这么布局；2、界面风格的评审留给业务员。
但我本身对交互设计和界面设计有较好的基础，我更接近客户，还是业务员？我接触业务已经一两年了。
4、决策
前三个项目，基本上是个人决策，执行力很高
新B2C：因为涉及到产品经理(我)、业务员、老板三方，谁都想争取决策，闹得非常僵，项目几乎无法展开。第三个版本，修改建议主要是听业务员的，但大家已经彼此失去合作热情，导致后期的原型确认和内容建设进度很慢，三方都在耗。
5、协作
前三个项目，基本都是单双人，很顺畅。
新B2C项目，涉及7人，技术团队内部协作对进度影响可能只有10%(除了当时那位设计师，都服我)，但部门间协作非常困难，因为没有利益制衡。虽然没有剑拔弩张，但已经是很机械、被动的合作。
6、激情/热情(最根本的问题)
BT：强烈的学习动机，一定的责任和荣誉感。那时候我每天写代码到晚上3点，睡一觉后接着写。
Report：强烈的技术爱好，领导的信任和支持，没有进度压力。那时候我路上思考，吃饭时思考，睡在床上也思考。
新B2C：毫无激情(一周有效时间三天都不到），下班和周末就彻底不想思考。
我：有责任，但无权和利。权：无法推进业务员的内容建设， 利：作为合伙人，只拿基本生活费2k(五年前月薪的1/3)。
我的期望：老板把网站业务这块抓起来，另外花点时间在用户体验上，而不是想起来就催进度，提需求，而从来不关心导致进度迟缓的原因，并且一起办法。
管理的本质是利益的制衡，对于我们三方，我、老板和业务员均无制衡。
事后我想到的解决方案
以信任和激励为核心(激励的本质是满足人性的需求：比如我最看重士气和团队凝聚力，做事本身的快乐，而不是利润)。
一切问题，都是人的问题。
如果说业务人员不配合、缺乏动力，是我引起的只有30%，因为我们是物理上分开的两个环境，两种文化。
如何激励？
老板解决内容质量和内容推进，不规定进度，而是期望进度(没有进度压力，往往开发得更快，进度我心里有分寸)。
原型决策权：在我，我会征询大家的建议，协商一致后，业务部必须达成。
界面风格决策权：在设计师(因为我吸取了以前的教训，新设计师热情很高，我的建议基本上就是她的决策)，其它任何人只有建议权。
薪水：在我强烈要求下，已经涨了1k，基本够业余时间消遣。
上面的措施，主要是解决我(负责人)和设计师的激励。如果说管理的本质原则是：责权利的平衡，那么有权和利做支撑，我的责任感也会来，我也想把事情做好。
不过，我的期望似乎太理想了，去改变老板太难。
如果能够解决团队协作和士气问题，我认为可以达成如下目标：整体进度提前50%，约15工作日(三周)，也就是将内耗省下来。界面设计速度、代码开发速度可能快不了，但原型开发速度、内容建设速度可能提高60%。
因为公司有好几个子网站要改版，目前这个子网站，我把负责人的位子交出来了，离开成都来大连(和老婆团聚一段时间)，我只专注于原型和界面评审，也就是用户看到的那部分。因为，我确实不想这样内耗，或许那位做老网站的员工和业务员、老板处容易些(企业基因啊，我是外来基因)。
大家看到这样的案例后，对团队协作和单人作战，以及项目开发过程(需求、原型、开发、内容)与进度的关系，有什么新的看法？如果这样一个项目，你是负责人，你会怎么做？
论坛回复 /
(60 / 32328)
1.楼主单干的那两个项目和公司的这个项目没有什么可比性（包括功能复杂度、需求侧重点、项目目标等）
2.楼主的管理经验不足
认同。
经过近三个月的反省、分析及总结和学习，特别是结合大家的看法和建议，后来类似的一个项目要顺利得多。
现在团队内沟通和协作比较顺畅，因为大家都参与到项目需求、进度等讨论和决策中，而不是前期的单向指挥方式。
现在，当和设计师、开发人员意见不统一时，基本把决策权给他们，我来协助。当然这需要把握一种平衡。最后的结果和进度差不多都超出了我的预期。
将团队的热情、主动性、责任感调动起来后，他们往往会超出我的期望，我觉得我们已经走入了良性发展。
《》提供给我一种理念和可操作性方法。
《》，给我提供了更切实际的计划、沟通技术指导。
我只告诉你一点，公司团队的客观因素，是我们无法改变的，只能去适应它，还要拥抱变化。
如果你想快速成长为一个职业经理人的话，那么你首先放好内部团队建设，多吸取有经验人事的意见，多从对方的切入点考虑，对你有利而无害。想必给你回铁子的这些人，都是热心肠，而没有人愿意和你争辩。
再者，带领团队应该看的更远，你这样的团队发展不利于良性循环。你刚才提到的第二点，很明显感觉到你是个极度主观的人，当然了。如果你是一个成功的Leader，那么首先放眼应该是在团队的人才培养，而不是单打独斗。人才培养，注重团队中每人的价值观，更易于团队良性发展。
最后，我想说，LZ你给我回复的那2点，如果你仔细看我这段话了，那么你这问题就迎刃而解了。
心态大于能力，做事先做人。squall140，可能在团队建设方面我们有误解。我很重视内部团队建设，问题主要是部门间沟通、协作。不知道你为什么觉得我是个极度主观的人，你说的主观应该是以自我为中心，因为人的想法都是主观的，想法出自自己的脑袋嘛。可能文章的描述只能反映一个我们团队管理的一个角落，并且我们的对话都很抽象，没有具体、针对性。那就这样吧，你的观点本身我是很认同的。
但是如果谈到PM，那么首先你的侧重点就搞错了。
团队最重要的是 沟通和协调。
小的团队更好管理，作为PM，小团队小项目可以发挥英雄主义，
但是如果你遇到大项目，恐怕你的这套“理论”就够呛了。
你适合做将领，并不适合做统帅。
至于为什么，我提到的2位已经说的很清楚了。
1、团队本来就几个人，并且有部分工作别人没法替代我。协调和沟通确实非常重要，我一开始就意识到，但不可能像10来人的团队那样只做沟通和协调。当然，我承认本身在这方面的能力不足。
2、如果我只想轻车熟路，可能真的是“适合不适合”的问题。但我认为，管理能力、领导力，这其中包括的协调、沟通、决策、激励等能力，均可以学会，只要这人人品还行(不去真正关心下属的需求和利益，任何管理、领导都是扯淡)。
如果是一个项目经理，细致的分析项目的过程，找到一个改进的方案，这是非常有必要的。
不过我觉得对LZ来说，这事其实做不做，真没有什么必要。小公司的开发部门的职能是什么？能带来什么价值？是上市以后，大家有股份，还是能涨工资？可能都不好说，公司业务本来就一般般，然后养着一群比业务员工资要高不少的技术人员，我想很难有什么话语权。
公司现在的目标是生存发展，开发部门的目标是什么？如果开发部门没有造血功能，时间长了，能不能存在下去都是个问题。这种压力下，能不能找到好人，能不能留住人，最后是能不能说服得了自己，都说不上。
LZ自家兄弟当老板，还是要多站在老板的角度看成本，看看业务的优化，而不是开发的优化，你那边即使省下来5个人月，对公司能有多少价值。开发可以考虑包出去，只要你能把握好设计。
看得出seeckt同学做事严谨，必要的硬性管理我很认同，你的做法比较倾向于职业经理人，只是目前中国职业经理人意识还处于启蒙，特别是合伙型团队，外企要好些。(我花了两年，看过余世维所有视频，买了他的所有书，理念很不错，但他那套方法很难在小企业操作。)
我不得不佩服一蓑兄的全局视野、判断力，及切实的建议，你的观点都是一针见血，感觉你比我还了解我们。
我一年前就在考虑怎么造血，可能自己人脉还不够广，现在正在努力扩大交际圈。
& 上一页 1
浏览: 655988 次
来自: 成都
技术孵化，任重道远啊！不过大哥能力牛逼啊，相信会有实现的一天的 ...
谢谢分享，刚刚考上研究生，对我有很大的帮助，希望5年后再回到这 ...
谢谢分享！
http://ez.web126.cn/这个不错，完全颠覆目前 ...
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'设计师这样的工作，可以做一辈子吗？ - 知乎<strong class="NumberBoard-itemValue" title="1被浏览<strong class="NumberBoard-itemValue" title=",723,914分享邀请回答39K2,085 条评论分享收藏感谢收起52992 条评论分享收藏感谢收起小编：工作需求每天都有，但总有一些冥冥之中会被更多人关注，如实事热点、周年庆典、大版本发布、热门合作等，那这些被更多关注的项目是否就是传说中的大型项目呢？视觉设计师在这样的项目中，又该如何发挥自己最大的作用，找到自己的最佳定位，保证高质量高效率的完成项目呢？
项目需求中，往往会根据产品功能的优先级、重要程度、工作量级、影响效应范围、资源投入量等维度来对其进行项目级别的评判，如该项目需求能对团队、产品、品牌（甚至企业和社会）造成重要影响意义的，都可被认定为大型项目（重要项目）。也因其对团队、产品的意义区别于日常需求，所以相较于平常而言定会受到更多的关注和期待。视觉设计师作为输出线的中间环节，需要环扣上下游的整体协作，且作为用户浏览的媒体介质的设计者和输出者，在这之中的作用不可忽视。
由于之前有幸参与了几次团队较大型项目需求的设计，对设计师在类似项目中的定位与协作方式积淀了自己的一些感悟和收获，在此和大家分享一下！
大型项目类别
一般情况下，大型项目可按时间划分为两种：计划型与紧急、突发型。
有可预见性，如传统节日、周年庆典、年中/年终大促，或有计划的大型改版、新产品发布等，准备时间相对充沛，且时间可弹性调整。整体设计目标以博人眼球、刺激高转化率或品牌的品质宣传为主。
时间充沛的前提下，对输出的精度和效果自然需要更高的要求，这时我们须在日常需求的流程基础上增加更多的流程细节，如前期的脑暴、更多次的评审、扩大范围的体验反馈等，以此筛选出最高质量的输出，达到大家对大型项目应有的预期。
当项目确定执行，可在立项之前预先做些准备工作：
日积月累：
传统节日与年终活动等都会定时定期出现，设计素材和灵感可在平日里有计划的搜集和积累，不要等到节日到来时急急忙忙去搜索、苦想。届时如有相同需求的设计师在同一时间做同样的设计，容易不约而同、撞稿、不出新意。（也许你会说，那只能怪你自己设计没有创意，但我会说，相同节日、相同地域、相同诉求、相同文化背景的前提下，你冥思苦想出来的创意以为独一无二却根本不能排除被撞稿的可能性。而你平日的灵感累积点却能比当前情境下，在创新点上有所区分、关注的侧重也可能不同而更有趣且更广泛，这样的积累再回看也许能带给你更多的方向参考。
（Ps：养成良好的分类习惯，在需要时它也可以是你的加速度。）
确定项目最新信息，如项目背景、目标、合作团队、可投入的资源、宣传力度预估还有项目时间等。计划型大项目，一般都存在往年的延续或ft性质的合作小组，所以这些基本信息都可以从以往案例中搜集到或者通过产品、运营同学了解到。还需要重点了解的是：项目重要决策人的方案偏重方向等，如果方向错了，那将会带来全盘被推翻的风险。
Brain-Storming
有了前面两项的资料后，就可以组织头脑风暴了。这里不要忽视设计之外的产品、开发哥哥的意见哦，如果可以的话，请更多的召集设计之外的同学，产品、开发虽然都不是设计出身，但是想法是没有界限的，说不定哪一个爆点就能刺激你的灵感，迸发好的方案，也能让你从不同角度了解产品和用户喜好，会有意外的收获。
确定立项时，需要确定的东西更多当然也更细，所以不要慌乱，让我们来做一个清晰的流程规划吧：
第一步：确认工作量，预留人力资源
绘制内容结构框架分布图，按职能拆分需交付的页面，越精确越好。如一些功能页面现有可复用，可免去交互、视觉输出的页面，需清晰标记，并同步UI开发同学可预先开始搭建工作。为后段大工作量留存更多时间。
第二步：排优先级，时间预估
根据拆分的页面任务，考虑设计的先后顺序。大项目页面数量较多，不可能一次性输出全部的设计方案，时间上即使有预留也不可让下游环节干等，人力资源足够的前提下设计方案可以并行，人力紧张的情况下建议分批次输出，让下游同学可以尽早展开工作，可让项目时间更充裕。
第三步：确认上线时间，确认各交付时间节点
确认上线时间后，根据各职能评估的完成时间，制作清晰的交付时间表格，（也可以是我们排期时常用的甘特图）并同步整个项目团队。每个环节需要确立明确接口人，负责在每个交付节点标记需要上游产生的交付物和信息，并且确认交付情况，设计侧一定要确立主视觉，把控整个视觉输出的品牌统一性与设计质量审核。
下图是之前一次大促时的交付时间表格：（可看到表格中需要交付的12个任务分项，与每个任务的交付时间，各任务的责任人、接口人等前面提到的重要信息。每个任务人员的时间是各自串联的，保证其可执行性）
（也可以选择甘特图，也是以图表的方式通过活动列表和时间刻度表示出特定项目的活动顺序与持续时间。基本是一组线条图，横轴表示时间，纵轴表示项目或分工，线条表示在整个期间上计划和实际的活动完成情况。它直观地表明任务计划在什么时候进行，及实际进展与计划要求的对比。管理者由此可便利地弄清一项任务（项目）还剩下哪些工作要做，并可评估工作进度。办公软件中一般可在条形图工具中插入并自动生成，大家这个应该用的较多就不卖丑了）
第四步：在交付时间节点前，安插方案评审环节
交互和视觉阶段，建议至少安排各两次（及以上）评审环节，评审能确立方案的可行性，重要的是可以避免后期的不必要返工。主视觉风格决定了整个项目想要带传达给用户的感受，所以风格是重点审核部分，记得动用立项前期准备的脑暴资料哦！ps：作为视觉设计师，要不忘设计的态度，时刻提醒自己，除了眼前的这个方案一定还存在一个更好的方案，时间允许的前提下不妨再对自己狠一点，过程虽然痛苦，但结果往往会带来惊喜！）
第五步：视觉走查与跟进
设计方案完成后，在UI和前端开发阶段，视觉走查必不可少，即使再有经验的设计师也不可能把所有情况都考虑到，所以在开发过程中补充一些细节是在所难免的，当然这样的情况能避免是最理想的。因项目的重要性质，至少安排两次（或更多次）走查，确保视觉还原度。当然走查完毕后仍要继续跟进，确保方案真实落地且被严格执行。
第六步：上线前内部体验
虽然有测试同学，但是他们在功能上可以保证体验的流畅性，而设计展示与体验还是需要更多双眼睛一起参与完成的，上线前的仔细才会让上线后的页面更加分！
第七步：移动端展示的校验
包括移动端的性能体验与图片、文字的展示，其中需要分享到社交媒体所需要的传播图片准备，响应式的匹配等
计划型时间较为充裕，所以步骤分的可以细致些。
( 拿腾讯云的周年活动为例，每一年的9月9日定会为周年筹划一次较大的促销回馈活动，在此之前自己会有意识的针对周年、庆典、促销等关键字保存一些可激发灵感的素材，如配色、绘图等。在距离周年2个月时，会主动征询产品和运营同学对今年周年庆的一些筹划方案，与大致的启动时间，在确保今年筹划的量级基础上，评估自己从容完成项目设计的时间，并给与产品同学时间预留的建议。在实际项目开始时，拆分并确定此次周年庆的会场数量，按照往年惯例会在周年庆之前推出一个活动预热页面，而主会场会存在一个抽奖模块，其他则是一些固定行业分会场的页面，那么即可确认视觉需要输出的页面个数为6个，抽奖涉及到的通知弹窗5个。那么按9月9日上线的deadline，即可往前倒推页面的交付时间点。其中预热与正式会场必然要保持一致的设计风格，那么这6个页面中，预热与主场馆首页是需要主视觉来设计完成的，而行业会场可以由其他设计同学根据主视觉风格延展就好，可确认下来视觉的人力需要2-3人，因为提前筹备所以时间预留较为充沛，那么主视觉 辅助视觉各一个即可很好的完成。 之后即可和交互、UI开发、开发同学评估完成所需时间，最后做出可执行的时间表格，并严格按照时间节点交付，就能完美的engding上线啦。
活动页面中最为费时的要数首屏头图的设计了，既占据了重要的篇幅，又牵控着主要的元素风格，所以当活动主题确认后，交互同学搭建线框图的同时，就可以着手首屏的设计了。这样能给自己预留更多的设计时间，也能给自己尝试更多方案的机会。关于首屏的功能，大多数情况下主要用于品牌打造，展示使用，并没有后台或操作等功能，如时间并没有这么充裕的情况下，可先将内容框架设计完成交由下游开始重构工作，首屏设计可暂由占位符替代，上线前更换即可。)
突发型项目，没有相应的准备时间，在接到通知那一刻起，就已完成立项。需要做的是分秒必争的马上投入到项目执行中去。项目目标是确保短时间内抢急上线，但即使是时间紧迫，合作流程与各环节的交付节点是绝不可被省略的。还有前期的功能讨论设计师也最好不要缺席，无论是否晦涩难懂，都能在一定程度上帮助理解产品，也能减少在设计过程中的沟通成本，了解产品定位，任务流程各个方面。做到这样才能在紧乱的场景下让团队有序的合作，环环相扣而不生差乱。
设计合作流程
拆分任务页面 —— 标记设计与开发可并行页面——并确认设计优先级——确认上线时间并倒推各职能环节交付时间节点（交付时间包含方案修改校验）——分配执行人员、环节接口人——严格执行
交付时间节点
（下图为并行时间节点分配图）
突发型项目，唯一目标是保证最快上线，时间是唯一的奢侈品，所以各环节必须串行配合，将页面交付细分到模块，让每一个职能都能环环相扣，最大程度的统筹时间分配与利用率，真正的与时间赛跑。时间紧张，难免需要加班配合，但早晚加班也是有策略的，充分了解上下游的加班习惯和决策者以及外界实事时间点，会发现有些需求点未必需要第一时间返回公司或加班，可以在下一个流程之后再补齐，如占位的配图、icon的高清匹配等。
在紧急突发型项目面前，设计师往往会犯很多本末倒置的错误，如在非常时期纠结哪种配色更好，哪种样式更搭等等，这些考量在平常也许正是设计细节的点睛之处，但在当前时间要求下，这些考量就是舍本逐末的表现。
经过最近一次微信小程序的项目，从中受益良多，相信很多视觉设计师也和我一样会情不自禁的关注了相对没有那么重要的细节部分，而掩盖了项目目标的重要性。以下是这次项目的一些收获，或者说是自己面对与其他日常项目时不一样的，需要注意的地方：
必须强制转移关注重点
设计师对美都有一种说不清道不明的执着，对自己设计的页面存在情不自禁的寻求一百分的强迫症，在突发型之外的项目中，这本是加分光环，但在紧急情况下，这样的完美执着无疑似团队的毒药，对项目进程有拖滞的危害。项目性质决定着上线deadline，如果一味的关注视觉呈现，只会拖慢下游进度，影响上线目标。所以视觉同学必须强制自己将关注重点从设计感转移至上线目标上来，优先确保功能的清晰展示，细节的设计可在迭代中仔细摸索。
提前预判性
时间紧迫的项目下，争分夺秒是必须的，视觉作为中间环节，可在交互进行阶段，提前分析页面的时间花费分布，预判可以和交互并行的模块或页面，并提前启动设计，给自己争取更多的时间。
优先结构框架的设计，细节内容占位预留
上下游配合，视觉在给自己争取跟多时间的同时，也可尽量多的为下游UI开发同学争取些时间。例如在页面中，会存在模块阵列或列表等结构，视觉侧工作自然需要将每一个模块对应的配图、控件、文案设计好，但是对于UI开发同学来说是需要先搭建这个阵列的结构，然后在逐一替换模块细节内容的。所以视觉同学可以优先只设计一个模块然后给到下游阵列的结构，UI开发同学即可提前展开工作，减轻后期时间分配上的压力。
（如下图所示为常见网页形态结构，整个页面UI开发同学最先需要得到的其实是设计师确认的框架结构，至于里面的图标、banner配图、抑或是文字内容都是可以后面提供的。具体来说，如下图中，场景切换部分为三分阵列版式，灰色方框为图标占位预留，UI开发同学只需要图标占位尺寸即可，图标细节和形态，设计师在后面完成整体页面框架后-上线前补齐即可。）
设计元素快速复用
不要过多的纠结于与众不同的创新，在设计规范内如有类似模块请优先复用，在保证统一性的前提下确保上线目标。因创新存在试错的隐藏属性，时间不富足的情况下，没有办法保证其高可行性，而已有模块即使在创新设计上减分了，但是却经过了试错的考验，相比之下更能保证上线的安全系数。
做完一个项目如果只是增长了项目数量值是绝对不够的，我们还需要对线上方案进行数据的回收，针对项目目标的不同侧重，有所针对的验收数据指标，以实际数据来验证自己的设计在项目中的合理性。计划型项目可能在设计过程中已被产品、运营同学要求埋点，这时主要着重将设计关注的部分提炼总结即可。突发型可更多关注功能模块触发区是否符合点击预期、隐藏功能是否被成功指引等方面的点击数据。（公司可提取数据的平台有 ,可在UI和开发阶段提前写入 hotrep 脚本，在数据平台即可根据 hotrep 标记的ID名称进行数据量查询）
当然大型项目并不像普通需求那么频繁，且每一次的场景与需求点、宣传重点都是不同的，所以每一次项目经历后，都应该在完结时养成做项目总结的习惯，通过数据反馈、用户使用的嘈点与赞点分析自己在设计方案中的优劣，集成经验与教训，搭成自我成长的阶石。另外，更多的了解整个软件开发的工作流程以及各个角色的工作内容，再深入些可再酌情了解些项目管理的相关知识，这些都可以帮助设计师更快的成长，更好的在团队中发挥作用。
原文链接：x
作者：蝈蝈蝈
封面图来源: dribbble- @ARM Sattavorn
转载请注明： &
学UI就上学UI网！越努力，越幸运！
“学UI网 ”最值得关注的UI学习平台！ 每天发布高质量的设计教程和分享设计经验，服务于20万UI设计师,帮助初学者快速转型。每周六晚上免费YY公开课（），给大家提供更多免费学习的机会。想成为设计师的你快来关注吧！
【特色推荐】
” 海量APP截图，让你灵感爆发！国内最好的APP截图站。
“” 每一个作业题都尽量配有教程，交作业就有大神免费帮你点评作业，爽歪歪！
“” 专为UI设计学习者打造的资源＋学习，双用途的网址导航站。亲爱的，你收藏了吗？
你可能喜欢的：