「Design Comment」是一个对设计稿中的文字注释进行索引的工具，它以项目为单位检索所有设计稿中的注释。它的目标是帮助界面设计师在复杂的设计过程中更好地发挥注释的作用。
问题分析和定义
我通过调研和分析完成了对 Design Comment 的产品初期定义，包括目标问题、用户对象、基本设计原则。
方案构思
我设计了产品的整体逻辑结构，并根据现有资源情况，规划了初期的产品发展路线。
实施设计
我设计了产品所有UI和交互， 包括基础的视觉设定、组件等。
开发
负责全部开发工作，不多赘述。
界面设计师，尤其是在复杂设计项目的执行中，始终有条理地进行设计不是一件容易的事。
随着项目体量的增大设计工作内容和产出都日渐冗杂，而如今迭代式的产品开发流程造成了设计工作的时间跨度很长，两者结合无疑会大幅给设计师的工作增加混乱的可能。而目前没有太多方案着眼于将设计师的设计过程条理化。
经过分析，我认为在复杂的设计过程中，在设计师自己的工作过程里，产生混乱主要来源有两个：决策的记录，对设计表达的管理。因此我的目标就是帮助设计师更高效地实现设计过程中的决策记录和设计稿管理。
设计的主要目标是让设计师目前的设计实施过程更加条理化，具体体现于以下几点原则：
解决方案的启发来自于编程中的注释。在大型项目中，程序员通过在写代码过程中加入注释来解释逻辑或功能，用于提示自己、合作者。同时，注释信息的形式非常直观，只需在文字前加入双斜杠，非常易于接受。其实设计师在设计中也有写设计说明的习惯，只不过基本都用于设计交付，其本质概念也与注释非常接近。
在定义了大体结构后，我用 Principle 快速制作了一个可交互的界面原型用于进行可用性测试。测试内容主要包括两方面，各界面的基本交互和在典型场景下的核心流程。
对核心流程的测试比较出乎我的意料。有一部分用户在进行设计工作中需要参考(或并行)多个设计稿文件，它们甚至可能来自不同项目(例如相互关联的产品线)，这就造成了用户要在项目间切换的问题。
由于我在移动端设计的惯性思维，将 Design Comment 的结构也默认为"一个窗口到底“，没有利用好桌面端软件多窗口的优势。于是我将每个项目页设计为独立的窗口，让用户可以利用多窗口来同时兼顾多个项目。
我将所有界面根据功能划分成了定制化和模式化两组。定制化组的界面主要承载 Design Comment 的主功能，个性定制程度高，短期的可变动性低，因此需要自己设计和实现这些界面（如索引注释的项目页面）；模式化组的界面主要承载常见的通用的功能或形式，可变动性高，所以可以采用现成的开源组件库来“拼装”界面，以省去设计和开发的时间（如布满表单的设置页面）。
由于目前产品的体量很小，我出于设计和开发的方便只对需要的部分定义了简单的组件系统；随着后续迭代的进行，各项功能的增加可能会使设计系统成为必要，到时可以根据具体情况定义一套较完整的设计系统，使 Design Comment 的整体更统一。
我的访谈结果表明，极少有设计师只创建唯一的设计稿文件，在一个项目或版本里按功能或任务分别创建设计稿文件是常态（Sketch和XD表现为文件夹结构，Figma有专门的项目组）。因此以项目为基本单位索引项目内所有设计稿的功能，更加符合目标设计师的基本需求和工作习惯。
筛选是索引中必不可少的功能，当注释条目多时，他能帮助使用者高效地寻找到目标注释。而通过标签扩展注释的功能，使索引筛选的使用体验得到了提升。而且标签在注释中并不是必要的存在，新手用户可以在不知道的情况下正常使用其他功能，高级用户则可以通过自定义标签来进行个性化且高效率地索引。
根据辅助工具的产品定位，DC的预想使用情景是在用户使用设计软件的同时提供辅助。因此设计软件会占据屏幕大部分空间，DC需要在小尺寸窗口中正常提供功能。而在用户放大窗口专注索引功能时也要提供符合大窗口的布局。所以DC根据窗口的尺寸提供了响应式的布局。（在埋点数据中也包含了对窗口尺寸数据的记录，以更了解实际的使用情景）
我的访谈结果表明几乎所有对象都会有晚上进行设计工作的情况，还有少数人会始终开启系统暗色模式只是因为觉得好看，像Sketch也提供了暗色功能。因此为这些用户提供暗色模式是非常合理的。（而且对设计来说只需替换一套基本色，对开发来说颜色本身就是一套变量，实现成本都很低）