作为网页设计师，我们做的很多事情是交流和有说服力的。我们运行用户测试来证明我们的决定。我们创造了多种选择，因为这是意料之中的。我们写下规格，制作流程图，或者模拟每个状态，这样工程师就能得到正确的细节。我们提出批评是为了获得反馈，但也是因为我们的同行想要一个质疑我们决策的场所。
总的来说，设计从宽泛和低保真度到详细和高保真度:要点到草图到线框到模型到原型到实现。当然，我们很少这样做全部其中之一。
在早期阶段，我非常喜欢纸上素描。我接受它们的混乱，并意识到它们比线框(我很少再用了)要快得多，功能强大得多，这已经是很多年前的事了。我甚至提倡在执行评估中使用它们。在某些方面，草图是更多当你是你唯一的观众时，这是强大的，因为他们甚至不需要清晰易读。角落里那个奇怪的东西是什么？没关系，只要你们知道。你可以很快地改变排列，这意味着我在使用更高保真的方法之前，会有规律地画草图，但是很简短。
我仍然在大型项目中使用设计概要。它们不会花很长时间，而且写它们的行为有助于我思考——将高层次的、手动波动的想法提升到更实际的水平。它们记录了我在想什么，以及为什么要为未来的自己澄清。我们有时会进行设计评审。
我也写作产品简介并鼓励工程师撰写工程简报。两者都运行良好。关键是不要走极端，因为它们被称为“内裤”是有原因的。虽然为它们提供模板很有用，但我把它们视为指导方针而不是需求。既然队里没有其他人，何必多此一举呢？因为在集中化的情况下，变更更容易、更安全，最重要的是，更快。如果明天我想让我们所有的按钮都是方形的，我可以做一次，然后让它到处传播。
不是所有东西都值得拥有一个组件。有时候太早了，太容易改变。那么，什么时候是将一次性工作转化为组件的合适时机呢？当我意识到在项目N+1中需要我为项目N构建的一个组件时，我会尝试这样做。(如果Figma像宣传的那样运行，这将容易得多，并且可以从单个文件中剪切和粘贴组件到您的库中。提示提示。)
这种集中化在代码中更加重要，当我们的模拟和代码库不一致时，通常是代码胜出。要明确的是:我不认为这是一个问题。我们的规范风格指南是包含所有CSS变量的文件。我们有一个仅仅一个按钮组件，我们在任何地方都使用它。当我编写和审查代码时，我对集中化毫不留情，因为这将确保事情保持一致并易于更改。
