User Experience Design: The complete design process of nearby tweets revision

UX case study:designing a user-focused web App
Brian Cray All rights reserved
Author: Brian Cray
Translator: UCD translation GROUP, BOHEMIA
Original address: http://briancray.com/2010/01/26/ux-case-study-designing-user-focused-web-app/

This article records the full design process of the nearby tweets revision. Web developers and businesses expect to get some inspiration. Users are more interested in finding the things that are hidden in these designs. Of course, I would like to know your thoughts and feedback at the end of the article! OK, let's get started.

The cause of the story is this ...

It all started with the first iteration of the nearby tweets, designed to make it possible for local people, businesses and businesses to get in touch with each other in a simple way.

But product development has never been perfect, only constantly iterative-product quality depends on user recognition. Therefore, the opportunity to borrow UserVoice to do as fast as I can contact with the user. Through UserVoice, users can vote on the revision of nearby tweets.

Nearby tweets users ' main needs

1. Default Area
2. Save keywords and locations
3. The annoying "drawer."
4. Catalog Manuals
5. Mobile version
6. Tweets automatically refreshed
7. Shielding users
8. Shielding Area
9. Follow characteristics

Choose which features to implement

Although all users ' requests are reasonable, I have to arrange what I can do according to my resources and schedule.

Move the version to the back row.
There is already a web version now, so take a wait-and-see attitude to the mobile version. Because of the need for more resources and a new round of consideration, temporarily lack of energy.

The catalogue manual is also going to the back row
The market is flooded with a number of Twitter catalog manuals. My development space is not big, but in automatic matching geographical area, has always been my, now is, the future is also. (See Twellow, Wefollow, and just tweet it)

The rest of the features that come
The rest of the functional requirements are on my schedule, and before I start the UI design, I have to sort them out a little more clearly.

Reduce design Scope

In order to keep my route, I developed 3 requirements for nearby tweets:

1. Get user feedback . After receiving a small amount of user feedback, I quickly released the first version of the nearby tweets, using this interesting, useful project to test the big shot. Through this revision I want to get as much user feedback as possible in the design process. Use Twitter,uservoice and other resources to conduct private and public testing.
2. The nearby tweets are built to be more robust . Although the focus is the first version of the advantages, there is no expansion of the underlying functionality. This nearby tweets will provide core functionality for user preferences, as well as advanced search.
3. keep the nearby tweets simple . All along, we have struggled to keep nearby tweets simple and to make it simpler to experience.

Next, I set the design goals

Allow users to view nearby Tweets at will and allow them to adjust when needed.

Translating concepts into UI design
To keep nearby tweets simple, I've drawn up 2 sets of UI design concepts: "Progressive disclosure" and "Lazy registration"
Implement progressive disclosure on UI design

Progressive disclosure advocates the use of advanced and infrequently used functions in a second screen (inconspicuous place), making the application look easy and error-prone--jakob Nielsen

It should be noted that the second screen can be understood to hide the function.

Tweet settings

For each tweet, "who said what" and "who said" is the key, so I keep the tweet like this.

However, there are other requirements for users, who want to be able to focus on someone, block someone, or even block areas. Such advanced features cannot be crammed into the tweet area. Progressive Disclosure's ideas came in handy. These 3 features are displayed when the user moves the mouse over each tweet. Just like this:

Region and Keyword Modification window

A user who first visited nearby tweets was looking around. So in the home page only show "Tweets nearby xxxxx about yyyyy." Is enough.

But what happens when users want to search for new areas and new keywords? You will find that the area and keywords look like point links. When the user wants to modify this information, a pop-up layer appears after the point link.

Rather than let the user see the search box and other heap of filter conditions, overwhelmed, rather than just give a "change" button, the purpose is clear. Click on the button and follow the next steps. The actual entire area is point-only, in order to increase the user's point area.

You will notice a button called "Use the map" in the area pop-up layer. There are two purposes for setting up a map in the UI: First, give the user a sense of location, and provide advanced search functionality through progressive disclosure.

Regional search using interactive map to complete

The first glimpse of the map will reveal that it is behind the nearby tweets, creating a virtual environment for the user area that scrolls through the tweets as search results.

As the user searches the area, the nearby tweets flash aside and the map becomes the main window. This can be done on a map when it is not used, subtly using it as a background for nearby tweets and exhaling it when needed.

User Preferences

As a classic demonstration of progressive disclosure, users can add save areas, keywords, and even more preferences to make nearby tweets better. To improve the user's preferences, let's see how it works.

Lazy Registration in the UI
A user may never touch preferences, but can still appreciate all the benefits. What are you going to do? Lazy registration is a growing UI trend that reads data from the user before and automatically completes the known information.

Passive preference
Although nearby tweets are not registered, it also has a preferences page for users to configure. The "lazy" section extracts a collection of user preferences.

• Each time the user switches the area, it will be automatically saved
• Each time a user searches for a keyword, it is automatically saved
• The main UI allows the user to block someone or an area

Default Area
Although the user can set the default locale, it is not usually necessary. Nearby tweets automatically get user locale information and do not require a user to do so unless he wants to customize it.

Handle User Requirements

Default Area
Nearby tweets are not always able to find the user's location, so sometimes you also need to manually override the default area. I think there are many ways to solve this problem, such as adding a "set to default" option next to each saved area, but there may be many more links out there that make the interface redundant.

I decided to keep the "set as Default" feature in User preferences. Where I use space to show this option. Each saved region can be set to the default region. As shown in figure:

Saved keywords and regions
I use "current" instead of "saved" because it is more appropriate. Keywords and regions are saved like bookmarks, but work like browser history.

Automatic scrolling of tweets
It is difficult to control the refresh rate of new tweets. I'm conflicted: if it's too slow, there will be users who think nearby tweets aren't working, but too fast for users to read. After some user testing, I found that the speed of 3 seconds was just right.

Not everyone's reading speed is the same, automatic refresh frequency can be used as a user preference. According to analysis, in addition to 3 seconds, 30 seconds, 10 seconds, 5 seconds and 1 seconds are also very common.

Shielding users

Shielding Area
How to shield the area is also a difficult problem, because you have to compare the area of the tweet and the blocked area. The problem is that when users block "Ohio Columbus", the publisher's area is Columbus. Although people may clearly distinguish between these two are the same area, but in the computer, "Ohio Columbus" does not mean "Columbus".

Next if I assume that the user only wants to block the exact match "Ohio Columbus" area, or all the tweets published in "Columbus"? In order to make the software intelligent, I let the program automatically match the city name. However, another issue ensued, if two regions had the same city name, like "Ohio Columbus" and "Columbus, Georgia". So, all the "Columbus" people in Georgia would have blocked all the places called "Columbian" when they tried to block the tweets from "Columbus, Ohio." If it has become a problem, I think I have to raise my ear and listen to the voice of the user.

Focus on features