【雨友第四期】雨友APP 第一期UE评审 --97928.com

关于雨友项目想法的胚胎：

当你经过8小时的工作，拖着疲惫不堪的身体回家，然后在地铁站出站的那一刻，发现外面下着瓢泼大雨，你无奈地看着地铁站外的熙熙攘攘的撑着雨伞的人群，希望对方能发现世界上有你这样一类人，需要他们的同伞共济，但是你因为各种原因不敢上前一步，比如内向、比如不好意思、比如怕对方拒绝或是觉得自己不怀好意，或者是你有伞，有与对方共享雨伞的需求，但是怕对方是坏人、是骗子、或者根本不需要你的帮助……这时候，多么希望存在这样一个 平台，可以给这些好心人发布接受雨伞分享需求。

这就是雨友的胚胎，我们希望有越来越多的人，可以通过雨友来奉献自己的爱心，给需要帮助的人提供自己力所能及的一份力量。进而，让这个社会多一点善意，多一份信任。

上期我们对雨友 APP V1.0的需求、功能进行了简单的梳理，对雨友的内容结构进行了简单的规划。其中主要包括： 账户管理版块、 求助版块、个性需求版块、诚信体系版块、供求信息发布版块。

还对雨友的主要场景进行了整理：

1、 用户发布可以共享雨伞的需求

2、 用户接收到周围愿意分享雨伞的信息后，回应接受分享的需求

3、 用户恶意发、接受需求的惩罚，以及判定依据

4 、用户分享过程中的陌生环境解决方式

5、 用户快速注册

一、雨友 app V1.0只做一个功能：就是LBS 平台下雨伞社交功能。

考虑到雨友 app是一个不稳定场景下使用的工具，所以此次设计我们抛弃了繁琐冗余的设计理念。我们的目标是，你打开 app就能一目了然。我们主要从以下方面满足这个目标：

（1 ）首页简单陈列入口

（2 ）列表页LBS多维度+关键词搜索

（3 ）用户详情页 ，雨伞社交

（1 ）在首页中，我们在界面上的只有 我有伞?和我没伞?的入口。通过这2个入口，我们可以快速的达到“ 共享”和“求分享”2个目的。

（2 ）首页的背景，我们设置为最近3天的天气预报。这么做的目的，可以促使大家每天看天气预报的习惯，提升我们 app的活跃度。

（3 ）首页的上方，有我们的标语，雨友-与你同行，提示大家：有雨的时候，可以通过雨友找到与你同行的人。传达了我们雨友 app的正能量和公益性互帮互助的初衷。

（4 ）首页下方，是快速进入入口，有首页、我有伞和我求伞大厅，以及我的账户。

（1） 进入这个页面，大家可以非常详细的看到。页面名称是大厅，为什么要叫大厅？因为我们希望有很多人参与进这个具有安心感的、类似候车大厅的感觉。

（2 ）下方是搜索栏，搜索栏可以搜索?目的地和起始地，这样可以快速找到符合你路程要求的人。

搜索栏下方是3个搜索维度：

按时间???主要使用场景为，按时间倒排，也就是最新一条排列在最上方

这个维度的效果呈现，是为了避免发布比较早的（即基本已经失效的）排列在前面

按距离???主要使用场景为，按用户的地理位置进行排列，最近的排在最前面

这个维度的效果呈现，主要是这样做可以方便的找到身边的雨友

按目的地???这个就是要结合地理位置和目的地一起用的功能了

这个维度的效果呈现，主要是一般离得近，目的地相同的话，基本同路

（3 ）接下来就是列表的具体内容：

每一条主要显示用户必须的信息

比如用户头像，昵称，以及?路线和距离

（1 ）这个页面就是列表页点击以后进入的页面，这个页面，是用来联系雨友的。

然后还是起始地和目的地信息的展现

起始地和目的地，是为了再次确认该用户与你是否同路，或者，你是否愿意与ta同路

（2）接下来的评价，是为了给双方构建沟通桥梁以及一点沟通前的认识基础。

（3）然后接下来如果你觉得，这个页面上的信息，你都接收完毕了，那么你可以选择：

a ?电话联络他??直接电话联系

b?用文字联系他??在下方类似短信息一样的输入字体

c?用语音联系他??类似微信

二、群友对页面的建议及看法

1.目前我们的 app中分成了4个入口，首页、有伞、求伞、我的账户，那么关于 app以后的扩展，我们要如何解决呢？

A：扩展时，将有伞和求伞进行合并，然后会多出一个雨友分享的入口，可以分享一些音乐和心情。

2.首页是否需要个对话的提示入口，比如直接显示附近有伞以及求伞的人，这样可以快速使用其主要功能。

A：目前雨友间的对话入口，放在了用户详情页。不过这个功能可以考虑。

3.是否需要在首页有分享？

A：分享是指公众账号登陆还是指用户把目前的使用雨友的状态发布到分享 平台？

前者是个非常必要的功能。

后者因为分享的内容，有可能会是他的当前地址，可能会涉及安全隐私，不过在今后会考虑。

4.是否需要在首页显示登录入口？

A：首页保留登录入口，对游客来说没有意义，登录会放在联系雨友的时候的流程里。

5.我的账户的名字，听起来会有支付宝的感觉。

A：考虑更改，暂定“我的雨友”

6.关于是否需要添加按性别来搜索？

A：增加该功能，会有约炮软件的趋势；虽然“约炮”不是雨友的行为，而是用户行为，但是在设计上尽量避免，因为是公益性的，不过在后期，会考虑开放更多的条件方便用户筛选，比如性别。

7.没有艳遇，为什么要分享伞呢？

A：因为你接受了帮助，那是一种正能量，所以会有很大一部分人还是会进行正能量分享。

8.列表页面，默认的排序规则是什么？

A：优先按距离排序，其次按时间，最后按照路线。

9.求伞大厅的时效性是怎样的？

A：用户在列表页中看到对方后，需要与对方进行沟通，然后才会知道对方是谁，对方如果不应答，就说明没有帮助的需求。

10.是否要提供类似起始地-目的地的搜索？

A：想法不错，但是同起始地的很多，同目的地的不会很多，而且太远操作难度大。

11.关于增加一个字段：距离我xxxx米，因为看地图不直观，而且费流量？

A：这个已经在列表页中显示过了，用户觉得这个距离能接受才会进入现在这个页面的；?地图不直观，费流量，这的确是个问题，会在以后考虑进行优化。

12.点击地图上的某一个人，用户就能进行对话吗？

A：关于对话，用户可以在点击任何列表页中的一条记录，或者地图页中的一条记录进入的页面。

13.关于用户详情页面要达到目的？

A：这个页面要达到的目的：1、 让双方有一个沟通的过程，以便同路的时候，不会太尴尬；2、如果用户间沟通不靠谱，可以马上反悔，降低沟通不顺带来的影响。

14.雨友是个服务 平台，那是不是应该有服务记录？

A：服务记录可以增加使用率，可以激励用户，值得考虑。

15.是否需要增加趣味性？

A：在下雨这种特殊的场景中，趣味可能体现于设计感，与实际情况更贴切。

16.是否需要网上评价机制？

A：这个是为了防止一些临时违约的人，当然防君子不防小人。

三、本期总结

在大家的积极讨论下，我们对雨友 APP V1.0的UE有了一个初步的想法和建议，我们将在一周的时间内，对我们之前的UE做修改，然后再与大家进行交流。希望大家能通过雨友 APP，能对产品设计有一个初步的学习。

本文由人人都是产品经理原创，转载请注明出处。

非常感谢以下人人都是产品经理2群 群友们的积极参与。排名不分前后（按出场顺序先后排序）

参与者：达令(主持人)、jacky、柠檬稣、喵了咪、果果、豆腐、酱油、大湿兄、Cecilia、凯文、天天、怪兽、COLIN、bool、小蒲、圐圙、有关部门PM、Nick、Dihong、大龄PM