受Jason的邀请看了你的原型文件，提出一些个人的看法仅供参考：

原型设计的问题：
* 活动详情1和2如果是同一个页面，可以在一个页面上完成，拉长整个页面即可。
* 在Axure上做移动端原型，你可以将尺寸缩小一半，这样方便查看和编辑。
* 一些组件上下没有对齐，左右间距不一，这些是应该避免的

功能、业务问题：
* 创建——邀请成员页面，是活动详情点发布后出现的页面吗？如果用户不想分享第三方平台，是不是少了“直接发布”？
* 有一个功能不完成的地方，就是你发起的活动有人报名后，在哪里查看？是否要批准或拒绝？相应的，你参加了活动，是否被允许通过？在哪里查看？
* 基本业务逻辑问题：是否用户必须下载App且登陆后才能参加或发起活动（这是一个成本很高的用户阻力，让相关朋友们都先下载App本身就是痛点）？用户是否可以直接在别人分享到微信朋友圈中的网页中直接报名参加？如果能，移动网页将是很重要的落地页面，需要重点设计；如果非注册用户可以在网页上直接报名，填写手机号是不是必须要经过验证？第三方登陆用户也没有验证手机号，报名时是否需要验证？或者有些活动需要验证，有些活动不需要验证，那么是不是发起活动时有相应选项？……这就涉及了一些列业务逻辑问题。

需求分析问题：
你用户定位里提到的人其实是用户角色，是用户使用你App时扮演的角色（主要用户流程），从这点看，你的分类大致合理，那么产品的功能就应该围绕着这几种角色各自如何完成自己的任务和需求来设计，最好有各自的用户流程图。

而在你App出现之前，生活中真实的用户是一直存在的，而用户定位，则应该是定位生活中的真实人群，我们通常使用“用户画像”来进行概括，比如 张小明，23岁，单身白领，在上海张江做程序员，与一老乡住在附近的租房，交际圈很狭窄，希望认识更多朋友，参与更多户外活动……以及这些人群参加活动、使用互联网的习惯和现有经验，我们能如何提供更好的解决方案。

在产品被用户验证之前，不能就直接认定现实中的人就是你的“同城活动爱好者”、“活动策划者”，而是如何让现实中的张小明、王小莉通过你的产品解决自己的问题。
首先是便捷的解决了临时性需求，留存下来持续使用，才可能演变为理想中的“活动策划爱好者”、“活动参与积极分子”。

受Jason的邀请看了你的原型文件，提出一些个人的看法仅供参考：

原型设计的问题：
* 活动详情1和2如果是同一个页面，可以在一个页面上完成，拉长整个页面即可。
* 在Axure上做移动端原型，你可以将尺寸缩小一半，这样方便查看和编辑。
* 一些组件上下没有对齐，左右间距不一，这些是应该避免的

功能、业务问题：
* 创建——邀请成员页面，是活动详情点发布后出现的页面吗？如果用户不想分享第三方平台，是不是少了“直接发布”？
* 有一个功能不完成的地方，就是你发起的活动有人报名后，在哪里查看？是否要批准或拒绝？相应的，你参加了活动，是否被允许通过？在哪里查看？
* 基本业务逻辑问题：是否用户必须下载App且登陆后才能参加或发起活动（这是一个成本很高的用户阻力，让相关朋友们都先下载App本身就是痛点）？用户是否可以直接在别人分享到微信朋友圈中的网页中直接报名参加？如果能，移动网页将是很重要的落地页面，需要重点设计；如果非注册用户可以在网页上直接报名，填写手机号是不是必须要经过验证？第三方登陆用户也没有验证手机号，报名时是否需要验证？或者有些活动需要验证，有些活动不需要验证，那么是不是发起活动时有相应选项？……这就涉及了一些列业务逻辑问题。

需求分析问题：
你用户定位里提到的人其实是用户角色，是用户使用你App时扮演的角色（主要用户流程），从这点看，你的分类大致合理，那么产品的功能就应该围绕着这几种角色各自如何完成自己的任务和需求来设计，最好有各自的用户流程图。

而在你App出现之前，生活中真实的用户是一直存在的，而用户定位，则应该是定位生活中的真实人群，我们通常使用“用户画像”来进行概括，比如 张小明，23岁，单身白领，在上海张江做程序员，与一老乡住在附近的租房，交际圈很狭窄，希望认识更多朋友，参与更多户外活动……以及这些人群参加活动、使用互联网的习惯和现有经验，我们能如何提供更好的解决方案。

在产品被用户验证之前，不能就直接认定现实中的人就是你的“同城活动爱好者”、“活动策划者”，而是如何让现实中的张小明、王小莉通过你的产品解决自己的问题。
首先是便捷的解决了临时性需求，留存下来持续使用，才可能演变为理想中的“活动策划爱好者”、“活动参与积极分子”。