The user interface framework will provide user interface controls or “widgets” — buttons, text fields, drop-down boxes, and so on. Knowing what set of controls you have to work with and what they look like is obviously important for design and prototyping. For the purposes of visual design, it is also good to know the degree to which the look-and-feel of the controls can be adjusted and customized, and what mechanisms are used for managing the page layout.

The technology framework that will be used for implementing the user interface can impose constraints on your designs. In particular, different web application frameworks can vary widely in their capabilities. For instance, some frameworks offer the ability to present modal popup dialogs, while others do not; older frameworks may not support partial page refreshes, requiring entire pages to be reloaded to show new data. The Oracle ADF framework, as of the current writing, does not offer any means for disabling or hiding options in pull-down menus.

If the framework chosen for your product has limitations, you will need to be aware of them and find ways to work around them — but these workarounds can often impact usability. If the problems are serious enough, you may need to reconsider the choice of framework, and it’s better to discover and decide this early on in the project, rather than later, after most of the product has already been built. Thus getting a good understanding the framework and its capabilities and limitations is a critical early step in user interface design.

In some projects, UX designers may have some input into which user interface framework will be chosen for the project. But in most projects, technical architects choose the technology stack — the set of frameworks that will be used to develop the software, including the user interface layer — based on technical considerations, cost analyses, political factors, and sometimes, personal preference. The UX designer, who is typically brought in at a later stage in the project, is then left to design interfaces that are implementable with the chosen technology.

The choice of user interface framework should be decided upon careful consideration of the requirements, or at least the best known understanding of the requirements at the early stage of the project, and ideally a user experience designer should be involved in determining those requirements.

If you’re running an organization and your staff gets their work done using an enterprise application, you’ll naturally want to increase their productivity. Or, if you’re running a community-driven website that relies on user-generated content, you’ll want to encourage participation and repeat visits. Especially in a business setting, some of the tasks that have to be done are often tedious or unpleasant — well, it is work after all.

But there’s one class of applications that tends to have little difficulty keeping users intensely focused and always coming back for more: Games.

Games are fun diversions, of course, and yet a lot of the actual tasks that players do in games are actually quite repetitive and often difficult. If these tasks actually led to any result in the real world, they would probably be considered work! In fact, some people really enjoy playing games that are highly accurate simulations of other peoples’ day jobs — flight simulators, for example.

Some people think some of the things that make gameplay addictive can also be applied to other kinds of applications. This is called gamification, and it’s currently a hot trend.

What makes games addictive?

First, there’s the voluntary nature of game-playing: People are more likely to enjoy something when they’re choosing the activity (unlike work, nobody’s forcing you to play a game).

Second, games have goals and rewards: You want to get to the next level, and it’s satisfying when you finally achieve it. Some games have elaborate systems of rankings, and as your skill improves, you get promoted; other games might revolve around “quests” for various “items” that are desirable for any number of reasons. And winning the game is ultimately the most satisfying reward.

Third, as players achieve these goals and rewards, there is a sense of progress and and an awareness that the player’s skill is improving.

Fourth, most online games are multiplayer games, and so there is an element of competition. Many people are driven to be the best, and they want to win against other players. There is pride and social recognition in being at the top of the “high scores” leaderboard.

Lastly, multiplayer games are a social experience, whether you’re competing head-to-head with other players, or in some games, forming cooperative teams. For some people, games are a way to spend time and share social experiences with friends and family.

If these ideas make games fun and addictive, then can some of those ideas be brought to other products like enterprise applications and websites, and will this make those products more fun and addictive? It depends on the product and its users, but often the answer is yes — as long as it’s not done in an overly gimmicky way.

StackExchange, a programming question-and-answer community website, is enormously popular. Much of that popularity today is due to the vast amount of content that often shows up at the top of the search results for programming-related queries. But how did they get all that content? It was created by the users, and a clever incentive system had a lot to do with it. On StackExchange, users accumulate points for successfully answering questions and earn “badges” as recognition of achieving certain milestones. Some badges “unlock” special privileges, like the ability to moderate the community. Users with lots of points and badges enjoy respect and status for their contributions to the community.

Rewards systems can be effective for work that is easily measured. But you can breed resentment if the rewards system is not seen to be reliable or fair. Creative work is particularly difficult to reward because totally objective metrics for measuring “quality” and even productivity are often impossible to define. For example, how would you create an algorithm to judge the attractiveness of an artist’s logos? Or if programmer A took two hours and wrote 100 lines of code to solve a problem, and programmer B took one hour but needed 200 lines, who is more productive?

One proxy for quality is popularity; on a community-driven website, you can let users “upvote” or give points to other contributors to reward them for good contributions. When the community is large and active, this system can be quite effective. This sort of peer voting is more problematic in a workplace setting, though. Asking employees in small teams to judge each others’ work and hand out rewards rarely results in objective evaluations and can exacerbate office politics.

Reward systems are always well-intentioned, and yet they often lead to unexpected and unintended consequences. In a business environment, management will inevitably use these systems as a metric for judging and comparing workers’ performance, even if that was not the original intention. And metrics-based incentives encourage workers to game the system, to the detriment of the organization and its customers. I’m aware of one technical support call center that measured the time spent per call and disciplined workers whose average time per call exceeded a certain target. While the scheme was intended to reduce costs, it only had the effect of forcing workers to do anything possible to reduce call durations. So rather than try to actually resolve callers’ issues, workers would unnecessarily forward calls to someone else or even give faulty but short answers so that they could hang up as soon as possible. This only led to an increased volume of calls from angry customers!

Competition can be a powerful motivator for some people; sales teams have used competition (such as salespeoples’ results and rankings being posted in the hallway) as a motivator for years. But competition can be a turn-off for many others. If you structure the system so that there is only one “winner”, then you’ll have one happy winner and the rest of your users will be unhappy losers. And on community websites, competition tends to discourage newcomers: How can a new user possibly compete against the obsessive-compulsives who have been contributing non-stop for years and have 50,000 points?

So if you’re considering applying some of the ideas of gamification to your product, be sure that you understand your users, and be sure to think through all of the consequences.

Gamification can be very appealing to some audiences, and gimmicky to others. Established professionals, for instance, tend to be highly self-disciplined, take a lot of pride in their skills and accomplishments, and gain intrinsic satisfaction out of doing their job well. (They also tend to be rewarded with good salaries.) These people will be personally insulted by the notion that their work can be turned into a “game” with phony competition and incentives.

For professional users, the simple indication of progress on long tasks is probably the best reward. There is satisfaction in finishing a task, and for longer tasks, it’s reassuring to know that you’re making progress towards completion. Reading a 500-page book with 50 small chapters tends to be more satisfying than reading a 500-page book with only 5 big chapters, because there’s a feeling of completion and accomplishment when you reach the end of a chapter.

So in a data-entry-centric application such as income tax software, it can make sense to break down data-entry forms into smaller sections or pages that be checked off when complete. A graphical progress meter showing the percentage of work completed and work remaining can be very useful. LinkedIn has a nice example of just such a progress indicator on its profile editing page:

UCD makes a lot of sense, and yet in many corporate environments, there is extraordinary management resistance to involving users in the product development process. Let’s examine some common objections to UCD and how you might address them.

• “You can’t do that! That’s not the way things are done here. That’s not our standard practice.”

Gently identify flaws in the company’s current products that could have potentially been avoided if a user-centered design approach had been used. If it’s too politically sensitive to criticize the company’s products, then try finding examples in your competitors’ products, or in mass-market products you’re familiar with.

If you’re forced to use a company-wide standard project methodology, ask whether the status-quo approach has always delivered flawless results, or whether there’s potential room for improvement. Lean, competitive organizations are often willing to entertain and embrace ideas for doing things more effectively and efficiently.

• “We don’t need to talk to users. The team has experts with all the knowledge to design the product.”

You’d be surprised at what you can learn from observing users doing their work, asking what problems they have with their current system or approach, and getting their ideas on what could be done better. It’s virtually guaranteed to challenge some of your long-held assumptions.

For enterprise applications, it often sounds like a good idea to only talk to the managers who oversee the users. But it’s important to talk to actual users who work with the system, and not just their managers: The reality of the way knowledge workers really get their jobs done frequently involves workarounds and special cases that their managers may overlook (or may not even be aware of).

• “We have a very tight schedule. We can’t afford to spend all that time talking to users and involving them in testing.”

Getting the requirements right is important so that you build the right product. This will prevent the team from wasting valuable time on unnecessary features and rework. Likewise, testing the product as it is developed to ensure that it really meets the users’ needs will avoid costly disputes with the customer (for bespoke enterprise systems) or failure in the marketplace (for mass-market products) after the product is delivered.

• “We don’t have staff experienced in these user-centered techniques.”

Your developers and business analysts can learn the techniques from books or training courses, or you might consider hiring a usability consultant.

• “Marketing is responsible for talking to the customers.”

Some organizations suffer from ugly and unproductive conflicts between competing managers and departments over their areas of responsibility. Try to build consensus around the need to establish the best process for ensuring a quality product, as all departments will benefit if the product is successful.

• “We don’t want to lose face in front of our customers if our staff asks questions that we should already know the answers to.”

Users and customers are usually more impressed that the team is taking the time and cares enough to understand their needs and provide a great product. If this is still a concern, then assign experienced senior staff to be involved with the users.

• “If we involve our users and stakeholders, they will all have different ideas and opinions that will divert our project’s focus off track.”

Ensure that all proposed user requirements undergo a proper review process to ensure that everyone’s wished-for features don’t gradually sneak into the product scope (this is known as scope creep or requirements leakage) without analysis and confirmation by an authority. A process such as the Quality Gateway described by Suzanne and James Robertson in Mastering the Requirements Process is recommended for controlling the quality of proposed requirements.

• “We can’t afford to let our competitors find out about our product development.”

Confidentiality is an important concern during the development of products to be sold on the open marketplace (it’s usually less of a concern for in-house enterprise applications). Consider non-disclosure agreements. Or, if possible, instead of working with users at your customers’ sites or recruiting users “off the street” (depending on your type of product), try to find users within your own organization.

• “I don’t want someone on our team to make promises to users that we can’t keep.”

Ensure that users understand that their suggestions and feedback are important, and that the project will try to accommodate as many reasonable ideas as possible, but that no guarantees can be made for any particular feature requests. Explain that the project has deadline and budget constraints and must satisfy multiple stakeholders, and that compromises must be reached.

• “We can’t afford to test with users. They might find a fatal flaw that will impact our deadlines!”

(Seriously?)  Much better to find serious flaws early, when they can be corrected, than to discover them after delivering the product!

[ad#AdSense_Banner]