今天完成的事情：

1. 看人人都是产品经理

2. 整理老大点评内容，需注意的点

3.复习原型规范

4.明确验收标准内容
明天计划的事情：（一定要写非常细致的内容） 

1.根据原型规范和验收标准，修改自己的任务

2.总结任务

3.查看师兄的项目，清楚每一个元素的认知和看法

遇到的问题：（遇到什么困难，怎么解决的） 

1.目前的方向是牢牢记住原型规范，并使用，对功能需求表的子模块和功能有清晰认知

收获：

1. 原型要求只允许使用黑白灰三色

2. 内评评审看规范，看组件，看业务逻辑是否有遗漏，看用户需求能否得到满足。真实使用场景有背景介绍

3. 登录注册等做组件

4. 根据用户story和用户场景画原型，清楚怎么做，做成什么样，给用户提供的体验是什么

5. 画原型前思考清楚业务逻辑，理清模块，清楚业务需求，明确产品给用户提供什么价值和服务

6. 原型内所有数据都要用真实数据

原型规范：

1、画原型要有流程图

2、页面间的跳转必须要有

3、输入框要有文字的限制说明

4、有交互效果的要有文字说明

5、有异议的地方都要说明

6、涉及到钱的、网站不想让用户做的、对用户有损失的操作都要进行提示

7、确认、取消按钮的左右排列问题要看网站的意愿

8、账号、密码输入框要进行文字性说明进行相关限制，保证破坏性测试时没问题

9、表格内容有限制时都要进行文字说明

10、与别人合作做事要有发邮件确认的习惯 

11、文件命名规范：【期数】产品名称-日期-时间。 （示例：【四期】编程王-0122-1825）

12、原型里不要页面里套页面。一个页面只画一个原型。

13、验证码一天只限3次，有效期15分钟

14、story与验收标准模板：

15、文字（标题、正文）行数、边界、行数限制。

16、光标移入移出、悬停、点击交互

17、图片来源的说明

18、列表的排序

19、点击区域说明

20、分页展示的数量设定

21、表单设计要注意几点：1.Label的对齐   2.错误信息的提示     3.PlaceHolder的对齐      4.确定和取消按钮位置

22、原型里的所有内容，不能任意乱填，而是应该填仿真数据

23、原型图中的文件必须遵循以下原则： 每一个文件必须放在文件夹下， 不准文件下面放文件， 一个文件里只允许画一张原型图，可以展示其他的交互动作，不允许一个文件画出来多个原型图。

24、生成的html包等文档压缩格式统一用zip

25、按钮位置：把最不常见的放左边，最常用的放右边。

26、标注时要注意标注不应该干扰视线，不要在原型上全是圆形标记和水滴标记，可采用连接线标注

27、同的功能页面，放到文件夹。

28、做PC必须要考虑到Title和Keywords和Descibition.

29、如果是网页，必须支持响应式和自适应。

验收标准：

前台验收标准

1.验标

在用户名栏输入只能纯数字，输入框失焦时，系统可以提示“用户名为5-16位，仅能输入字母或数字，且需以字母开头”

在用户名栏输入低于5位或高于16位字符，输入框失焦时，系统提示“用户名为5-16位，仅能输入字母或数字，且需以字母开头”

点击新增按钮，若用户没有模块管理权限，则弹出提示“您没有该权限！”点击确认，弹出框关闭

2.记清楚，验收标准是通过做什么，看到什么来验证需求

例子：手机号输入框字符限制次数在11位。
这是需求。
验收标准是：手机号输入框字符输入不足或超出11位时，显示“手机号码位数不对”的错误提示。
这才是验收标准，对比一下。

写后台验收标准的看一下 

1. 操作完整性：

搜索区域这部分不是只写可输入，应该保证操作的完整性。输入内容是为了搜索，不是单纯的输入。

所以应该写上，可以输入中文和英文，点查询之后可以在列表页展示对应结果。

2.公共性：

基本内容页，在我们的后台只有两种，一个叫做列表页，一个叫做详情页。正常来讲。详情页的取消操作，这是一个公共的操作，取消也并非是返回上一个页面，而是返回到列表页。

3.关键性：

验收标准的目标是为了寻找核心操作点和容易被忽视，犯错的关键点，不是把所有的操作都逻列出来。

点击什么点入什么页面，正常来讲可以不用写。

这个仅供参考 

这次写的 分三块 

操作 ：只包括跳转 

状态： 不同操作交互带来的改变  例子 按钮变化 数字变化 图标状态变化   

内容展示 ：只当前页面展示固定元素的内容 

犯错原因：写的太多了 有些不用写 跳转返回之类的 ，有些写到通用验收就可以了 。重点没描写业务逻辑；

验收标准不是功能需求表，着重点在于通过动作和结果来验证规则。

例子

比如，输入框不允许输入多少字，这是功能的描述。

而验收标准是：在文本介绍中输入超出50字的时候，不可继续输入。

注重动作，结果。 同时，验收标准不需要写的太过详细 。

对于通用的标准来说，可以是一个全局的约定。

重点在于关键的业务逻辑。