那么到底什么样的设计过程算是完整的呢？
私以为，设计完整性的标准不在于方法的使用，而在于推导过程的合理性。详细而言就是，从原始信息到设计方案的推导过程在逻辑结构上是完整的，在因果关系上是合理的。为了达到这种「推导合理」，笔者总结了一套模型工具-GUCDR模型。套用这个模型便可以得到相对完整的设计推导过程，它可以很方便地组织交互设计工作-从需求梳理到设计落地。
GUCDR模型植根于数个设计模型，并不是完全创新的模型。笔者设计它的目的是在交互工作中可以直接拿来套用，可以把它看做是一个实用工具。
如上图，这是一个非常简单的模型主干：所有设计均起始于「目的」，可能是商业目的或其他目的。然后经过「设计、最终、落地」为产品。用户和条件是设计前须介入的两个重要因素。具体而言，只有“用户”使用产品并完成某些行为，才可能达到最初的「目的」。而设计总是戴着脚镣跳舞，也就是“条件”，譬如技术限制，譬如成本限制。
下面我们对画布中的内容进行相对详细的解释：
a.项目目的
b.项目目标
当然，项目目标的完成情况不完全取决于设计，更取决于运营、产品、市场环境等多种因素。优质的200W流量和劣质的200W流量，对应的转化率必然是不一样的。所以，设计目标的制定需要考虑多种因素，比较简单的方法是参考以往的数据。
方法参考：需求评审、需求梳理、需求沟通；
a.用户信息
方法参考：查看后台数据、查阅历史资料、问卷、访谈、用户测试、用户画像等。
b.用户场景
方法参考：场景剧本、故事板、同理心地图、用户体验地图、访谈、观察、用户测试等。
条件，就是设计的脚铐：
a.资源
b.限制
方法参考：需求评审、需求沟通、技术沟通、竞品调研、历史版本调研等。
设计部分从设计目标到设计策略到设计点，应当是一个巨大的树形图，如下：
a.设计目标
设计目标建立在项目目标和用户目标（用户目标就是用户的诉求、担忧、阻碍）基础上，比如“某问答类产品”改版的部分设计目标是：
方法参考：需求沟通+树形图推导等。
b.设计策略
设计策略建立在设计目标的基础上，每个目标可能有多个策略。比如上文中的“提高回答率”这条设计目标可能有以下策略：
制定设计策略的前提是充分了解“用户”、“场景”、“条件”，这些是设计策略的信息源，也是设计策略合理性的筛选器。
方法参考：树形图推导等。
c.设计方案
每个策略都会延伸出多个设计点，所有可执行的设计点生成了设计方案。比如上文中的“提高回答者回答意愿”这个设计策略，可能对应以下设计点：
想要得到「设计点」，同样需要充分结合「用户、场景、条件」。仅仅通过“推导”和“脑补”是不够的，这是决定设计合理性的重要一环，也是新手很容易犯错的地方。最后需要补充的一点是：设计点简单相加无法直接得到设计方案，这期间还需要通过“信息设计”、“任务流程设计”、“界面推敲”等几个环节，才可以将设计点串联在一起变为设计方案。
方法参考：树形图推导、脑暴、焦点小组、设计内审、MVP+简要测试等；
a.设计确认
设计确认有很多方式，比如走查、评审、用户测试等。
b.设计实施
设计实施是重要的环节，设计效果的评判永远以线上产品为准，而不是设计稿。此部分可能含有：视觉对接、开发对接、跟进辅助、线上走查验收等等。