说实话，刚入行那会儿，我也以为画个网页的框架结构图就是拿笔在纸上圈圈画画，搞个线框图交差完事。后来被产品经理骂，被开发怼，被设计师嫌弃，我才明白，这玩意儿根本不是简单的“画图”，而是逻辑的具象化。今天不整那些虚头巴脑的理论，就聊聊我踩过的坑，顺便说说怎么把这事儿做对。

记得第一次独立负责一个电商后台管理系统的重构项目。当时为了赶进度，我连低保真原型都没细磨，直接跳到高保真设计。结果呢？开发一看，懵了。因为我在页面上放了一个“批量删除”按钮，但在逻辑上根本没考虑多选状态下的数据校验。最后上线那天，测试提了十几个bug，其中三个都是关于这个按钮的交互逻辑。那一刻我才意识到，没有经过深思熟虑的网页的框架结构图，简直就是灾难的源头。

很多人觉得，框架图嘛，不就是把导航、内容区、侧边栏排一排？错。大错特错。我之前有个习惯，喜欢一上来就纠结颜色、字体、圆角大小。后来有个老设计师跟我说：“你先把骨架搭稳了，再考虑皮肉。”这句话点醒了我。真正的框架结构，解决的是“用户在哪里”、“能做什么”、“下一步去哪”的问题。

举个例子，比如做一个内容资讯类的APP。如果你把搜索框放在底部导航栏，用户找东西得先退出当前页面，这体验得多差？但如果放在顶部，虽然占用了首屏空间，但符合大多数人的操作习惯。这种取舍，在画网页的框架结构图的时候就得想清楚。别等到开发写代码了，再改布局，那代价太大了。

我现在的做法是，先拿纸笔。对，就是最原始的纸和笔。在纸上快速勾勒出页面的层级关系。比如首页，我要突出什么？是Banner图，还是推荐流？如果是推荐流，那列表的密度是多少？一行显示几个？这些细节，在电脑软件里调半天，不如在纸上划两笔来得快。纸上画完，确认逻辑通顺，再导入Axure或者Figma。

这里有个小细节，很多人容易忽略。就是状态管理。一个按钮，有正常态、悬停态、点击态、禁用态、加载态。在网页的框架结构图中，如果只画一个静态按钮，开发做出来的效果肯定是不完整的。我一般会专门列一个“状态说明”的小区域，或者在原型里用不同的颜色标注出来。虽然这会增加一点工作量，但能省去后期无数次的沟通成本。

还有数据展示的问题。比如一个列表页，如果数据为空，显示什么？是一张插画，还是一句提示语？如果数据加载失败，是显示重试按钮，还是自动刷新？这些边界情况，在画框架图的时候就要考虑到。我之前就吃过亏，没考虑断网情况，用户没网的时候，页面直接白屏，投诉电话都打爆了。

再说说工具。有人喜欢用Visio，有人喜欢用ProcessOn，还有人喜欢用Figma。工具不重要，重要的是思维。我之前用Visio画过，虽然逻辑清晰，但视觉反馈弱，容易陷入细节。后来转用Figma，组件化做得好，复用率高，效率确实提升了。但不管用什么工具，核心都是要把信息架构梳理清楚。

我见过很多新手，画出来的网页的框架结构图密密麻麻，全是字，全是线，看着就头疼。其实，留白也是一种设计。适当的留白能让用户视线有落脚点，不会感到压迫。就像文章一样，段落之间要有间距，阅读起来才舒服。页面也是同理。

最后，我想说，框架图不是一成不变的。随着项目的推进，需求可能会变，用户反馈可能会出来新的问题。这时候，框架图也要随之迭代。不要怕改图，怕的是不改。每次修改，都要记录原因，这样以后复盘的时候，才知道当初为什么这么设计，现在为什么又要改。

总之，画好一个网页的框架结构图，需要耐心，需要逻辑，更需要对用户心理的洞察。别把它当成任务，把它当成一次与用户的对话。当你站在用户的角度，去思考每一个点击、每一次滑动，你的框架图自然会变得有温度，有生命力。

这行水挺深，但也挺有趣。希望能给正在头疼的你，一点点启发。别急，慢慢来，比较快。