产品功能设计

相信我们都遇到过这些情况，看到⼀个好⽂章想评论收藏时，会提示我们先登录；在⽹上购买的商品想看看发货没，系统却提示你先登录；想进⼊后台看公司的数据都必须先登录后才可查看；有的产品提供多种登录⽅式，⽽有的却只能⽤账号密码登录… 那，登录到底解决了什么问题呢？什么情况下才需要登录？为什么地区不同、类型不同、端⼝不同所使⽤的登录⽅式也会有所不同，接下来就让我们⼀起解析⼀下登录的那些事⼉。 一、登录解决了什么问题，有什么意义？ 登录，解决了⽤户与系统间的“告知与识别”的问题；就像我们在路上遇到熟⼈，他的脸“告知”了你的⼤脑他是谁，你的⼤脑才会把这个⼈的信息、与你的关系等信息“调”出来， 你才能叫出对⽅的名字。 其实登录就是这样的⼀个过程，将现实的我们与虚拟的我们进⾏匹配——现实的我以登录的⽅式“告知”了系统对应的虚拟的我是哪⼀个，系统才能从后台精准调取相应的信息去展示给我，买了什么，能操作什么，数据是多少，每个⽤户都是不同的。 那不做登录可不可⾏呢？ 不做的话不但解决不了⽤户与系统间“告知”与“识别”的问题， 反⽽会让三⽅陷⼊混乱，产品不知道⽤户是谁，⽤户也找不到⾃⼰的信息，有些业务也⽆法操作…… ⽆论登录⽅式如何简单、流程如何优化，⽤户与系统间都需要有⼀个“告知并识别” 的过程。⽐如在社交型产品中，如果不做登录会怎样，系统不知道消息是发给谁的，也不知 道发消息的⼈是谁，这是⽆法满⾜社交这⼀需求的。 二、登录的方式有哪些，都有什么意义呢？ 1. 验证码登录 验证码登录，是当前很多产品推荐使⽤的登录⽅式，特别是移动端，也经常⽤在拉新的运营活动中，⽐如领券、领红包等。此登录⽅式的主要特点如下： 优点： 短信验证码具有时效性和随机性，相当于动态的密码，能有效防⽌登录密码被破解； 验证码登录不需要⽤户强⾏记忆平台账号和密码，降低了⽤户的记忆成本和操作复杂度，提⾼了登录效率； 对于未注册的⽤户，也简化了注册流程，提⾼了注册率； 缺点： 短信发送是需要付费的，对于有一定用户规模的企业来说成本会比较高； 因手机信号不好、手机号欠费或者第三方短信运营商的问题，验证码可能发送不了或延迟发送，导致用户无法登录，这时需要考虑给用户提供其它解决方案； 因手机号回收，可能会导致账号信息被他人使用，存在账号安全隐患； 以小红书app为例，我们看一下手机号验证码的数据流转： 功能流程： 功能点说明： 注意的点： 什么样的验证码有效，比如验证码的有效期、可获取的时间间隔、同一个手机号在同一时间段有多个验证码相同时； 被机器恶意消耗短信配额时怎么办，在pc端一般会让用户输入图形验证码、点击某一处拖动等方式来判断是否人为操作；但在移动端，为了简化流程，只有系统识别到有黑客攻击的意向时才会加入是否人为操作的判断。 用户获取不到验证码时怎么办，导致这样的原因有很多，但用户在使用时不会想那么多，这时我们就需要考虑怎么引导用户去解决他当前遇到的问题。 2. 账号密码登录 密码登录，就是我们常见的账号密码登录方式，而账号密码登录也有不同的方式，比如：手机号+密码，邮箱+密码，自定义的用户名+密码；有的平台直接选择一种方式，大部分平台会结合多种方式去登录。 （1）手机号+密码 优点： 账号便于记忆； 有利于企业获取到用户的联系方式，方便后续运营； 无大的隐形成本； 缺点：密码登录的通用缺点都有 适用于：手机号+密码的登录方式pc、移动均适用，也是当前很多产品使用的登录方式之一 （2）邮箱+密码 优点： 能获取到用户的邮箱，可用于后期的邮件推广 用户自己的邮箱，账号便于记忆 缺点： 用户容易忘记密码，记忆成本较高； 邮箱的普及率不太高，特别是老年人或者使用网路较少的人 适用于：多适用于国外的产品，或者企业内部使用的产品； （3）自定义的用户名+密码 优点：未强制获取用户联系方式，不会导致用户反感； 缺点： 账号、密码均不容易记忆； 未能获取到用户的有效联系方式，不利于后期的用户运营； 这种方式不利于验证用户身份，并不知道是否是本人在操作； 密码容易被破解。 适用于：是之前主流的登录方式，现常见于海外产品、企业级产品； 接下来我们以小红书为例，来深入看一下手机号+验证码登录方式。 数据流转： 功能流程： 功能点说明： 虽然有不同的账号密码登录方式，但以下缺点每种方式都存在： 用户记忆成本高，可能会因为忘记密码而中断登录流程，登录效率低； 登录密码属于静态密码，在一段时间内不会被改变，被破解的概率较高，存在被盗风险； 此方式只适用于已注册的用户，未注册用户需要去注册页面走注册流程；不利于新用户的引入； 要注意的点： 账号密码登录所用的账号，无论用手机号、邮箱、自定义用户名来登录，在当前平台内必须是唯一的； 忘记密码的流程，在设计时需要考虑身份验证，每个平台不同身份验证的方式不同，最常用的是用绑定的手机号进行验证，还有邮箱验证、人脸验证等； 产品在选择以哪种密码登录方式时，需根据产品的定位、每种方式的优缺点和适用场景来做选择，比如针对海外用户使用的产品，手机号+密码的登录方式就不太适合，虽然它在国内比较主流。 3. 第三方登录 第三方登录是以其它平台账号进行登录的方式，国内常见的是用微信、qq、新浪微博三个平台进行登录。 这种登录方式优点是用户操作方便，引入第三方平台的账号验证体系，对平台来说安全可靠；但缺点是受限于第三方平台，只能根据第三方平台返回的信息来填充自己平台用户体系，无法获得有价值的用户信息。 为了解决这一问题，大部分平台会在第三方登录后让用户绑定手机号，在产品设计时需根据自身情况来判定是否需要绑定手机号。 小红书第三方登录数据流转： 功能流程： 功能点说明： 以上流程为小红书移动端的第三方登录流程，未涉及手机号绑定的流程，但现在大部分平台在第三方登录后会让用户绑定手机号，将用户信息平台私有化，方便平台的用户运营。 要注意的点： 绑定手机号在用户看来只是输入手机号、验证码这么简单，但在后台需要考虑到账号信息合并的问题，该手机号已绑定过其它同平台的账号，该手机号已注册并已有自己的用户信息等情况。 因操作习惯不同，不同端口在进行第三方登录时操作流程会有所区别，比如第三方微信登录，在pc端一般是用微信app扫码进行登录，而在移动端是直接调用微信app授权。 移动端在做第三方登录时，应考虑用户未安装该平台的app怎么办，或者已安装该平台但未登录时怎么办。虽然第三方平台有相应的解决方案，但在产品设计时也应考虑到此种情况，结合自己产品的定位去引导用户进行相应操作。 4. 扫码登录 扫码登录，同指纹登录、刷脸登录等方式，是新型的快捷登录方式；适用于同一产品有多个端口的情况，比如新浪微博app和网站、视频播放产品等；优点是用户登录操作简单、更加安全（登录过程中用户无需输入账号密码，只有二维码展示），缺点是使用场景受限（有自己的app、需在移动端已登录的情况下）在产品设计时需考虑码的时效性、用户确认授权登录这一操作。 以爱奇艺视频播放器产品为例，看一下它的数据流转及功能流程； 数据流转： 功能流程： 功能点说明： 以上所列为现在使用较多的登录方式，此外近来新出现的方式还有指纹登录、刷脸登录、本机号码一键登录（app）等，每种登录方式都有优势、也有不足的地方，在设计登录流程时，需根据产品定位、目标用户、企业利益来考虑，选择更加适合的登录方式。比如企业用户更喜欢使用邮箱，但普通用户会更偏向于手机号。…

实时新闻和消息公开是最好的疫苗，及时的信息获取让我们理性认识疫情发展，不陷入恐慌中。目前丁香园、腾讯、支付宝和网易做的疫情实时新闻产品在市面上是不错的，其中丁香园的产品上线最快，最早进入公众视线。而本文就为大家分享一下，如何小步快跑，做出一款疫情时事新闻的MVP版本。 这篇文章将会分析如何设计一款疫情实时新闻的MVP版本。 MVP指的是最小可行化产品，通过MVP可以快速验证这个需求，快速进入市场。MVP设计一般来说只需要设计一个主要的功能便可以上线推广，后续再小步快跑、快速迭代完善产品别的功能。 大纲如下： 需求分析 产品功能 用户路径 产品规划 总结 一、需求分析 武汉疫情的信息和资讯这么多，你是怎么获取的呢？ 以我为例子，刚开始我花大量时间在微博上，看微博热搜和主页。但微博的信息量极大，我不得不每天花费一定量的时间来获取信息。 接着我开始通过微信“看一看”和“朋友圈”来获取相关信息，这个渠道的好处在于通过我的朋友筛选出了质量不错的信息，我可以看到大家都在关注的热点。 以上两个途径是我最开始获取疫情信息的主要途径。 但这两个途径并没有满足我另外的需求，比如获取跟茂名、杭州、湘潭这三个城市相关的最新疫情消息和复工政策。 准确来说，我需要一个特定城市的疫情实时新闻。 作为一个产品人，我开始思考这样的疫情实时新闻产品该怎么实现？只是我一个人想获取这类信息的需求吗？ 基于以上的疑问，我对5位朋友进行了简单访谈。由于只是想验证这个需求的真伪，故只抛出三个问题。以下是访谈的结果： 需求背后是因为这与每个人的利益相关，疫情对人们的生命健康、生活、工作、学习都产生了可大可小的影响，大家想打破信息的不对称，主动获取跟自己有关的信息。 访谈的主要问题为信息的获取途径和获取的信息类型，通过以上访谈，可以看到每位朋友普遍都有获取相关城市最新疫情信息和政策的需求，也有朋友告诉我几乎每天都会去微博、百度、当地公众号查看自己城市的最新消息。 需求验证了之后，那么怎么来做这么一个疫情实时新闻产品？ 看起来好像很简单，就是将每个城市的最新疫情信息整理，然后以倒序的方式排序展示。 但仔细一想，还是有很多东西需要确定。比如： 疫情信息从哪里来 信息格式是怎样的 展示的信息类型是哪些 是不是有关的信息都得展示 一个城市在一定时间内展示多少信息 信息更新时间是多少 用户如何订阅城市 用户获取信息靠自主登陆还是系统推送 如何推送信息给用户 支持分享吗、产品形态是网站、小程序还是app 由于只是想做一个疫情实时资讯的MVP设计，所以暂时不考虑别的功能，只做这个需求的最小可行化设计。针对以上需要qualify的内容，经过思考，我得出了以下确定的内容： 疫情信息来源于国家卫健委、各省市区卫健委、权威媒体 统计地方单位为省 信息格式为时间+新闻标题+新闻简介+新闻来源，以时间信息流展开 展示的信息类型为跟疫情相关新闻（不细分分类为辟谣、疫情数据、政策等，考虑到MVP设计，这些分类可以后续优化迭代再上线） 每一小时更新一次最新新闻，按照最新时间倒序新闻 产品形态是网站 用户通过扫码网站上的二维码订阅公众号 用户通过公众号查看网站，公众号一天推送一次订阅提醒 支持分享，仅支持链接分享（不支持图片等形式，与第4点同理） 二、产品功能 2.1 功能分析 疫情实时新闻MVP设计分产品后台和网站。其中产品后台的功能为模块编辑和内容管理，网站的功能为新闻展示和城市订阅。 产品后台是什么呢？产品后台是通过后台来支撑前台网站的业务。 比如前台网站上的城市数量有多少个、网站展示的疫情新闻、新闻更新的频率，数据爬取的网站等这些功能都需要后台来支撑，通过后台来控制前台的信息呈现。 在一些大公司，后台产品的角色非常重要，除了支撑前台网站业务外，还可以提高业务效率和进行数据分析，数据分析包括公司层战略分析、产品层数据分析、人员层绩效分析等。 这篇文章，我也把后台产品的设计写进来了，希望将这次的疫情实时新闻MVP设计写的更加全面。 2.2 产品后台   模块编辑（点击放大查看） 后台的模块编辑主要是为了支撑前台网站新闻展示这一模块的呈现。考虑到这只是MVP设计，后面还会上线别的功能模块、比如辟谣模块、口罩预约模块等，所以疫情信息模块是一级菜单，模块编辑和内容管理是二级菜单。 模块编辑里每个字段的定义如下： 模块名称：该名称是前台网站新闻展示的模块名称，同时也是为了区别于后面上线的模块 描述：这个描述会呈现在网站新闻展示模块名称的下方 更新时间频率：更新的时间频率单位是小时，比如填1小时，指的是1小时才会更新一次；填2小时，指的是2个小时才会更新一次 更新新闻数量：指的是系统更新一次后，每个地方新抓取的新闻数量。比如更新新闻数量是20，一次更新后，湖北、湖南、广东等分别更新20条新的新闻。（这里有个特殊场景需要讲一下，比如一次更新后，系统抓取不到20条新闻，只抓取到10条新的湖南疫情新闻，那么前台只展示10条新的湖南疫情新闻） 地方选择：后台勾选了哪些地方选项，前台网站才会出现这个地方选项 抓取网站：抓取网站里的选项内容是技术写死的。我们会提前做好调查，每个地方都会找到5-10个网站，让技术写死在选项内容里面。后台只有选了这个网站，系统才会爬取这个网站的新闻、文章 爬取关键字：可以输入多个关键字，关键字以空格隔开。为什么要设置关键字输入，而不是技术写死？因为不同关键字获取信息类型和效果不同，方便我们能根据热点和用户需求来改变网站的疫情信息类型。  内容管理（点击放大查看） 内容管理是产品的内容资源，这一块决定了用户看到什么样的疫情信息。 爬取到的内容都会在这个内容列表里，内容列表里的字段有标题、简介、来源、新闻链接、地方、时间、删除操作。 这一块也表明了用户看到的信息格式将会是标题+简介+来源+时间，用户在网站上点击信息将会跳转到该信息链接。 内容管理还提供了内容查询功能，可查询的字段为标题、地方、时间。 标题查询支持不完整标题的查询，地方查询的选项为模块编辑勾选的地方，时间查询是为了让后台操作人员方便搜到某一时间段的内容，对这个时间段的内容进行查看和删除。 内容管理板块有几个需要特别说明的逻辑： 内容列表排序根据时间倒序展示 内容缓存需要跟技术沟通，找到合适的缓存方案 技术需要保障内容的去重 删除列表里的信息需要二次确认 暂时不上线对内容列表的编辑功能，这个可以留在后面排期 关于简介的抓取，如果抓取的新闻有简介，则直接抓取新闻原本的简介；如果没有的话，则抓取文章开头的前两句话（两句话字数不超过三行，超过则只取文章开头前一句话） 2.3 网站设计 由于是MVP设计，网站界面也只是设计了城市设置、新闻展示、城市订阅和分享这四个功能，具体逻辑和交互页面如下。 2.3.1 城市设置和新闻展示 上图是新闻展示的一个原型图，从上往下分别是Banner、新闻展示、底部两个tab。 新闻展示里的信息格式由时间+标题+简介+来源组成。当用户进到网站未设置城市时，展示的新闻是全国疫情新闻。 只有当用户选择了城市之后，才能生成特定城市的疫情信息，目前仅支持用户选择一个城市。 2.3.2 订阅城市和分享 用户点击【订阅城市】后，将会弹出弹窗，引导用户关注公众号。 在这里说说产品形态为什么要选择网站。目前主流的产品形态是网站、小程序和app。 这三者的特点和优势不同。网站无需用户下载，易于推广分享，开发成本一般，可放置于公众号菜单栏。小程序用户无需下载，推广容易但不能分享至朋友圈，开发成本低。app需要用户下载，体验虽更好但打开频次低，推广分享难，优化迭代上架比较麻烦。…