新手必看

已经用到的各种第三方框架或者教程


团队职责角色讲解

<p>[TOC]</p> <h1>一、为什么写本篇文章</h1> <ol> <li><strong>招新的时候可以参考</strong>,毕竟刚高考的同学们刚进组,可能还不了解什么是“运营人员”、“UI设计人员”、“开发人员&quot;.写这篇文章就是为了让大家对团队的不同角色有个大概的印象,也方便大家挑选不同的组。</li> <li>对于新加入组的成员可以看一下团队的协同合作,以及<strong>一个需求是怎么从想法到具体成品的实现过程</strong>。</li> </ol> <p>这篇文章的逻辑,先概述的讲一下不同角色的职责,然后再举一个具体的应用场景,来辅助大家理解</p> <h1>二、角色职责概述</h1> <p>下面由具体到抽象分职责来介绍,运营人员思考的事情比较具体,开发人员思考的事情最为抽象</p> <h2>1.运营人员</h2> <p>团队的灵感发动机</p> <p><strong>写这个之前,运营人员需要知道,咱们并不是一个大的互联网公司,所以职责界限并不是很明确,也就是说,运营人员也可以设计一些UI</strong></p> <p>主要是提供各种方案,以及各种不同的营销手段 下面写的只是举例哈,<strong>不是规则</strong>。有可能还会做一些其他事情,也不像是下面写的那么“严格”</p> <ol> <li>关注产品各项指标,根据分析报告,提出优化方案;</li> <li>制定运营策略、活动方案和推广计划并负责实施;</li> <li>运用有效的手段提升用户的关注度和活跃度,增强用户粘性;</li> <li>提供用户反馈和运营数据,从运营角度提出产品优化建议。</li> <li>审核新用户</li> <li>当客服</li> <li>写一些推文 等等</li> </ol> <p>平时可能会学习并用到的知识,看一些互联网app或者网站的运营策略,比如什么时候出活动呀,如何增加用户体验度啊等等</p> <h2>2.UI设计人员</h2> <p>团队的美工大触</p> <p><strong>写这个之前,UI设计人员需要知道,咱们并不是一个大的互联网公司,所以职责界限并不是很明确,也就是说,UI设计人员也可以想点子,想一些运营的点子</strong></p> <p>下面写的只是举例哈,<strong>不是规则</strong>。有可能还会做一些其他事情,也不像是下面写的那么“严格”</p> <ol> <li>用户界面设计;</li> <li>负责界面、图标、动画等素材设计;</li> <li>协助完成一些交互设计。 等等</li> </ol> <h2>3.开发人员</h2> <p>团队的想法实现者</p> <p><strong>写这个之前,开发人员需要知道,咱们并不是一个大的互联网公司,所以职责界限并不是很明确,也就是说,开发人员也可以想点子,想一些运营的点子,设计一些UI</strong></p> <ol> <li>git协同合作</li> <li>小程序编程实现各种产品方案</li> <li>在运营人员忙的时候审核新用户</li> <li>在运营人员忙的时候当客服 等等</li> </ol> <h1>三、具体场景举例</h1> <p>下面举一个具体的应用场景实例来解释: 【在论坛功能中,当用户发布了一个帖子后,有其他用户对其进行评论了,此时<strong>通过微信的“服务通知”功能在微信上通知用户</strong>他的帖子有人评论了,并且也在小程序里推送消息通知。】</p> <h2>对于这个场景下不同人员的职责,以及需要考虑的事情</h2> <p>下面由具体到抽象分职责来介绍,运营人员思考的事情比较具体,开发人员思考的事情最为抽象</p> <h3>1.运营人员的职责</h3> <p>运营人员要思考的事情和用户以及小程序的整体体验最为密切,也最为具体,所以最先介绍,让大家由易到难的理解不同角色的职责 对于这个场景<strong>【通过微信的“服务通知”功能在微信上通知用户】</strong>。运营人员要思考的是,</p> <ol> <li>需不需要通知用户</li> <li>如果需要通知用户。是只在小程序里通知用户(方案1);还是既在小程序里通知用户也在微信里通知到用户(方案2)。哪种方式用户易于接受</li> <li>不同方案的优缺点各是什么,比如在本例中:</li> </ol> <table> <thead> <tr> <th>方案号</th> <th>实施方案</th> <th>优点</th> <th>缺点</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>只在小程序里通知用户</td> <td>如果有太多回复不会打扰到用户,只在用户想主动进入小程序查看时才会看到</td> <td>可能小程序的流量会少一些,因为用户毕竟只是在想起来的时候才看看</td> </tr> <tr> <td>2</td> <td>既在小程序里通知用户 也在微信里通知用户</td> <td>可以增加小程序的流量</td> <td>如果评论通知过于频繁,用户可能会不喜欢,更甚者会直接关闭通知</td> </tr> </tbody> </table> <h3>2.UI设计人员</h3> <p>对于这个场景<strong>【通过微信的“服务通知”功能在微信上通知用户】</strong>。UI设计人员要思考的是, 设计怎样的通知样式用户使用起来更方便。 在具体一点就是,假设运营人员在前面的决策中选择了【方案1|只在小程序里通知用户】。</p> <h4>对于本例,UI设计师思考的事情之①</h4> <p>是否要在“我的”图标上加个小红点,以及是加小红点还是具体未读通知的条数</p> <center>![“我的”图标上的未读消息小红点](https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/66442da5994a9cec96504618112c1bce)</center> <center>图1 “我的”图标上的未读消息小红点</center> <p>如果要加小红点,那小红点的样式是什么样子的,<strong>样式1</strong>上图那种只有一个小红点的样式、<strong>样式2</strong>下图左边那种超过99条显示99+、<strong>样式3</strong>下图右边那样超过1000条才简略显示,1000条以内显示数字</p> <center>![小红点显示具体未读通知条数](https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/9a218134b31f0cef14ea20cc4ff7b259 "小红点显示具体未读通知条数") 图2 小红点显示具体未读通知条数</center> <h4>对于本例,UI设计师思考的事情之②</h4> <p>消息的图标需不需要加个小红点,以及小红点的样式(样式同上,不在赘述)</p> <center>![](https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/0f8334b84a0dc711ce889d6c84cd8ad5) 图3 “消息”图标上的未读消息小红点</center> <h4>对于本例,UI设计师思考的事情之③</h4> <p>点击进“消息”板块后,具体的通知样式是什么样子的,是下图4,还是图5,还是其他样式</p> <center>![](https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/4ba1b807a614ee1ba782a6090bdbe82b) 图4 消息通知卡片样式一</center> <center>![](https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/4799b365974febb839f80f2498920bb0) 图5 消息通知卡片样式二</center> <h3>3.开发人员的职责</h3> <p>对于这个场景<strong>【通过微信的“服务通知”功能在微信上通知用户】</strong>。开发人员要思考的是,</p> <h4>①.提前编码</h4> <p>在知道这个需求后,先写一个版本的代码,此时应该是运营人员刚决定用哪个方案,但是方案还没细化。UI人员更是可能还没想好具体样式是什么样子的,但是开发人员在方案基本清楚后,就可以写代码了。这样可以保证写80%的逻辑代码和页面渲染,方便后续UI设计师设计出良好的样式后,可以只注重样式上的修改,而非再从头开始写逻辑代码。</p> <h4>②.具体完善</h4> <p>当UI设计师给出成品稿时,开发人员就可以按照成品稿尽量还原出UI设计师设计出的样式和逻辑。</p> <hr /> <h3>关于本文</h3> <p>创建时间:2021.7.26 参考链接: 创建者:快乐小隆</p>

页面列表

ITEM_HTML