UX Case Study: Designing a user-focused web app
Brian Cray版权一切
作者：Brian Cray
译者：UCD翻译小组，波希米亚
原文地址： http://briancray.com/2010/01/26/ux-case-study-designing-user-focused-web-app/
这篇文章记载了Nearby Tweets改版的完好设计进程。Web开发者和商家希冀借此获取些灵感。用户则更有兴趣找寻这些设计中所蕴藏的东西。当然，我希望能在文章结尾理解到你的想法和反应！OK，我们开端吧。
故事的原因是这样地…
这一切开端于对Nearby Tweets的第一次迭代，目的是让当地的人与人、商家与商家之间可以经过一种简单的方式互相获得联络。
Brian Cray版权一切
作者：Brian Cray
译者：UCD翻译小组，波希米亚
原文地址： http://briancray.com/2010/01/26/ux-case-study-designing-user-focused-web-app/
这篇文章记载了Nearby Tweets改版的完好设计进程。Web开发者和商家希冀借此获取些灵感。用户则更有兴趣找寻这些设计中所蕴藏的东西。当然，我希望能在文章结尾理解到你的想法和反应！OK，我们开端吧。
故事的原因是这样地…
这一切开端于对Nearby Tweets的第一次迭代，目的是让当地的人与人、商家与商家之间可以经过一种简单的方式互相获得联络。
但产品开发向来不可能十全十美，只要不时迭代――产品好坏取决于用户认可。因而，借Uservoice的时机得尽我所能快地跟用户接触。经过Uservoice，用户可以针对Nearby Tweets的改版进行投票。
Nearby Tweets用户的主要需求
默许地区
保管关键字和地点
令人烦恼的“抽屉”
目录手册
挪动版本
tweets自动刷新
屏蔽用户
屏蔽地区
follow特性
选择哪些功用完成
虽然一切用户的恳求都合理，但我得依据本人的资源和日程状况布置哪些可以完成。
挪动版本要再往后排了
如今已经有web版了，所以对挪动版持张望态度。由于需求更多资源和新一轮思索，暂时没有精神。
目录手册也要往后排
市面上已经充满了大量的Twitter目录手册使用。我的开展空间并不大，但在自动匹配地理位置范畴，不断都是我的，如今是，未来也是。(参见 Twellow, WeFollow, 和 just tweet it)
其他的功用，一个个来
其他的功用需求都在我的日程上，在开端UI设计之前，我得把它们再梳理明晰一些。
减少设计范围
为坚持本人的道路，我为Nearby Tweets拟定了3个改版必备条件：
获取用户反应。在得到少量用户反应后我迅速发布了Nearby Tweets的第一个版本，用这个风趣、有用的项目小试牛刀。经过这次改版我希望在设计进程中尽可能多地获取用户反应。利用 Twitter，Uservoice等资源，进行私测和公测。
把Nearby Tweets打造的更强健。虽然焦点是第 一版的优势，但还是没有扩展的基础功用。这次Nearby Tweets将为用户偏好提供中心功用，以及高级搜索。
坚持Nearby Tweets的简单。不断以来，我们努力坚持Nearby Tweets的简单，并使它的体验更简化。
接下来，我制定了设计目的
允许用户随意检查Nearby Tweets，当需求时也允许他们调整。
将概念转化为UI设计
为坚持Nearby Tweets的简洁，我拟定了2套UI设计概念：“Progressive disclosure” 和 “lazy registration”
在UI设计上施行Progressive disclosure
Progressive disclosure主张把高级和不常用的功用放在第二屏（不显眼的地方），使使用看起来简单易用，且不易出错――Jakob Nielsen
需求指出的是，第二屏可以被了解为把功用隐藏起来。
Tweet设置
对每条tweet来说，“谁说了什么”和“是谁说的”才是重点，所以我坚持tweet表现成这个样子。
但是，用户还有其他需求，他们要求可以关注某人、屏蔽某人，甚至屏蔽地区。像这种高级功用就不能塞满tweet区域。Progressive disclosure的思想派上用场了。当用户把鼠标挪动到每条tweet上时，上述3个功用才显示出来。就像这样：
地区和关键字的修正窗口
一个初次拜访Nearby Tweets的用户也就是四处看看。所以在首页里只显示“Tweets nearby xxxxx about yyyyy.”就已经足够了。
但当用户想要搜索已经新地区和新关键字时怎样办？你会发现地区和关键字看上去像是可点的链接。当用户想修正这些信息时，点链接后会呈现一个弹出层。
与其让用户看到搜索框及其他一堆挑选条件，手足无措，还不如只给个“Change”按钮，目的明白。点击按钮后进行下一步操作。实践整个区域都是可点的， 目的是为了添加用户的可点区域。
你会留意在地区弹出层里有个名叫“use the map”的按钮。在UI里设置地图有两个目的：一来，给用户位置感；二来经过Progressive disclosure提供高级搜索功用。
地区搜索利用交互地图完成
初窥地图会发现它就在Nearby Tweets的后面，营建了一个用户地区的虚拟环境，将tweet作为搜索后果不时滚动显示。
当用户搜索地区时，Nearby Tweets闪到一旁，地图就成主窗口了。这样做可以在地图不必时，巧妙地将它当作Nearby Tweets的背景，需求时再将其呼出。
用户偏好
作为Progressive disclosure的经典示范，用户可以添加保管地区、关键字，甚至更多偏好设置，目的都是让Nearby Tweets变的更好用。进步用户偏好，让我们看看它是怎样运作的。
UI中的Lazy registration
一个用户可能从不碰偏好设置，但仍能领会一切优点。要怎样做？Lazy registration是一种 growing UI trend ，它能读取用户之前的数据，自动完成已知信息的填写。
被动偏好
虽然Nearby Tweets不必注册，但它同样有一个偏好设置页面供用户配置。其中“lazy”这局部抽取的是用户爱好的集合。
用户每次切换地区后，都会被自动保管
用户每次搜索关键字后，都会被自动保管
主UI允许用户屏蔽某人 或某地区
默许地区
虽然用户可以设置默许地区，但通常都没必要。Nearby Tweets能自动获取用户地区信息，基本不需求用户入手，除非他想自定义。
处置用户需求
默许地区
Nearby Tweets也不是总能找到用户的位置，所以有时也需求手动掩盖掉默许地区。我想过很多办法处理这个问题，比方添加个“set to default”的选项在每个已保管地区旁边，但这可能会多出来很多链接，让界面变得冗余。
我决议在用户偏好中保存“设置成默许”这个功用。在那我用空间来展现这个选项。每个已保管的地区都可以被设置成“默许地区”。如图：
已保管的关键字和地区
我用“以后的”替代“已保管的”是由于它更贴切。关键字和地区的保管像是书签，但工作原理像阅读器历史。
Tweets的自动滚动
在控制新tweets刷新频率时有些困难。我很矛盾：假如太慢，会有用户觉得Nearby Tweets是不是没在工作；但太快，用户又没法阅读，过犹不及。在经过一些用户的测试后我发现，3秒这个速度正好。
并非每团体的阅读速度都一样，自动刷新频率可以当作用户偏好。据剖析，除了3秒外，30秒、10秒、5秒和1秒也都很罕见。
屏蔽用户
屏蔽地区
如何屏蔽地区又是个难题，由于要去比拟tweet所在的地区与被屏蔽的地区。问题在于当用户屏蔽了“俄亥俄 州哥伦布市”，但发布者的地区是“哥伦布”。虽然人可能明晰区分这两个是同一地区，但在电脑里，“俄亥俄州哥伦布市”并不等于“哥伦布”。
接下来假如我假定用户只想屏蔽准确匹配“俄亥俄州哥伦布市” 的地区，或许一切在“哥伦布”发布的tweets？为了使软件智能化，我让顺序可以自动匹配城市名。但是，另一问题接二连三，假如两个地区拥有同样的城市 名，就像“俄亥俄州哥伦布市” 和“佐治亚哥伦布”。那么，一切“佐治亚哥伦布”的用户想屏蔽来自“俄亥俄州哥伦布市” 的tweets时，就会屏蔽掉一切名为“哥伦布”的地区。假如它已经成为一个问题，我想我不得不竖起耳朵，听取用户的声响。
关注功用
原文链接：http://blog.b3inside.com/userexperience/ux-case-study-for-microblog-app/
