昨天已经预告了今天的主题：webapp结构布局实现方案

大家在使用app中，经常会进行各种操作，实现不同的功能间切换，可以看到不同的内容。各种内容之间切换，会通过各种动画，比如从左到右、从右到左、从上到下、从下到上、透明到不透明、缩小放大等效果。

如果大家多了解些，也许和我一样也知道native app的视图view概念。原生app通过控制视图实现内容的展现和切换，以及app的内存管理。

在手机上webapp，怎么能够模拟原生webapp的实现效果呢？

如果在进行某个操作的时候，采用最简单的加载网页，可以吗？

很明显，这样做，会导致页面刷新，出现闪屏，而且无法控制页面的原始位置，继而无法实现动画效果。

那么，你可以在app store搜索“上海房税”。看看这个webapp是否接近原生app的效果。欢迎体验。

现在进入主要环节，webapp之结构布局实现方案：

大家仔细看这个大图：

大家看出端倪了吧？

在webapp和native app中，都是有默认视图，我们这里认为是“1”。当app启动时候，用户就能够看到“1”。如果用户进行操作，就可以把“2”、“3”、“4”、“5”的内容通过动画从各自的位置移动到2所在位置，这样就可以避免页面闪动等问题。

当然，具体实现的时候，还有某些细节。

我主要列举下一下原则，供大家参考。
1：所有的模块通过如图的样式和位置布局；
2：所有的模块是平级的，都包括在一个父容器中，父容器相对或者绝对定位，模块都按照绝对定位，当然也可以相对定位，但必须都保持一致；
3：父容器位置是从“1”的左上角开始，也就是“2”模块位置，是left：320px，top：0；“3”模块位置，left:-320px,top:0;“4”模块位置，left：0，top：460px；“5”模块位置，top:-320px,left:0;(已iphone 4s为例，其他的原理一致)
4：此外，需要对各个模块，标注z-index值，显示不同的层级。避免模块在“1”区域出现的层级，避免被遮盖。

此外，还有一些罩层，都是在“1”区域，但是默认hidden的，需要的时候显示即可。

大家有什么细节问题，回复即可。我基本在线的

做手机应用，最痛苦的就是适配，适配就涉及到分辨率之类的问题。

今天就我已经了解到的只是和领域和大家分享下。

我们通常所说的分辨率，就是手机的宽和高分别能够显示的像素数。

分辨率：分辨率（resolution）就是屏幕的精密度，是指显示器所能显示的像素的多少。
比如：iphone5 分辨率6401136,也就是宽可以显示640个像素点，高显示1136个像素点。总的像素点是6401136 = 727040个 。js获取屏幕分辨率方法，window.screen.width 、window.screen.height
宽度：x方向显示的像素数，width，以window.screen.width获取；
高度：y方向显示的像素数，height，以window.screen.height获取；

设备独立像素(device-independent pixels (dips))：即移动设备的显示像素，如iphone的设备宽度和高度为320568而非6401136；

由此衍生出设备宽度（Device-width）和设备高度（Device-height）。
比如iphone 5，设备高度568px、设备宽度320px。ios通常的设备宽度是320px，而android设备宽度主流为320px，也存在360px、400px等。这也为android适配带来了巨大的麻烦。

在iphone 4s之后，出现一个retina概念。这个概念，实际是iphone自己提出来的，他并不是一个标准。

那什么是retina？就要涉及到上面说的设备宽度了。

device-pixel-ratio：width/device-width，即上面说的的缩放比例值。device-pixel-ratio大于等于2时，就是苹果所称的retina了。也就是一个显示像素宽度，可以装下2个像素以上。也就是所说的一个像素点可以放4个像素点的内容。

现在很多手机早已经实现retina了，比如魅族2，4.4寸（720px1280px），小米2，4.3寸（720px1280px）。都已经是retina屏幕。

目前，可以通过window.devicePixelRatio查询device-pixel-ratio。

此外，在讲一个我不太熟悉的概念。

PPI/DPI：PPI有时也叫DPI，表示的是每英寸所拥有的像素（pixel）数目，数值越高，即代表显示屏可以显示高密度像素。计算方式（以iphone4 为例）

由上图可知，PPI在120-160之间的手机被归为低密度手机，160-240被归为中密度，240-320被归为高密度，320以上被归为超高密度。

现在的主流手机，都已经在高密度和超高密度上上。

今天同事们在折腾android的ui切图，我还不太了解，拿这些已经积累的只是，和大家分享下。

今天上海下暴雨了，下班了走不了。

一天的工作也刚刚结束，慢慢慢下心来。和大家回味下webapp遇到的那些坑。

进过webapp开发的各种坑之后，心态坦然多了。不在那么彷徨而纠结，简单整理下这些坑，给大家一些建议。
和很多webapp团队一样，我们看上webapp，就是出于跨平台、解决开发成本的原因。

1：适配的坑

屏幕适配，主要media query实现。

ios基本就是320480或者320568，比较容易确定；

android适配就比较蛋疼，虽说主流屏幕是320、仍不免有360、400之类的，而且往往屏幕分辨率一致时也有宽不同的情况，这种情况下，高度确定就更加蛋疼。而webapp的高度必须用css确定的。这个往往又影响到内部元素的大小，XX%和固定宽度的写法，都不是很好，往往采用折中实现；

2：android返回键

在ios上，不存在返回键，可以只在界面设置“返回按钮”即可，这么做的前提是，所有页面结构塞在一个html中，通过定位、动画来实现切换；

但是在android，如果不做任何设置，返回是直接退出app的。这个自然很诟病，也有通过phonegap监听返回键事件，但是效果不太理想，往往监听不到或者重复执行操作。也有通过pjax（ajax、html5 history、pushstate）来实现，但是我还没有尝试，方法可以参考”张鑫旭“最新博客

3：phonegap

webapp虽说可以用web实现很多功能，但是硬件设备和系统本身的很多事件却无法直接调用；
比如通讯录、指南针、光感应等。现在phonegap通过系统集成，提供给了才有js调用系统功能接口，目前来说，虽然能够扑捉具体事件。但是任然不够灵活、操作速度也比较迟钝。当然，这可能是我的技术功底不足，希望大家多多指正。

4：浏览器性能

这才是webapp实现的重点。原生app，会通过主视图、试图的方式加载显示内容，包括异步加载、分布加载、内存管理等光是控制优化app性能。webapp就主要取决于浏览器本身；

webapp，而是通过app加载html文件实现，我们是在一个页面中集成所有肯能涉及到的模块，通过切换加载显示对应的数据。但是，任然发现，在数据稍多，例如25条房源数据，就显得比较卡顿了。也许和经验有关系，我也在学习，尽量优化；

ios目前对浏览器优化还是不错的，主要是android的浏览器问题。可以参考昨天的文章，回复数字”4“可以阅读。我做过一款app”上海房税“，可以app store 下载。ios体验还是可以的，但是android上一塌糊涂，基本只有60%手机可以直接运行。最后折中在android上采用wap方式实现。我发现在android上，webapp的内核在支持js上基本是坑爹，坑干爹的。很多简单的算法也很难执行。也许，可以采用云计算的方式，但是后来，时间有限，其他项目也上来了，就先到此为止。

总的来说，我现在，还是很不认同webapp，不管多少书多少人造势webapp是手机应用未来。希望说这些话的人，走过这些坑之后再发表观点，而不是为html5或者其他原因举旗而已。

讲了这么久的webapp，开始给大家讲讲我们webapp中掉过的坑，并把一切基本技巧通过微信和大家分享。

在使用app时，往往在页面滚动到头部或者底部时，会出现弹性反弹效果。在原生应用中，这个是基本的ui体验细节。但是在webapp中，却需要仔细设置了。

使用safari的时候，在页面过长时，拉到底部或者头部往往都有弹性的，这是safari浏览器特有的。

在webapp上，为了实现页面的弹性碰撞，我们可以借鉴safari的这一特性。（这里特指ios系统下webapp，android的还没有找到页面弹性的方法，欢迎大家赐教）。

页面弹性，主要应用到-webkit-overflow-scrolling这一特性
条件：

1：父元素设置-webkit-overflow-scrolling: touch;overflow: scroll;属性；
2：子元素高度要大于父元素或者设置min-height大于父元素
demo：

html部分
<div class="father">
   <div class="child">
   </div>
</div>
css部分
.father{
    height: 548px;
    overflow: scroll;
    -webkit-overflow-scrolling: touch;
}
.child{
   min-height:549px;//或者height:1000px;
}

如果不设置father的属性，即使child值大于父元素，也无弹性效果，切记。

今天接着昨天的文章开始，大家可以回复数字“3”查看昨天的文章。

今天主要讲讲iphone和android平台的浏览器，也就是webapp赖以运行的核心。

对于浏览器来说，主要工作是通过内核进行渲染，包括渲染html(常见的div、table、css等)以及渲染javascript（包括dom节点操作、交互、数据读取等等）。通过渲染，可以把代码文件通过排布好的界面展现给用户。

ios系统浏览器叫做“safari”，是基于苹果自己家的safari浏览器内核，现在也以及开源了。safari在移动领域非常普及，常见的pc双核浏览器、手机浏览器，基本基于safari内核。包括全球闻名的chrome浏览器，也是基于webkit内核，但是也有一些特别的地方，稍后继续解释。

android原生浏览器，相信大家也都用过，界面恶心，操作不流畅，速度也很慢。相信大家都会用uc、海豚来代替的。

再说说chrome pc浏览器，chrome也是基于webkit，但是他在webkit上做了很多优化，形成独立分支，并且添加了渲染的javascriptV8 引擎，合并成了Chromium，现在已经开源。这点，开发者也是很认同的，chrome 并不比safari差。

但是，这里主要来解释下，为什么android的浏览器这么难用呢？而chrome pc版却这么赞？

1：Chrome for Android和 chrome pc完全是两个不同的团队；
2：Chrome for Android并没有使用google最强大的浏览器内核Chromium；
3：以及历史原因，android版本多变，现在中国区2.35版本任然达到30%以上（umeng数据）
4：android团队，并不重视浏览器，导致浏览器不够给力，而且在android开发环境也没有很好的支持webview的实现。（虽说webview是原生软件和web结合的最理想方式，这都不给力，纯webapp就更弱）

到这里，大家应该还有疑惑：为什么google有单独推出了，chrome移动版浏览器？而且没有让人失望

我的估计是，android系统内置浏览器已经是历史原因很难纠正，那就最简单的一刀切，来一个全新的浏览器，基于v8，堪比pc版。可惜，4.2android还是没有内置这版浏览器。

但愿，android系统对浏览器多一些支持，内置上chrome移动版，更多支持webview，让我们这些苦逼的webapp开发也少走弯路，用户也能流畅些。

以上内容参考，知乎、百度、wiki等
如有疏忽，欢迎指正

刚才wikipedia.org时，突然发现wikipedia.org竟然没有webapp的描述，着实雷到了。百度还是有解释的，不过范围比较宽泛。我这里限制下，本文说的webapp是指用web技术制作的手机移动应用app。传统的手机应用app基本是基于客户端语言实现的，android是java语言，而ios则是objective-c为主，window 7 以.net为主。

为什么webapp的概念呢？

做手机应用的同学肯定有这样的感觉，移动跨平台加上屏幕适配的问题，导致移动开发工作量比传统pc软件开发要增加数倍工作量。如果利用web的技术制作app，那么就只需要一个网站，实现全平台适配，无需多平台开发，开发工作量将大大减少，效率也数倍提升。而且还有很多其他的附加值，包括全平台更新无需等待，开发技术难度小等。貌似，就是基于这几条原因，webapp在数年内，概念上一直比较火。国内外也出现了众多的webapp制作框架：phonegap、sencha、jquerymobile、jquery.mobi、Dojo Mobile等等

京东搜索”移动开发“，众多”html5制作移动移动开发“书籍闪亮你的眼睛。

在详细解释下移动webapp的实现逻辑：
1：通过android、ios平台构建一个应用的外壳，里面塞一个网页，通过网页来实现应用的所有功能。
2：网页的技术则是通过html5、css3、js技术为主，后台技术就比较多了，java、php、c#等技术都可以利用起来；
3：网页开发的技术，除了移动适配和移动的部分适配特性外，其他开发等同于pc web开发；
4：那么，也就是说webapp应用不在和传统app一样，基于客户端语言，而是基于手机浏览器内核来运行的；
5：此外，浏览器本身html5的功能机发展原因，还不能直接调取手机的硬件功能，包括摄像头、电话、通讯录、指南针、声控、光控等。那么，现在的方案是通过phonegap、sencha等框架调取移动硬件，供js调取实现的。

看到，这里，大家对webapp有了初步的认识吧？

有什么不明白的或者疑问、错误，欢迎指正。

明天，开始重点解释webapp运行的基础：手机浏览器内核。这是影响移动应用的嘴关键因素，脱了这个条件，移动webapp，是不存在的。

看到这个标题的亲，是不是觉得命题太宏大了。

是的，我也这么觉得。当然，我不想在这里误导大家，我很坦诚的告诉你，我也只是半吊子。我只想用有限的经历，和大家分享下这里面的心得。

总的感觉，产品引领技术，技术实现产品。梦想伟大，两者皆光荣。无论是程序员还是产品都乐在其中。

在金山毒霸做了近1年半的产品，最后为了女朋友还是别离了北京来到上海。又有点怀念金山了。

产品的感觉：

1：做产品就是居委会大妈，侍候好一大帮人。管产品、管数据、管设计、管交互，还有运营、收入啥的，甚至还有市场的。我基本都遇到过，确实比较大。当然，都说IT 行业CEO 产品居多，这也是其中一个理由；

2：产品，往往在自身工作之外，还有更多的协调工作，平衡技术、设计、市场等部门的各种工作的平衡。侍候好各方部门，给需要给你帮助的对方最充足而极致的准备，尽量减少合作者的工作量。当然，他们给你的回报就是，产品上线运营的综合效应。相信，这也是做产品的成就感。

3：最好，当然也是最重要的。你的人性上的特色，比如秉性、价值观都会体现到你的产品上，也会在你的产品沟通、发展、运营体现的淋漓尽致。相信，你最后的产品成功取决于此。那么，就努力先成为一个优秀的人，那么你离成功的产品也不远。

技术感受：
1：做技术，更专注于自身的工作，关注技术实现的细节。收到一个活之后，了解需求完毕。剩下和其他人打交道的机会，变得非常少，除非主动型。接完需求，赶紧躲到自己的代码角落，流程、逻辑、判断，这逐渐成了你世界的所有；

2：做技术，面临的是日新月异的技术挑战。学习，成了最重要的能力。我从去年开始做前端，遇到很多机会，让我遇到很好的学习机会。从最开始的手机wap页面，到webapp，能做的事情太多了。每天学习的东西也是指数级增长。所以，最近很喜欢“分分秒秒涨姿势”这个词。后面，还有更多IOS原生开发的挑战，共勉；

3：技术，对产品实现负责。产品不可能方方面面周到，剩下的需要自己培养产品意识和全局感。虽然自认做过产品，感觉在全局观上还是要继续努力。多多理解产品，好的技术，应该对产品的成功奉献技术以外的惊喜。

分割线一下，这是最近体会的一些唠叨。

后面有机会继续展开，当然，相信你也有很多想法。请不吝赐教。

PS最新在玩微信公众帐号，目前好友只有13个，离500个关注目标还远着。希望你可以分享这篇文章到朋友圈。让更多的人关注~

多谢，以@xiazer 之名，感谢你的分享

我还在纠结要不要写这个实习小结了~

近四个月的时间，发生了很多事情，无论是工作本身、对产品和运用的理解、公司人际关、工作流程，还是我自己的心路，都有这说不完的故事。写小结之前，我甚至考虑过要不要有一些顾忌或者部分事实的遮掩。但是现在，我决定放下这些顾虑。尽量通过小结的方式，记录一下我这近4个月的变化和成长，让大家对产品的新人也有更好的了解。想法总是不断的交汇和碰撞才有火花，一个想法换一个想法就是两个想法。

先说一下我的产品之路吧~

我一直自认为是一个简单随意的人，对自己的喜好有着鲜明的取舍。讨厌的事情，我一定不会去做，主动远而避之；喜欢的事情，我会不断挖掘自己在喜欢事情上长处，并最大化做好这一点，无论这个领域是多么的全新和富有挑战力的。我讨厌政治、我讨厌虚伪、我讨厌阿谀奉承、我讨厌拐弯抹角；我喜欢简单、直接、富有挑战的生活。

大学的四年时间，我放弃了所有的专业课程，只因为一个最简单的文字链接把我带入了神奇而丰富的互联网，就再也没有离开过。2年的.net开发，近3年的web开发~~~我一直在试图为自己找到进入互联网的入口。中间我陆续学习了c#、sql、web开发、css、php等各种语言，还有ps工具，常用的开源程序wordpress、discuz。这些东西的学习虽然给我增长很多互联网的知识和技巧，但是由于泛而不专导致了我无法实现我最初的技术梦。大四的时候，我曾经反复的考虑过我技术的能力，也曾十分怀疑我有没有必要一定要去互联网。但是，长久培养起来的互联网热情无法消灭。我没法忍受不去实现一个连接的功能、我也没法忍受在互联网的世界没有一个我创建的产品、我也无法忍受看着丰富无比的互联网没有我的声音和态度。我要亲自参与到互联网的战斗中去。

基于这个不能让我释怀的理由，我坚持着尝试寻找我在互联网的位置。直到和媛媛、小凉水的初次对话，我才确定了。原来我是进入互联网的，而且是以产品为切入点的。

和很多人一样，迷迷糊糊的进了互联网，做了产品。里面除了机遇和偶然，也有自己的坚定。但是这有一个基本的问题，我们对产品的理解基础是有问题的。

因为我们看过了太多的说教和理论阐述，对产品的很多理解都是从前人总结的基础上理解的。每次看一个产品，都回从它成功之后说起，从他成功的地方来总结这个产品，而不是关注到这个产品的前前后后的经历。我们喜欢说，某个产品怎么牛逼，怎么改变的互联网，却忘记了牛逼的产品是怎么从不牛逼变成牛逼的，牛逼的产品为什么一开始不牛逼却还能牛逼了。过分的关注成功，是我做产品之前的一个很严重的弊病。真正的产品是做出来的，而不是生下来就是真龙天子注定名扬天下；大部分优秀的产品是从一个孤儿甚至难产儿成长起来的。

在来金山之前，对产品的理解缺少很多具体而真实的理解。我按照自己对产品的理解，进行一下拆分，也相应的描述一下我的理解。希望以后可以对这些理解再加入新的理解和认识。我现在接触的产品工作不仅仅是单一而独立的工作，往往更涉及到整个产品的完整流程。这是我们会员的现状，不仅仅让我们能接触到产品的具体工作，更多的是产品线的整个流程，对我们也是极大的锻炼。

主要描述一下，我对产品中“需求分析”、“竞品分析”、“需求判断”、“原型设计”、“UI设计”、“研发需求”、“测试”、“产品上线”、“运营”、“产品调整”。

需求分析

需求分析作为一个产品诞生的最基础工作，但这些工作不是刻意而为之的。很多产品的挖掘并不是通过写需求文档就可以出来的，而是在平时的体验中一点点积累互联网认知，对特定的群体的需求有敏感的认知，逐渐提炼出的用户需求。而“需求分析”文档，只是对你的分析判断做一个整理，把想法变成一个可供参考的文本方案。所以，很多时候做产品不能依靠写需求文档来实现，需求分析文档只是对你的想法做一个整理工作。真正的需求分析是来自于产品的体验和对用户需求的敏感度。

我在会员的4个月，虽然没有经历一个完整一个全新产品的开发，所以“需求分析”这一部分并不是按照正常的产品开发流程实现的。更多的时候，我们会在产品运营中需要调整一些功能或者付费流程。这才是我现在，经历的小范围“需求分析”。说道这个问题，需求分析并不一定只是通过用户的层面来考虑，会员的需求分析，有时候也要兼顾到营收最大化来考虑，所以就需要产品体验和营收的平衡。

竞品分析

很遗憾，我现在还没有真正意义上的写过竞品分析。惭愧~~虽然我窥见过一次少娟写的棒棒堂和金山电脑医生的分析，但是我真的还没有自己完成分析过竞品分析。

但是按照我的理解，竞品分析是对自己和对手的同类产品在功能和产品上做一个全面的梳理，并且对各自的优势做重点阐述，挖掘对方优势在自己产品上实现的可能性，形成互补关系。

需求判断

需求可能来自很多方面，包括自己的小想法、用户反馈、部分用户的共同性挖掘等等 需求会有很多，点子也有很多，但是为什么并不是所有的想法都可以付诸实践了？我的理解很简单，在需求出来后，按照三个问题的方式来判断。这个需求是怎么出来的？实现了这个需求对谁有价值？我能不能得到足够的力量去实现需求并运用好这个产品？第一个问题，想了解这个需求出现的真实环境，这个产品有足够的需求而不是空中楼阁。第二个问题，想判断这个需求有没有价值，没有价值的需求是没有存活的空间。第三个问题，想确定这个需求从技术上实现的可能性，而且一个好的产品不仅仅是做出来的，也需要好的运用配套支持。

原型设计

需求确定以后，剩下的逐步推动需求实现。最简单而直接的方式，就是把需求转化为设计稿，让开发人员和设计人员能清晰的看到产品界面或者网页结果，而不是一堆如坠云里的文字符号。原型的设计，不仅仅要把基本的结果和功能展现出来，在精力有限的情况下页需要勾勒出基本的设计风格和相应的设计元素。一个好的原型设计会说法，帮你省掉很多不必要的言辞，提高效率。客户端的原型设计，重在体现产品的功能，优化产品的交互，减少用户不必要的操作和良好的反馈提示。网页版的产品，注意的因素就更多了，不仅仅要考虑整体的视觉、结构、排版文字，还要考虑产品的交互、重点元素的设置、产品的风格、模拟用户的使用习惯等等 具体的案例，下面再细说

UI设计

原型设计就是ui设计的基础，但是并不代表，原型设计就是ui设计的底稿，更多的时候，Ui会有自己的设计风格和间接，比如排版和设计元素的确定，有时候甚至会有一些比较难以搞定的设计需求，ui也需要做一些调整。这些都是可以理解的，甚至有时候UI会重新设计你的网站排版，而且也可以给你足够的理由。如果这样的话，这些都是可以接受和借鉴的。当然有时候也会遇到设计师设计出来的内容和你的需求决然相反的情况，这个时候，和很多前辈说的一样，你并不需要去否认ui的设计，而是询问ui的想法，多对的他的设计表示赞许，并提出你的想法和见解。这个时候，两个人的想法交织在一起的时候，大家都会从对方的角度思考，这样你就可以更好的推动你的修改意愿了。

研发需求

研发需求往往会写的很详细，这不是因为研发人员喜欢看长篇大论，相反，他们更愿意看到一种流程图而已，还有简单的编号的列表而已。但是一个详细的研发需求不仅仅会帮助产品理清思路、也会让研发人员有足够准确的信息，在研发不确定的时候，把文档作为标杆进行研发。

当然，研发需求也会有一些改动，这个时候需要重新修改研发文档。这是一个很慎重的问题，如果之前已经发过一次研发需求文档，那么重发修改后文档需要重新和研发人员沟通需求，避免旧需求干扰新需求。

当然，研发需求不能只靠一份文档，更多的是不断的沟通和确认每一个细节，知道研发需求和文档需求一致。

测试

我和测试的接触没有研发和ui的多，但是每一次的测试，都可以帮我重新梳理一下产品的思路，更深刻的理解产品的功能，也可以帮我认识到这个产品最可能出现的隐患，对一些需要注意的地方做好应对性准备。最重要的一点是，测试的同事会近乎苛刻的认真仔细。测试部小梅，甚至给我们提出了标点符号的中英文统一性。我当时石化~(≧▽≦)/~啦啦啦。感谢测试部同事，让我们自己对产品有了更高的要求。

产品上线

测试完毕，就是产品上线啦。这个时候是产品、研发、设计人员的高兴时刻。但是这也只是产品的开始，伟大的产品最重要的是产品后期的运营和不断调整。所以不要太过分强大产品上线的重要性。产品的上线也预示了，产品的运营和推广开始。但是这个工作需要在产品一上线就开始推行，但是推广的准备工作确实可以在产品设计研发的时候准备的。这也的话，在产品上线的同时就可以迅速进入运营状态。尤其是在互联网产品日新月异的竞争氛围里面，这个是很有必要的。

运营

如果说一个产品的上线是一个里程碑，一个成功的产品在上线后还有无数的里程碑要实现。

运营里面主要包括三大块：数据监控、用户反馈、产品体验改进。

数据监控需要对产品的各个操作进行全程的控制并有效统计使用量和来源，通过对这些具体的数据进行一些指标性的评估，包括基本的转化率、点击量、付费量、用户活跃量等等用户反馈，主要来自于论坛和微博等渠道用户的声音，这一部分用户的声音表明了用户比较重视这些事情，说明他已经影响到用户了。所以要优先考虑这些用户的声音，并在产品里面做出相应的改进。

产品体验改进，由于产品本身的设计可能出现不完善的地方或者随着时间的推移用户的使用习惯改变、互联网主流交互方式的改变，都会有一些产品的设计方案需要做出适当调整。最严重的是，一些产品体验的硬伤，一定要足够的重视，无论是涉及技术还是ui的，都需要一一推送。

产品调整

这个问题，经常会遇到，而且产品的调整频率是多的。这样一个由于互联网开发模式的普及，再就是用户需求的变化。现在产品调整，现在产品的调整主要来自于运营，包括数据的反馈、用户声音、产品体验等等。产品的调整不应该是问题，而应该逐渐成为常态，让产品通过运营和调整，更快节奏的推动产品更加优秀和完善。

上面的是昨天写的，还没有写完 。在整个产品工作中其实这部分是最重要的，虽然他只是一个产品中的中的一个部分，但他却是一个产品成功的最重要部门。产品工作的所有细节都会在产品调整中体现出现，每一次的运营调整实际上是一个全新的需求，全新的小产品。

产品调整也是产品运营的一个常见的反馈机制，只有在运营中不断根据用户需求调整和修改产品，不断的调整产品的方向，才能够让产品被越来越多的人接受，才可以让产品成功。

我以前比较避讳对产品的反复修改，这样对产品的稳定性不好，但是现在我慢慢认识到产品的调整是因为用户需求的不断改变和市场的局势也在改变。只有通过不断的调整，才能跟上用户需求，实现产品的完美。但是这并不是说一个产品不一定要通过不断的调整才能获得成功，真正的调整都是确定正确的方向和用户的需求而决定。

上面的都是我到现在对产品中的各个流程的一些理解，还要很多不全面周到的地方，还需要大家在以后的工作指正哈。