ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

个人网站与作品集设计案例:排版、静态建站与变现

个人网站与作品集设计案例:排版、静态建站与变现 做个人网站这件事我前前后后折腾了十几年从最早用表格排版的静态 HTML到后来装过各种博客程序再到现在用静态站点生成器配一套自己攒的 CSS 变量推翻重来至少五六次。每次重做都会留下一堆设计稿、截图和配色文档时间久了这些个人网站、个人博客的设计案例本身反而成了我给别人做咨询时最有价值的东西。因为大多数人卡住的地方真不是技术——现在建站门槛低到一晚上就能上线——他们卡的是“不知道该长成什么样”首页放什么、导航要不要侧边栏、正文字号多大、配色怎么定、图片怎么压、上线之后怎么被人找到。这篇就把我这些年攒下来的几套设计案例完整拆开讲包括每个决策背后的理由、具体能抄的参数、我自己踩过的坑以及个人作品集网站从展示到产生收入这条路上真实存在的几种走法。不管你是刚写完第一篇笔记想有个自己的地方还是已经有站但想重新设计一版或者手里有几套设计稿想找参考下面这些内容应该都能直接拿去用。1. 先把定位想清楚个人网站的三种典型形态很多人一上来就问用什么框架、要不要买服务器这其实是把顺序搞反了。设计的第一层不是像素是定位。你做一个站是为了让陌生人读完你的长文还是为了让招聘方三分钟内看完你的作品还是纯粹给自己做知识存档这三种目标对应的信息架构完全不一样硬套同一套模板最后一定会出现“首页很漂亮但没人往下点”的情况。1.1 三种形态的判断标准与设计取向我一般把个人网站分成三类判断方法很简单想象一个陌生人第一次打开你的站你最希望他在 30 秒内做的那一件事是什么答案基本就决定了形态。文字驱动型核心动作是“读下去”。这类站的内容主体是长文设计上要极度克制任何干扰阅读的元素都是负资产。典型特征是没有大图轮播、没有侧边栏广告位、列表页只给标题和日期。适合写随笔、行业观察、长篇教程的人。我见过太多这类型站点在首页堆一张全屏风景照加一行 slogan结果访客要滚动一屏才能看到第一篇文章的标题这是典型的自我感动式设计。它的核心指标是“人均阅读篇数”和“读完率”不是首页停留时长。作品驱动型核心动作是“看完并且联系你”。这就是热搜里常提到的个人作品集网站。它的主角是项目本身设计的重点是让每个项目的图片足够大、上下文足够清楚、联系入口足够显眼。典型结构是首页即作品索引每个项目一张卡片点进去是详情页。适合设计师、摄影师、独立开发者、接单的自由职业者。它的核心指标是“项目详情页的到达率”和“联系表单提交量”。知识库驱动型核心动作是“找到并记住”。技术笔记站是这一类分类、标签、搜索、代码高亮、交叉链接是它的骨架。像光学设计、仿真计算这种偏专业领域的记录博客也属于这一类公式多、图表多、术语密集读者往往是通过搜索某个具体关键词进来的一进来就要精准命中。它的核心指标是“搜索流量占比”和“回访率”。判断清楚之后你会发现很多设计争论会自动消失。比如“要不要在文章页放阅读进度条”文字驱动型可以放因为它强化沉浸感作品驱动型完全没必要因为没人会在作品详情页读三千字。1.2 栏目规划与导航结构的具体做法定位定了接下来是栏目。我的经验是一级导航项不超过 5 个超过 5 个就开始有人找不到东西了。三种形态的推荐结构如下站点类型一级导航推荐不建议放的栏目文字驱动型文章、归档、关于、订阅相册、友链墙、心情日记作品驱动型作品、服务与报价、关于、联系技术博客、每日打卡知识库驱动型全部笔记、分类、标签、搜索、关于作品展示、个人日记侧边栏这个事我踩过坑。早年我很喜欢在博客右侧放一堆东西个人头像、标签云、最新评论、归档月份、友情链接。后来看数据发现右侧栏的点击率低得可怜而它占掉了大约 25% 的横向空间直接导致正文变窄、代码块频繁横向滚动。现在的做法是只有知识库型站点保留一个极窄的左侧目录正文宽度保证在 680px 以上其他类型一律取消侧边栏把标签和归档收进独立页面需要的时候再点进去。导航的另一个细节是移动端。桌面端横向排五个导航项很轻松手机端就不行了。我的处理方式是移动端只保留“首页、主栏目、搜索、菜单”四个入口其余全部折叠进菜单里。还有一个容易被忽略的点页面底部要放一次简化导航因为读者读完长文之后想继续看下一篇没必要让他滚回顶部。这个小改动我在自己站上实测人均阅读篇数大概提升了两成成本几乎为零。2. 版面设计把“好看”翻译成可执行的参数设计师说“这个版面有点闷”工程师听不懂改出来还是不对。问题在于缺一套中间语言。我的做法是把所有视觉决策收敛成三组数字加一套配色变量写进 CSS 里以后改版只动变量不动结构。下面这些参数是我用了好几版之后稳定下来的可以直接抄。2.1 栅格、间距与字号的三组基础数字第一组是间距基准。我用8px 基准制所有间距都是 8 的倍数8、16、24、32、48、64、96。好处是整页的呼吸感统一不会出现某两块内容挨得特别近、另一块又空得离谱。相邻元素用小间距8 或 16区块之间用大间距48 或 64页面上下留白用 96。第二组是字号与行高。正文16px 到 18px行高倍数1.7 到 1.8。18px 配 1.75 大约是 31.5px 的行距长文读起来不累。这里有个换算要说明如果你的正文用 rem浏览器默认 1rem 16px那么 18px 就是 1.125rem行高 1.75 直接写在line-height里就行不用算绝对值。标题层级我固定成 4 档正文 1 倍、H3 约 1.25 倍、H2 约 1.5 倍、页面主标题约 2 倍。层级超过 4 档就没人分得清了。第三组是容器宽度。文字内容我锁死680px 到 720px这是中文长文比较舒服的区间一行大约 35 到 40 个汉字。宽屏1440px 以上的时候容器居中两侧留白各 360px 左右留白本身就是设计的一部分。图片和宽表格可以突破容器用max-width: 100%加负边距做成通栏但正文段落绝不能跟着放宽。:root { --step-0: 1rem; --step-1: 1.25rem; --step-2: 1.5rem; --step-3: 2rem; --space-1: 8px; --space-2: 16px; --space-3: 24px; --space-4: 48px; --space-5: 96px; --measure: 42rem; }这套变量写好之后改字号只改一行全站跟着变不用满世界找硬编码的font-size: 17px。我带过的几个人里凡是早期手写死数值的后期改版都很痛苦。2.2 配色方案与对比度计算配色我不按“好看”来选按对比度来选。正文文字与背景的对比度至少要4.5:1次要信息日期、版权、注释也要达到这个下限否则在阳光下看手机就是一片灰。纯黑配纯白对比度约 21:1其实过于刺眼了我一般用深灰。具体算法是相对亮度公式这里不展开推导直接说结论白底#FFFFFF配#333333的正文对比度约 12.6:1非常舒服配#767676的次要文字对比度约 4.54:1刚好过线再浅就不合规了。你可以用任何在线的对比度检查工具验证改完配色跑一遍五分钟的事但能避免掉一大批可读性问题。配色结构我固定成五个变量背景色、正文色、次要文字色、强调色链接和按钮、分割线色。整个站点只用这五个颜色。强调色只出现一处比如链接和主要按钮共用一个色值这样视觉焦点集中。早年我喜欢搞三四种强调色结果页面上到处都是彩色读者反而不知道看哪里。注意分割线不要用纯黑或者深灰用对比度 1.5:1 到 2:1 之间的浅灰就够了。分割线太深会把页面切得很碎视觉上像表格。暗色模式现在基本是标配。我的做法不是简单反色而是单独定义一组暗色变量背景#141414正文#E6E6E6次要文字#A0A0A0强调色稍微提亮一档。因为深色背景下同一饱和度的颜色看起来会更暗直接沿用亮色模式的强调色会显得发闷。2.3 首屏、列表页、文章页的排版套路首屏最容易翻车。我的原则是首屏必须回答三个问题这是谁的站、这个站讲什么、我该从哪里开始看。文字驱动型的首屏我一般是两行字站点名加一句说明下面直接就是最新文章的列表开头不留全屏大图。作品驱动型的首屏可以放一屏但内容必须是三到四个代表作的缩略图而不是一张装饰性插画。列表页我的套路是标题、日期、可选的一句话摘要。摘要长度控制在 50 字以内超过就变成“二次阅读”反而降低点击欲望。列表项之间的间距用标题字号的一半左右比如标题 20px间距留 32px节奏感比较稳。知识库型站点我会在列表项上额外加分类标签和阅读时长因为这类读者是带着目的来的需要快速筛选。文章页的排版重点在节奏。段落每段 4 到 6 行就换行中间用 1.5 到 2 倍行距隔开这是中文长文最舒服的密度。代码块我用深色背景加等宽字体字号比正文小 1px 到 2px并且一定要加横向滚动而不是换行因为代码换行之后缩进就乱了看着更累。公式块单独居中上下各留 24px。图片下面加一句灰色说明文字字号比正文小两档这个细节能显著提升专业感。2.4 暗色模式与移动端适配的取舍响应式我不做“三套设计”我做的是断点收窄。断点设三个就够768px、1024px、1280px。768px 以下单栏1024px 以下取消侧栏1280px 以上放开通栏图。真正要花心思的是手机端的触控区域所有可点击元素的最小高度44px链接之间的间距不能让两个链接的点击区域重叠。我见过不少站点在手机上点“下一篇”结果老是误触到旁边的标签。字体方面我用系统字体栈不加载自定义字体文件。原因很实在一套中文字体动不动就几 MB加载会拖慢首屏而且会出现文字闪烁。系统字体在 iOS、安卓、Windows 上都已经足够好看这个取舍我认为非常划算。只有 Logo 或者极短的标题我会用一两行文字做 SVG 图避免加载字体文件。3. 三个可直接参考的设计案例拆解上面讲的是规则下面给三个具体案例。这三个都不是什么大站就是我实际做过或者深度参与过的类型每个都会说清楚页面清单、关键决策和适用人群你可以按自己的定位挑一个改。3.1 案例一极简文字博客把阅读体验做到极致这个案例服务的是一位写行业观察的朋友站点只有四个页面首页、文章详情页、归档页、关于页。首页顶部是站点名加一句 20 字以内的定位说明然后立刻进入文章列表。列表项只有三样东西标题、日期、分类。没有摘要没有缩略图没有阅读量。很多人觉得没有缩略图会显得单调但实际读起来反而清爽因为读者的注意力全部在标题上扫读速度非常快。正文规格是 18px 字号、1.8 行高、680px 宽度段落间距 1.5em。文章页顶部有阅读时长估算底部有三条相关文章推荐用最简单的链接列表呈现。订阅入口只放一个 RSS 和一个邮件订阅位置在文章结尾之后不是弹窗。这里我特意不做弹窗订阅因为它的转化率提升远不如它对阅读体验的破坏来得明显。这套设计最值得抄的一点是归档页的处理。它把所有文章按年份分组每年下面按月份排标题右侧对齐显示日期。看起来像个简单的索引但它承担了两个作用一是让老读者方便回顾二是让搜索引擎更容易抓取全部内容。归档页的链接我用的是纯文本列表没有分页一页到底几千篇文章也扛得住加载速度几乎不受影响。缺点是这套设计不适合需要展示图片的人。如果你做摄影或者设计纯文字列表会把最重要的资产浪费掉。3.2 案例二个人作品集网站为“被联系”而设计这个案例是一位独立设计师的接单站。整站五个页面首页作品索引、项目详情模板、服务与报价、关于、联系。首页没有 hero 大标题直接就是作品网格两列布局每个项目一张封面图加项目名和类别。为什么不做全屏大图因为访客的目标是“看作品”任何阻挡在作品前面的东西都是障碍。项目详情页我用的是固定四段结构项目背景、我的角色、过程与方案、结果与数据。这个结构是我改了好几版之后确定下来的因为招聘方和客户关心的问题基本就跑不出这四块。每段的文字控制在一两百字中间穿插三到五张大图图片统一 16:9 或者 4:5混用比例会让页面显得杂乱。过程部分我会放一些草稿和中间稿这个特别加分因为它能证明思考过程而不只是最终效果。联系部分有两个入口一个是页面底部的固定联系条一个是顶栏右侧的“联系我”按钮。不搞联系表单的复杂字段只有姓名、邮箱、需求描述三项提交后跳到感谢页。理由很简单字段越多放弃率越高。另外我在页面底部放了一个简历下载链接PDF 控制在 2MB 以内方便对方直接存档。这类站点最忌讳的是“关于我”写得像自传。我的模板是三段话我做什么、我做过什么、我能帮你解决什么。每段不超过 60 字最后附上三个可以点开验证的项目链接。3.3 案例三技术笔记站让搜索流量自己找上门第三个案例是一个偏专业技术方向的笔记站记录的内容比较垂直涉及仿真、建模、参数调优这类偏工程的笔记公式多、图表多、术语密度高。这类站的设计重点完全不在美观而在“精准命中”。它的结构是全部笔记列表、分类页、标签页、单篇笔记页、搜索页。单篇笔记页的顶部是一段 80 字以内的结论摘要下面才是正文。这个摘要非常关键因为搜索进来的读者往往只想要一个答案你得让他第一眼就确认“来对地方了”。正文里代码块和公式块交替出现代码块带语言标签和复制按钮复制按钮这个小功能我一开始觉得无所谓后来发现它确实能减少读者手动选中的麻烦回访率有感知上的提升。标签系统我做了限制每篇笔记最多打 4 个标签标签总数量控制在 100 个以内。早期我不限制结果标签膨胀到几百个每个标签下面只有一两篇既不美观也没法形成聚合效应。控制之后标签页的跳出率明显下降因为点进去至少能看到五六篇相关内容。导航上这个站保留了一个左侧目录宽度只有 200px只在宽屏显示滚动时跟随。目录对长技术文的价值很大读者可以直接跳到关心的章节。这个站的核心指标是搜索流量占比我在上线三个月后看数据搜索入口带来的访问已经超过总访问的一半这说明结构化的标题和清晰的分类确实起作用了。4. 从零到上线技术选型与实操流程设计定了接下来是落地。这一部分我把完整的流程写出来包括选型的判断依据、目录结构、图片处理、上线后的配置每一步都给出可直接复制的方案。4.1 技术选型的决策树选型的问题可以简化成一个问题你的内容会不会频繁变动以及你愿不愿意维护服务器。三种主流方案的对比如下方案适合场景优点代价静态站点生成器博客、笔记、作品集快、便宜、易备份、可版本管理需要一点命令行基础内容管理系统多人协作、非技术用户后台操作直观需要服务器和数据库维护手写 HTML/CSS单页站、活动页完全可控、零依赖内容一多就难维护我几乎全场景推荐第一种。像 Hugo、Astro、Eleventy、Jekyll 这类工具写 Markdown 就能生成站点构建产物就是一堆静态文件扔到任意静态托管上都行。速度方面静态站首屏基本不需要等服务端渲染体验差别很明显。备份方面整个站就是一个代码仓库换电脑克隆下来就能继续写。如果你完全不想碰命令行那内容管理系统也够用只是要准备好每年一笔服务器费用和定期的升级维护。这个取舍没有标准答案但你得提前想清楚自己愿意付出哪一部分成本。4.2 目录结构与关键配置文件这是我用了很多版之后稳定下来的目录结构逻辑很清楚内容和样式分离源文件和构建产物分离。my-site/ ├── src/ │ ├── content/ │ │ ├── posts/ # 文章一年一个文件夹 │ │ └── notes/ # 笔记按分类分子目录 │ ├── layouts/ # 页面模板 │ ├── components/ # 可复用片段 │ ├── assets/ │ │ ├── images/ # 原图不直接引用 │ │ └── styles/ # CSS 源文件 │ └── pages/ # 独立页面关于、归档等 ├── public/ # 静态资源直接拷贝到产物 ├── dist/ # 构建产物不进版本库 └── config.* # 站点配置每篇文章的头部信息我固定几个字段多余的字段一律不加--- title: 文章标题 date: 2025-03-12 updated: 2025-04-02 category: 分类名 tags: [标签一, 标签二, 标签三] summary: 八十个字符以内的摘要用于列表页和搜索摘要 cover: /images/cover-1200.webp draft: false ---updated这个字段很多人不加但对技术类内容很有用因为读者会想知道这条信息是不是还适用。draft用来控制草稿不参与构建省得忘删。摘要字段我会严格控制长度超过 80 字的直接在构建脚本里报错提醒这个笨办法能避免摘要长短不一导致的版面参差。4.3 图片处理与性能预算计算图片是个人网站最大的性能杀手没有之一。我做过一次统计一个没有做压缩的站首页图片加起来能到好几 MB而压缩之后通常能降到十分之一。具体的处理流程是原图只保留在assets/images构建时压缩输出到public/images页面只引用输出目录。图片规范我定三条宽度最大1600px格式用WebP质量80。转换命令大致是这样# 批量把目录下的 png/jpg 转成 webp宽度限制在 1600px 以内 for f in assets/images/*.{png,jpg,jpeg}; do [ -e $f ] || continue outpublic/images/$(basename ${f%.*}).webp cwebp -q 80 -resize 1600 0 $f -o $out done效果我实测过一张 1200×675 的截图源文件 380KB 左右转成 WebP 质量 80 之后大约 85KB体积降到原来的 22%肉眼几乎看不出差别。如果这张图在页面上只显示 600px 宽再加上srcset提供 800px 和 400px 两个尺寸手机上实际下载的可能只有 40KB。有了单图数据就可以算首屏预算了。我给自己定的首屏总预算是200KB以内拆开是HTML 15KB、CSS 25KB、首图 90KB、脚本 10KB、其余零散资源 40KB、字体 0用系统字体。在慢速移动网络下这个预算对应的首屏渲染大约 2 秒出头。如果你超了优先砍图片和脚本CSS 和 HTML 一般不是瓶颈。注意不要用 CSS 大图做背景。背景图没有srcset手机端会硬着头皮下载桌面尺寸的图这是最常见的隐形性能坑。4.4 上线、域名、收录与订阅上线这一步现在很快静态托管平台基本是连上代码仓库推一次代码自动构建部署。域名我建议用短一点的能记住比好看重要。拿到域名之后三件事必须做开启 HTTPS、配置站点地图、把www和裸域名其中一个做 301 跳转避免同一份内容出现两个地址。收录方面我一般做四件事。第一生成sitemap.xml并在站点地图里提交第二每篇文章的标题和摘要必须唯一不要所有页面都是同一个标题加站点名第三给文章配结构化数据至少包含文章标题、发布时间、修改时间和作者第四站内做好相关文章内链让爬虫能顺着链接把所有内容逛一遍。这四件事做完通常一到三个月能看到搜索流量起来。订阅只做 RSS 和邮件两种。RSS 是免费的、标准的、所有阅读器都支持一定要生成别嫌它老。邮件订阅我建议用一个简单的第三方服务把订阅入口放在文章末尾不要做弹窗。我自己的数据是文章末尾的订阅入口转化率大概是 1% 到 2%弹窗看起来能提高到 3% 以上但会明显拉高跳出率长期看并不划算。5. 变现路径个人网站怎么变成收入网上经常刷到“个人网站盈利百万”这类说法我的建议是先把这类标题放到一边因为那类案例基本是幸存者偏差加上流量红利的产物复制难度极高。但个人网站确实可以产生收入只是路径和规模都不一样下面这几条是我见过真实跑通的。5.1 四条主流变现路径与门槛第一条是广告。门槛最低收益也最低。它依赖访问量通常需要稳定的月访问量才能看到像样的数字而且对阅读体验有影响。我个人的态度是如果站点定位是长文阅读广告要极为克制最多在正文中间或结尾放一个位置不要做全屏浮层。经验上小众技术博客的广告收入往往不如同等精力投入到第二条路径。第二条是内容付费。适合知识库型站点。把一部分深度内容做成付费专栏或者把系列笔记整理成电子书。这条路的关键是“免费部分已经足够有说服力”让人愿意为后续内容付钱。我自己观察到的转化率区间大概在千分之五到百分之二之间取决于内容的稀缺程度和读者的信任积累。这个数字不是承诺只是给你一个量级参考。第三条是服务与咨询。这是目前最实在的一条路。作品集网站天然适合接单技术笔记站天然适合接技术咨询。流量要求不高但要求专业度的信号足够强详细的案例复盘、清晰的服务说明、可验证的成果。我见过不少月访问只有几千的站靠每季度几个咨询单就能覆盖全年成本还有盈余。这条路的瓶颈不是流量是你能不能把“我擅长什么”说清楚。第四条是卖模板、素材或者工具。适合有设计能力或者有现成工作流的人。把自己的站点主题整理成可配置的模板或者把常用脚本打包成小工具这条路的前期投入比较大但一旦成型边际成本很低而且不太受流量波动影响。5.2 收入测算与转化率估算做个简单的模型方便你判断什么样的路径适合自己。假设站点月访问10000次每篇文章平均阅读1.5篇那么月阅读量约 15000 次。路径关键指标量级参考主要影响因素广告广告展示次数与阅读量正相关内容类型、访客地域、展示位置内容付费转化率 0.5%–2%与内容稀缺度强相关信任度、定价、免费内容质量咨询与服务线索数 每月 3–10 条与专业信号强度相关案例质量、服务描述清晰度模板与工具复购与口碑传播与产品完成度相关易用性、文档、更新频率这个表里我最想强调的是第二列和第三列的区别广告和内容付费基本是流量函数流量不够就是不行而咨询服务和模板工具是专业度函数几千访问也能跑起来。所以如果你现在的站流量一般别急着研究广告先把项目案例和内容质量做扎实这条路的性价比高得多。还有一个常被忽略的点收入不是从站点直接来的是从信任来的。同样一篇技术文章读者看完顺手就走和一个有清晰作者介绍、可验证项目经历的站后续能产生的关系完全不同。所以我在所有做过的站上都会认真写“关于”页面并且在文章末尾放作者信息和联系方式这个动作几乎不花时间但它是所有变现路径的共同前提。6. 常见问题与排查速查表最后一部分是我这些年攒下来的问题清单基本都是上线之后才暴露出来的写在这里能帮你少走弯路。6.1 样式与构建类问题现象常见原因处理方式长英文或代码把版面撑破容器没有限制溢出正文加overflow-wrap: break-word代码块加横向滚动中文标题在窄屏折行难看固定宽度或字号过大用clamp()做字号自适应移动端降一档暗色模式下强调色发闷直接沿用了亮色变量单独定义一组暗色变量强调色提亮一档构建产物里有草稿草稿状态没被过滤在构建脚本里显式过滤draft: true段落间距忽大忽小混用了 margin 和空行统一用 CSS 控制段落间距Markdown 里不写多余空行图片在手机上糊只提供了一张大图用srcset提供多个尺寸让浏览器自己挑这些问题的共同点是都很小但都会直接损害阅读体验。我一般会在发布前用手机真机过一遍重点看代码块、表格和图片这三块因为它们是移动端最容易出问题的地方。6.2 速度、收录与流量类问题速度问题基本可以按“图片、脚本、字体、第三方资源”这个顺序排查。先看首屏加载了多少 KB超过 200KB 就砍图片再看有没有加载了没用到的脚本再看是不是加载了自定义字体最后看有没有嵌入的第三方组件比如评论系统、统计脚本这类东西往往是最隐蔽的性能消耗。收录慢的时候先确认站点地图是否正常、标题摘要是否唯一、robots有没有误拦截再检查是否有大量重复或空内容页面。另外新站的收录周期本身就长着急没有用。我的做法是上线后先稳定更新两三个月把内容量做起来再去观察搜索流量曲线这样判断更准确。流量结构也值得定期看一眼。如果搜索流量占比持续上升说明内容结构没问题如果全靠社交平台导入那就得考虑内容的可搜索性比如标题里带不带具体的问题描述、分类页是否清晰。我自己的经验是技术类内容只要标题写得具体搜索流量通常会稳步爬升。注意不要为了流量去堆砌同义词标题或者复制内容。短期内可能有点效果但会让整个站的可信度受损后续很难恢复。6.3 我踩过的几个坑第一个坑是过度设计。早期我给自己站做过视差滚动、滚动动画、全屏视频头图做完之后自己都不想打开因为加载慢、看着累。后来全删了页面反而更耐看。这件事给我的教训是设计的目的是让内容更容易被接收不是展示技术。每次想加一个效果先问它是否降低了阅读成本答案是否的话就不加。第二个坑是栏目开太多。我曾经同时维护“文章、笔记、碎碎念、书单、影单、周报”六个栏目结果是每个栏目都填不满访客点进去看到两三篇内容观感很差。后来合并成两个内容密度立刻上来了。个人站点的内容量本来就有限栏目数量必须跟着内容量走宁可少而满不要多而空。第三个坑是改版太频繁。有一年我每两个月换一次主题每次改完都要修一堆细节写作时间被严重挤占。后来我给自己定了个规矩非必要不改版改版必须带着明确的问题去改比如“文章页移动端阅读体验差”或者“作品详情页到达率低”。带着问题改改完能验证效果凭感觉改改完只剩折腾。最后再分享一个我自己一直在用的小方法每次写完一篇文章我会用手机读一遍把卡顿的地方、需要返回看前文的地方、看不清楚的地方全部记下来然后一次性改掉。这个方法比看任何设计教程都管用因为真实的阅读感受骗不了人。
返回列表