Elito方法：把观察、价值与设计概念连成一条证据链

员工发出请求后，反复问有没有人接手。研究结束，团队提出“做一个智能工作台”，听起来很完整，却说不清为什么这条观察需要这样的方案。

Elito方法把设计观点拆为五项：观察、判断、价值、概念或草图、关键隐喻。团队可以逐段检查，避免从材料突然跳到一个大概念。

填完五列并不会自动证明方案有效。它提供的是一条能够讨论和追问的设计主张，每一段仍需要相应依据。

先区分看到了什么、怎样理解它

假设一个后台研究记录到：员工发出请求后，再次联系接收方。观察列应该写这项行为，并对应具体事件，而不是写成“系统低效”。

判断列解释它为什么重要，例如“发起人无法确认责任是否已转移”。但这仍有竞争解释：再次联系也可能是补充资料，或确认优先级。需要回到原材料，不要因某个解释容易画成界面就选它。

价值列说明希望支持什么，如清楚、自主或安心。它不是把判断换个词重复，也不等于收入预测。概念列才提出回应方式；隐喻则帮助团队记住主线。

“交接回执”不意味着必须画回执图标。要检验的是用户能否理解责任转移，以及状态是否可信。一个好记的词，不能替代具体功能说明。

思考可以跳跃，正式观点不能靠猜测补齐

先整理研究材料，为事件、引语和图片编号。AEIOU框架可以检查情境是否遗漏，但“互动”“物件”这些类别不能直接当作观察结论。

设计、业务和技术人员可以分别提出主线，再一起讨论。不同角色能够补充解释和条件，业务目标却不能代替用户材料。

填写不必机械从左向右。可以先有一个概念，再寻找支持与反证；也可以被一条观察触动，再考虑价值。但如果找不到依据，就把想法标成探索，不将猜想塞进观察列。

同一观察可以保留几种判断。例如“没有明确接手”与“优先级未确认”，可能指向不同设计。先留住分歧，相关研究才能决定该核对哪一段。

每个概念都要问一句：它靠什么工作

显示接手人，看似只是增加状态，实际依赖谁来确认、什么时候更新，以及转交后责任怎样变化。若这些规则没定，界面可能显示一个很好看的错误承诺。

业务限制可以影响方案规模，技术条件可以影响实现路径，但不能改写观察事实。预算不足时可以先做较小方案，不能把用户问题描述成恰好已经能实现的功能。

逐段检查：观察是否支持判断，判断为何与价值相关，概念怎样支持价值，隐喻有没有夸大。薄弱处和未知条件都可以留在表里，不必把每条主线整理成毫无漏洞的结论。

跨行综合时，别剪掉依据

多个观点可能有共同价值、重复概念，也可能互相矛盾。用亲和图归组后，仍要保留每条主线的材料索引和分歧。

如果几条主线都提到“清楚”，需要进一步看清楚的对象：任务状态、责任人还是资料版本？抽象词相同，不代表可以合成一个方案。

成功标志：团队能从候选概念回查原观察，说明中间怎样推理，并指出还缺哪项确认。表格不是评分矩阵，也不是因果证明；可追溯的薄弱点比一张填满的表更值得讨论。

下一轮验证，检查的是哪一段

回到研究材料，可以核对“无法确认责任”这项判断；通过原型任务，可以检查用户是否理解接手状态；实际使用之后，才能继续观察这种表达有没有支持协作。

这几项不能合成一句“方案已经验证”。最终保留五列表、材料索引、约束和后续问题，让团队知道当前凭什么决定，以及何时应该修正。

58UI可以用这类推理记录连接研究、UI/UX原型和企业官网设计开发，并提供品牌视觉、响应式适配及体验诊断。可了解设计服务，或带着资料与候选方案联系58UI，讨论最需要核对的一段连接。

相关服务