上周三下午，原验设我盯着屏幕上那个用Axure堆出来的型实“用户登录”页面，鼠标悬停在“确认”按钮上，计解决方心里却犯起嘀咕：这个按钮点击后的原验设反馈，到底是型实弹窗提示，还是计解决方直接跳转？问了旁边的同事，他说“看需求文档”，原验设可文档里只写了“登录成功进入首页”。型实这种模糊地带，计解决方在传统网页开发里顶多算个细节，原验设但在WEB原型实验里，型实它可能直接决定整个交互逻辑的计解决方走向。

WEB原型实验，原验设说白了就是型实把“想法”快速变成“可点击的草稿”，然后拿给真实用户去点，计解决方去滑，去出错。它的价值不在于像素级还原，而在于用最低成本验证那些“我以为用户会喜欢”的假设。比如我们做个生鲜电商的结算页面，你画了五个步骤的购物车流程，觉得用户会一步步走完。但原型一测，发现超过一半的测试者在中途就放弃，因为他们找不到“修改数量”的入口。这种挫败感，不亲手做一次实验，永远只在PPT里躺着。

设计这个实验方案，我踩过不少坑。最核心的一条：别把原型当高保真页面做。你花三小时调阴影、调圆角，用户根本不会夸你，他们只关心“点这里能不能出现我想要的东西”。所以我的方案里，第一原则就是“功能优先，视觉靠边”。用灰白块代替图片，用文字链代替图标，甚至允许某些按钮暂时不可用——只要核心路径能走通，其他都是噪音。

具体怎么操作？我习惯分三层来搭。第一层是“骨架层”，只放页面框架和跳转关系，用简单的线框图标表示元素，不填任何真实数据。第二层是“逻辑层”，开始加入条件判断，比如“如果用户名已存在，则显示错误提示”，用简单的变量和状态来控制。第三层才是“表现层”，这时才考虑颜色、字体、间距这些视觉元素。这三层不是严格顺序执行，而是边做边调，但心里得有数：哪一层出了问题，优先改哪一层。

工具选择上，我试过Figma、墨刀、Axure，也试过直接用HTML+CSS写个静态页。说实话，没有完美的工具。Axure功能强，但学习曲线陡，适合复杂交互逻辑；墨刀上手快，但多状态联动时容易卡；自己写代码最灵活，但速度慢，而且改起来费劲。我的建议是：团队协作时用Figma，因为实时评论和版本管理方便；个人快速验证时用墨刀，十分钟就能出个能点的东西；如果要做复杂的条件逻辑，比如多角色权限切换，那就老老实实回到Axure。

实验方案里最容易被忽视的，是“测试脚本”的设计。你让用户自由点击，他们可能漫无目的，你问“觉得怎么样”，他们只会说“还行”。得给他们具体任务，比如“请找到并购买一瓶500ml的矿泉水，完成支付”。任务要具体，但别给步骤提示。观察他们怎么走，在哪里犹豫，在哪里卡住，比听他们说一百句“挺好的”都有用。我上次测一个预订流程，用户卡在“选择日期”那一步，因为日历默认弹出的是当前月份，而他们想订下个月的。这个反馈，直接让我们把日历组件改成了“点击后自动跳转到下个月首日”。

还有一点，别怕原型做“错”。做错了，改起来成本极低，这恰恰是原型实验的意义所在。你花一天时间做个粗糙原型，测出三个逻辑漏洞，比闷头开发两周后才发现需求理解偏差，划算得多。记得有次我们给一个B端后台做原型，测试用户是内部运营人员，他们提了个需求：“能不能把导出报表的按钮放在列表页顶部，而不是详情页里？”我们当场改，五分钟就更新了原型，再让他们试，果然顺畅多了。这种即时反馈的快乐，是其他开发阶段给不了的。

最后说句实在话：WEB原型实验设计，没有标准答案。你团队里有人习惯先画流程图，有人喜欢直接码界面，只要最终能回答“这个方案能不能用、哪里不对劲”，就算成功。别被方法论束缚，工具是死的，实验是活的。多试几次，你自然会形成自己的节奏。