这是一篇关于设计反馈和团队管理的文章，更多的聚焦在如何更好的在工作中沟通协作，以及如何激发团队的潜力，希望会对大家的工作有所帮助。
最近思考最多的一个主题是设计反馈。在我的工作环境中，我们的核心流程是每天早上都会召开内部会议。我们会回顾前一天的工作进度，并对哪些方法是有效的以及哪些方法可以改进，相互提供反馈意见。
了解如何给出反馈和懂得给出什么反馈同样重要。
最近我写了一篇关于反馈的文章，文章大致表达了如下观点：
在设计工作中，你选择不给出反馈与给出反馈同样重要，并列出了做反馈时的七条基本原则：
你不需要证明别人错了，就可以证明自己的观点你不需要用你的反馈向别人证明你知道多少你需要能够将概念反馈与详细设计反馈区分开你可以通过专注于哪些有效而不是哪些无效，来达到同样的效果负面反馈具有传染性，且会影响团队士气某些评论在私下比在公开场合更有效归根结底，这一切都是为了激发他人最好的一面在每一次回顾会议上，我脑海中不断浮现的另一个方面是反馈的标准，这对团队是最有帮助的：是更具规范性的反馈还是更具战略性的反馈，这是一个很好的平衡。
一方面，作为一个经验丰富的设计师，更容易想象出一些解决设计难题的潜在方法；另一方面，你要确保每天都在工作中面对挑战的设计师们感觉自己拥有最终的解决方案。
曾经有很多次，出于本能，我没有考虑给出战术反馈的结果，便告诉其他设计师某些屏幕的外观和表现应该是怎样的。
“当用户点击时，您应该使用下拉列表，而不是 UI 展开以显示其他位置的列表。当再次点击时，将刷新页面来展示他们选择的位置。”
我并不对此而感到自豪。战术反馈不仅限制了某些解决方案带来的创新性和惊喜感，同时削弱了团队自己提出解决方案的信心。
资深设计师自然会懂得，提出的解决方案只是众多解决方案之一。并且懂得如何用这个建议作为出发点，去集中的思考一个比原来的方案更有力、更有趣的新方案。
但是年轻的设计师可能会冒着风险，直接采用建议：他们这么做要么是因为无法立刻想出另外的解决方案，要么是他们太看重职级。（“好吧，要是我的上级告诉我应该用这个方案，我最好就用这个。”）
这些年来，我开发了这个快速的思维框架，试图迫使自己远离那些过于战术化和规范化的反馈:
01 提醒团队该页面要实现的目标（用户目标）
一开始沟通的时候就提醒其他设计师，这个页面、屏幕、功能的目标是什么——要从用户的角度来表达。这是一个很好地提醒，你和你的团队应该始终把
本文主要从审核机制、排序算法、评论运营、个性化推荐切入，思考如何让评论区更有趣。
对一个互联网产品来说，好的评论运营逻辑可以营造强大的社区氛围，助力增长，如网易云音乐、抖音。
目前市面上流行的评论样式有：平铺式、主题式、盖楼式、对话式、混合式，大家都很熟悉。
（资讯APP评论区截图）
先回忆下我们在评论区活跃的动机有哪些？
逛淘宝购物时翻阅评论，主要是想依靠评论消除疑问或做出决策；
听歌或阅读资讯APP时查看评论，主要是寻找共鸣或了解舆论风向（延伸阅读）；
当被提醒评论被回复/点赞（与己相关），情不自禁点击进入评论区。
基于上述用户在评论区的活跃动机，可将用户需求理解为：时效性（我要看最新的评论）、逻辑性（我要看懂评论）、趣味性（我要看最好玩或有用的评论）。
需求拆解完，我们来看看“让评论区FUN起来”的方案，下文主要从审核机制、排序算法、评论运营、个性化推荐切入，启发思路。
01 评论安全审核机制
同文章分发，评论的分发也需要安全审核机制，方式有：
先发后审先审后发处理优先级可遵循：流量热门的内容优先处理；重要账号的内容优先处理；高信用用户的内容优先处理。
安全审核机制和举报惩罚机制、用户头衔评级系统，共同构成评论土壤的守卫墙。除了以上官方的处理机制，还可以发挥用户“众志成城”的力量，共同维护评论或社区的内容生态，如下图：
（左：最右app，右：网易新闻）
评论清理的过程中，留意一些避免伤害用户参与积极性的小技巧。如先审后发的评论，仅用户自身可见、仅粉丝可见，待通过审核再取消曝光限制；评论删除同理，用户自身对评论仍可见，但该评论已从大众的曝光list中剔除。对一些“满怀恶意”且“屡教不改”的用户可进行禁言加黑名单的惩罚。
02 寻找优/劣质评论
以资讯APP为例，评论区展示逻辑一般有两种：热门评论（精彩评论）和最新评论，后者是以时间倒序排列，前者可以简单按点赞或回复数倒序排列，精细化运营可以有更多提升空间，整体思路是：找到优质/有趣的评论，制定合理健康的排序规则。
怎样从海量的评论中找到优质、有趣的评论，四字方针：除劣拔优。
先从文本入手，可以通过敏感词滤网和特征识别，将低质评论过滤掉，如：
有过多重复词违禁词错别字字数少、纯表情、乱码广告也是通过文本特征，可以识别出对联、打油诗、押韵、角色扮演、深度答疑、讲故事这类具有特殊的文本结构的特色评论（前期需要做浓度摸底），可在排序环节加权或强插。
另一方面，从
对程序员来说，一定要掌握 Linux 操作系统嘛？
回想下你用的 Google 搜索，淘宝购物，用 QQ、微信聊天的时候，其实这些软件和服务的背后，都是成千上万的 Linux 服务器在支撑。
对软件工程师来说，几乎一定会遇到 Linux 的应用场景，如果你无法熟练地操作 Linux ，基本上等于少了一半的功力，也少了一半的机会。
但学习 Linux 最大的困难就是，它的指令涉及方方面面，每个命令又有一大堆相关参数，学起来毫无头绪，网络上的资料也参差不齐，遇到问题简直不知从何下手。
掌握里基本知识后，对 Linux 性能优化又束手无策了，怎么根据指标找工具？或者根据工具找指标？怎么快速定位性能问题，性能分析有什么逻辑和步骤可言？
又或者还想深入学习操作系统原理，但总是记不住核心流程，不知道是否有清晰简洁的示意图辅助理解。
今天给你推荐一个“大物件儿”，1.56 米（大概双臂展开长度）的Linux 操作系统知识地图，极客时间团队出品，可谓 2019 年最硬核的 IT 技能图谱，以上问题都可以帮你解决。
只要你的工作与操作系统相关，这份知识地图定会成为你面试、工作中不可或缺的神助攻。
NO1.3 大体系，22 个模块提炼核心思路
Linux 指令太多太复杂？再也不怕了！这份包含“基础知识体系”“性能优化实战”“操作系统原理” 3 大体系，共 22 个模块的总结性内容，呈现形式为脑图、流程图、表格等。简洁又清晰，想找的知识点一目了然。
NO2.快速构建 Linux 操作系统知识体系
内容简直面面俱到，超全实用，干货满满，能帮你学习并快速搭建起整个 Linux 知识框架，查漏补缺，点亮自己的技能树。
NO3.速查常用 Linux 操作命令、性能工具与指标
非常实用，可以帮你快速定位工作中 80% 高频问题，分析问题、解决方法一步到位，放在工位上莫名有种安全感。遇到性能问题再也不慌了，按照逻辑条理分析，分分钟解决。
所谓一图胜千言，不管是技术小白，还是资深程序员，想少走弯路，快速掌握 Linux 知识体系，这份地图绝对值得你仔细研读，贴在任何地方都可以，常看常新，时时有收获。
这个程序设置为登录启动比较好
源码很简单:
//
// AppDelegate.m
// beamoff
//
// Created by ANDREI VAYAVODA on 09.11.14.
// Copyright (c) 2014 ANDREI VAYAVODA. All rights reserved.
//
#import "AppDelegate.h"
extern void CGSSetDebugOptions(int);
extern void CGSDeferredUpdates(int);
typedef enum {
disableBeamSync = 0,
automaticBeamSync = 1,
forcedBeamSyncMode = 2
} beamSyncMode;
@interface AppDelegate ()
@property (weak) IBOutlet NSWindow *window;
@end
@implementation AppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
int mode = disableBeamSync;
CGSSetDebugOptions(mode ? 0 : 0x08000000);
CGSDeferredUpdates(mode);
[self.window close];
[NSApp terminate:self];
}
- (void)applicationWillTerminate:(NSNotification *)aNotification {
// Insert code here to tear down your application
}
@endbeamoff 在github 上的地址:
https://github.com/JasF/beamoff
另外还有一个必须做的优化
“系统偏好设置” 进入”辅助功能” 然后勾选”减少透明度”
另一个:
“系统偏好设置”进入”Dock” 最小化窗口时使用: 选择“缩放效果”
another:
“系统偏好设置”进入”扩
文章将讲解通用的启发式评估十项原则，以及由其延伸出来的移动端启发式评估原则。
用户体验直接关乎产品的成败，影响到业务能否正常开展并为公司赚取利润。而可用性作为用户体验的核心，是设计师投入最多精力去探究和实践的关键点。在产品上线之前，企业往往邀请可用性专家来评估产品的体验、可用性问题，希望通过专业人员的介入，发现产品存在的体验问题并及时纠正，以避免上线后的不良后果。
本文的主题就是关于可用性专家评估产品的用户体验的常用方法——启发式评估。
文章将讲解通用的启发式评估十项原则，以及由其延伸出来的移动端启发式评估原则。文章最后会附上启发式评估表格的 sketch 文件，大家可以在文末的链接点击下载。
启发式评估是什么？
「启发式评估允许一部分评估者检查界面，从而判断其是否符合公认的可用性原则」——Jaokb Nielsen
简单来说，启发式评估是 UX 领域的一种评估产品可用性的方法或者说一组原则、标准。在设计思维及产品设计的流程中，原型和测试是其中的关键步骤，通过将想法和策略原型化并进行测试，设计师可以避免不必要的成本投入，规避掉产品中的异常问题，帮助团队找寻到正确的设计方向，以及选择最佳的设计方案。
虽然在国内，原型工具主要用来进行视觉和交互的上下游对接，但不得不承认，原型的核心作用是用于测试、验证乃至规避风险，节省投入。
不考虑商业策略和业务方向的前提下，我们一般通过创建原型以及测试原型来排查可用性问题，即产品原型是否有较严重的可用性障碍，用户能否正常完成操作实现目标。
一方面，我们通常会将原型直接投入到真实场景中，并通过真实用户的实际体验来进行测试，获取用户的反馈从而进一步优化产品的可用性。
但另一方面，限于隐私、经验等问题，用户的真实想法并不一定能够完整的传达出来。产品的可用性不能够完全依赖于没有设计知识和经验的用户来实现。因此我们通常会邀请可用性专家对产品原型进行评估，通过其丰富的设计经验来发掘问题并进行规避。
启发式评估就是可用性专家常用的一组测试标准，由尼尔森发明，共包括十条原则。尼尔森最早发明它们用于网页设计的可用性评估，后来该十条可用性原则成为了通用设计原则，即适合包括移动端和 PC 端产品，也包括应用程序到工业设计产品，而不限于某个领域。
启发式评估适合在什么阶段和情况下使用？
启发式评估并不限于某个特定的时间段，或者产品阶段，在任何需要专家来评估和验证方案的地方，都可以使用
平台产品有自己的生态闭环：供给充足，能够适配多方的需求。连接用户和产品，是平台产品的运营重点。
快手本质是什么类型的产品，想清楚这个问题，再确定运营咋搞。首先快手毫无疑问是内容型产品，其次也是社区产品。
但一个2亿+DAU的产品，肯定可以从多个角度去解读，有多重属性。这次的视角是：快手还有平台属性。
啥是平台型产品，至少是海量数据的吧，不管是DAU还是GMV，量级小的产品也没脸说自己是平台。
称得上是平台的产品，是要解决一个生态的闭环，比如上下游、B端C端或生产消费。所以，数量级肯定是很大的，产品承载的用户类型也是多样的。
一、平台型产品有以下几个特征
1. 平台是双边或多边的，供求是动态不平衡的
其实这个观点来自美团高级副总裁张川的文章，我是跟着学习的，掺杂着自己的思考。
有生态闭环才叫平台，所以肯定就是有多样的角色，比如上文提到的B端C端、生产消费什么的。
比如淘宝就是一个巨大无比的生态，不仅有买家卖家，还有代运营服务商、广告代理商、物流公司等等，这就是平台的多边角色。以此逻辑去分析，也能得出像快手这样的产品，有平台属性。
供求是动态不平衡的，平台才有价值。针对这点，川哥举例是：用户交易的时候很少在固定的时候固定的买一家店固定的商品，用户也很少同时同刻在同一地点打上同一个司机的同一辆车。
也就是说，如果双边或多边能甩掉平台自己玩，那这个平台就没价值了。平台的动态不平衡，不是追求的目标，而是特点，是呈现结果。
对于快手的「动态不平衡」，体现在供求双方在内容品类上的匹配程度。比如在高速增长中，总有多个细分品类的内容供给，小于内容消费；反之也是一样的。
这是常态，也是正常现象，运营要做的就是不断优化内容品类，不断补缺。
2. 供给是核心，且供大于求才成立
我经常举这么一个例子，如果要从零做一个招聘网站，先搞B端还是C端，也就是先搞招聘方，还是求职方。只能二选一，理论上不存在同时搞。
看似是一个鸡生蛋和蛋生鸡的问题，但其实不是。答案肯定是先搞B端招聘方，先搞供给端。
从规律上来看，面对这样供求的选择时，就先搞供给。从具体情况来看，B端招聘方更好搞，因为他们就摆在那里，可以一个个去磕。而求职者的身份是隐性的，不会写在脸上。
同理快手的运营也应该先搞供给，原因也类似于上面提到的招聘网站。
供给搞到什么程度呢，从定性非定量角度说，供给要远大于需求的。因为需要提供给用户选择的空间，这样的平台才能成立，反之平台会死掉
本文所有涉及到的大部分代码均在这个demo里面：https://github.com/sxei/chrome-plugin-demo ，大家可以直接下载下来运行。
另外，本文图片较多，请耐心等待加载完毕。
本文目录：
demo部分截图：
2.1. 什么是Chrome插件
严格来讲，我们正在说的东西应该叫Chrome扩展(Chrome Extension)，真正意义上的Chrome插件是更底层的浏览器功能扩展，可能需要对浏览器源码有一定掌握才有能力去开发。鉴于Chrome插件的叫法已经习惯，本文也全部采用这种叫法，但读者需深知本文所描述的Chrome插件实际上指的是Chrome扩展。
Chrome插件是一个用Web技术开发、用来增强浏览器功能的软件，它其实就是一个由HTML、CSS、JS、图片等资源组成的一个.crx后缀的压缩包.
个人猜测crx可能是Chrome Extension如下3个字母的简写：
另外，其实不只是前端技术，Chrome插件还可以配合C++编写的dll动态链接库实现一些更底层的功能(NPAPI)，比如全屏幕截图。
由于安全原因，Chrome浏览器42以上版本已经陆续不再支持NPAPI插件，取而代之的是更安全的PPAPI。
2.2. 学习Chrome插件开发有什么意义
增强浏览器功能，轻松实现属于自己的“定制版”浏览器，等等。
Chrome插件提供了很多实用API供我们使用，包括但不限于：
- 书签控制；
- 下载控制；
- 窗口控制；
- 标签控制；
- 网络请求控制，各类事件监听；
- 自定义原生菜单；
- 完善的通信机制；
- 等等；
2.3. 为什么是Chrome插件而不是Firefox插件
- Chrome占有率更高，更多人用；
- 开发更简单；
- 应用场景更广泛，Firefox插件只能运行在Firefox上，而Chrome除了Chrome浏览器之外，还可以运行在所有webkit内核的国产浏览器，比如360极速浏览器、360安全浏览器、搜狗浏览器、QQ浏览器等等；
- 除此之外，Firefox浏览器也对Chrome插件的运行提供了一定的支持；
Chrome插件没有严格的项目结构要求，只要保证本目录有一个manifest.json即可，也不需要专门的IDE，普通的web开发工具即可。
从右上角菜单->更多工具->扩展程序可以进入 插件管理页面，也可以直接在地址栏输入 chrome://extensions 访问。
勾选开发者模式即可以文件夹
评审会是产品开发的重要环节，产品参与人需要在这个会上对关键要素达成一致，从而才能保证产品的顺利上线。那么，评审会该如何开呢？
被怼，只能减少不能消除，减少是可以有方法，本文就讲述了一个方法，人人可做到。
PRD的评审会，是一个方案的确认会，主要讲产品“是什么”，为后续环节“怎么做”提供依据。
本文通过将PRD评审会议过程进行结构化拆解，然后将执行过程标准化，以解决PRD评审会常见问题，提高评审效率和质量。
本文主要对如下几个环节的操作进行了说明：
- PRD评审会目的；
- 会议的两大原则；
- 会前准备；
- 会议议程；
- 会后收尾。
一、会议目的
搞清楚目的是做事情的第一个步骤，因为有了目的才能有的放矢，确定原则，对方案进行取舍优化，对PRD的评审会议也是如此。
PRD评审会的会议目的有两个，一主一次：
- 最主要的是统一各方对产品方案的认知，以便项目组协同作战；
- 次要的方面是通过会议群策群力，查漏补缺。
如果主次弄混了，就会评审会变讨论会，讨论会是应该在方案确定之前进行的。
如果有大幅修改，不二审会有很大的认知不一致风险，进而给项目带来额外的成本和风险；进行二审不仅延误时间，同时还会让合作方对你能力产生怀疑。
如何评估PRD的评审会是开好了呢？
理想情况下，所有参会人员在三个方面都理解一致且认同了：方案的整体思路、关键点风险点、细节设计。
然而现实中大部分项目是不可能做到的，所以可行的标准是对产品方案：
- 整体思路理解一致且认同；
- 关键点风险点理解一致且认同；
- 对需要注意的详细设计点理解一致且认同，大部分的设计可以不记得，回头看PRD。
主要是需求目的，方案的实现思路、实现方式、实现程度、实现范围、时间计划、已知风险的理解达成一致。所谓认同，就是在对疑问进行质询后，认为方案可行。
二、会议两大原则
- 问题解决在会前；可能的问题，有预案；
- 就事论事，好的建议要吸收。
我们可以借助一个场景来理解：
有个大集团M，对某个功能的设计方案进行招标，产品方案就是针对这个招标进行的方案。
PRD评审会就是这个招标评审会，会议直接决定了你能不能拿到这个大集团合同，赚到钱。对方参与招标评审的是除产品经理外的相关方。
这时应该如何去做，才能最大可能的通过招标评审，拿下合同，限制条件是没有灰色行为。
总结起来，其实就是上面的两条。
三、会前准备
要将问题解决在会前，就需要充足的准备，一个会开的顺利不顺利，会前准备的工作可以占到80%，另外20%才是在会上取得的。
这个会前准
本篇文章通过使用、体验、研究等方式倒推「易捷加油APP」，借助 Axure 撰写 PRD 文档。与大家分享。
作为产品小白，希望通过倒推的方式，来锻炼产品思维、提升画原型的能力。同时分享在使用中获得的心得体会，欢迎提出宝贵建议。
目录：
一、文档综述
- 文档属性
- 产品综述
二、产品说明
- 产品功能结构图
- 产品信息结构图
- 产品结构图
三、全局说明
- 功能权限
- 键盘交互说明
- 异常情况说明
- 交互规则
- 数据说明
四、部分任务流程
- 购物流程
- 加油流程
五、部分功能详细说明
- 登录页/注册页
- 首页
- 商品详情
- 一键加油
- 我的
六、非功能性需求
- 性能需求
- 可用性需求
- 运营需求
七、优化建议
优化商品详情页
01 文档综述
1. 文档属性
2. 产品综述
二、产品说明
1. 产品功能结构图
2. 产品信息结构图
3. 产品结构图
三、全局说明
1. 功能权限
登录/未登录：
- 登录用户可以浏览所有页面、执行所有操作。
- 未登录用户可以以游客身份进行内容游览，可以游览商城商品。
2. 键盘交互说明
- 点击APP手机号码输入框，页面底部弹出数字键盘。
- 点击其他输入框时，页面底部弹出字母键盘。
3.异常情况说明
打断后重新打开APP：
点击空白区域或无网络情况：
无网络情况：
4. 交互规则
加载状态：
首页：
商品列表模块：
提示信息：
空状态：
页面在正常情况下，没有数据显示时，表现形式为插图配提示性文案。如需要，根据特定页面场景，增加引导用户操作的Button或链接等；
操作状态：
所有的按钮或者可点击的icon、文字均分为：可操作状态，不可操作状态两种。
其中可操作状态对应可操作颜色，不可操作状态一般可见，但为灰色，易捷加油APP没有做操作后的按钮状态变化。
5. 数据说明
四、部分任务流程
1. 购物流程
2. 加油流程
五、部分功能详细说明
1. 登录页/注册页
页面名称：登录
入口：初始登录APP
基本事件流程：
- app显示登录表单页面，表单中包含文本：①输入手机号码②输入验证码
- 用户输入11位手机号码，获取验证码并输入
- 点击登录按钮，进行登录
- 登录成功进入首页
页面逻辑：
- 登录方式：①手机号码登录②提供第三方登录
- 点击手机号/验证码登录，输入手机号和验证码进行登录
- 用户可点击注册，输入手机号码，填写验证码，设置密码进行登录，并默认“注册代表同意用户使用协议”
后置条件：登录成功/登录失败重新登录
异常流程：用户输入短信验证码错误，弹出“短信验证码错误”提示文本，2秒后消失，用户重新操作
页面内交互：
- 点击手机号、验证码输入框时，数字键盘从底部向