网站建设创新机制
条条道路通罗马，同样地，交互设计问题的解决方案也不止一种。我们总是在追求最好的解决方案，但考虑选择的时候，通常可供选择的方式总是被时间，技术，资源，竞争等以上因素，甚至更多因素羁绊。有时为了“交货”，通常我们总是选择一个最稳妥，最保险的解决方案，只是很可惜通常这个解决方案看上去并不怎么创新。
对于交互设计的创新网站建设，我们通常愿意采用这样一种形式，在提供切合目前现状的最合适解决方案时，鼓励设计师储备“备选解决方案”，而备选方案的设计通常会有制度性的保障，例如当没有想法的时候，设计师可以在交互设计组，甚至更大的范围发起“头脑风暴”会议，可以申请“设计封闭”，可以组建“工作坊”，当创新点梳理出来后，鼓励自己动手，通过各种工具变成可演示Demo，以直观丰富的形式向项目组展示，这个其实也是一个启示，对设计方案的创新需要有孵化机制，需要包装，需要推销，“唯有震撼，才能影响”。
经验法则：任何设计都是可以改进的，这是永恒真理，但只有适合当前项目需求的才是最优方案，不盲目创新很重要。
设计实践
主要有两个维度， 对于垂直维度，网站建设我们关注流程实践，我们如何组合团队搭建，用户参与，设计评审，原型设计，专家评审，迭代设计等设计过程，以保证设计实践的最优路径，并做到快速渐进，在这个维度目前我们还在摸索，但随着交互设计子流程的建立，应该说基石已经打好了。
对水平维度而言，我们关注共同成长，对于多数设计师而言，多年的设计实践最终可以形成自己的行事经验和专有技能。从此成为立命之本，对于CDC的设计团队而言，我们还有很重要的工作就是团队建设，如何分享设计师的经验，如何取长补短，如何形成最优的设计实践。其实是一件群策群力的事情，简单而言，B1.0项目的教训如何保证B2.0中不再重复，A项目的经验能不能复用在B项目中。在一个大团队中，很难保证一个设计师会跟一个产品跟n个版本，从生到死，当一个新人加入时，他（她）需要怎样的准备才能快速成长，项目组之间的信息不透明，不对称这些都是问题。目前我们是通过小组的制度来加以保证的，例如所有设计师参与的周例会，月会分享，原创写作，项目组showcase机制，定期项目管理沟通会，邮件周知制度等来保证的。
一点题外话，从上可知，设计实践产生了一个重要命题是“各项目线设计实践中的零散经验教训如何转化为群体智慧，从而保持基业常青”，从这个话题延伸，目前广为人知的概念是design patterns，DP在产品设计中怎样才能做到内容自发产生，被设计环节以最小制作代价复用，同时又能有很强的自我修订能力？坦白讲我们还在实践，能够看到的好的范例一个是yahoo的DPL，这个我们以后有时间再探讨。
经验法则：越早制订设计流程越早遵循，设计实践效果就越好，关注设计师团队的共同进步，消除各自的能力短板，团队才能互补。
风险管理
预先示警相当于提早准备，若能认识到软件和用户界面的实现均涉及较高风险，产品开发团队就能够预先管理整个过程。通常我们在业界的专业分享或者在外面能看到的很多case为什么不具有很强的参考性，一个很重要的原因是它们剥离了软件研发环节的影响因素，“看上去很美”而已，规范风险在CDC的交互设计层面通常倡导几个措施：
1.建立风险列表，提供可用性评估指标，例如“XXX”“XXXXX”“XXX”（请原谅我隐去的一些信息）。
2.设计初期引入用户研究资源，保证客观公正的建立典型用户模型，对设计概念的接受程度进行测试，对设计方案的用户操作问题进行观察，在设计投给开发实现之前，尽量将界面可用性问题加以曝光，避免用户界面和可用性出现大的缺陷和隐藏的缺陷。
3.确立内部专家评审机制，从设计的方向开始，到设计细节实现，内部专家（黄金圣斗士级别为主，也包括神斗士）会先进行一轮预审，然后才会到产品层面的评审，这样也有助于设计团队内部资源的合理利用。
4.将开发阶段和测试阶段的工作明确化，例如在开发之前需要确认设计方案的执行程度，在测试阶段要提供界面实现评估报告等，一直到项目结束都有工作要做。这也成为了CDC交互设计师的日常工作之一，而不是提交完设计方案后就意味着任务结束。
经验法则：有正确可执行的计划只是第一步，引入check机制，强化执行和跟踪水平，项目会更容易获得成功。
相关信息