Task first designing

Introduction

Software is an extension of thoughts. To develop good software it’s not enough to deal with the technicality of computers. UX is the most ambiguous module of software. UX is acronym for User Experience. It’s different from the look and feel of the software. UX helps a user to experience software through its human interface. There is nothing wrong or right while we develop UX. The only thing which matters is how comfortable a user is while he is trying to accomplish a task. A UX can be forced to users, which will require a training budget, learning curve, and productivity curve for users.

While a forced UX can work great in a controlled environment and highly process oriented tasks it may not be good to force a UX to customers. This is very true in the case of commercial websites; similar websites can have different traffic based on the UX design. A site which makes a user think and assimilate his learning will usually be turned down by a user, the moment he gets a better alternative. This means that when a user is visiting a commercial website, he has less amount of time and a high amount of task he wants to do on site. A site requiring testing the user’s patience will be slowly discarded by the user.

Users don’t mind waiting for one-time installations or non-repeated progressive loading, but they might be turned off if waiting does not yield to lowered turnaround time for the task in hand. The user gets trained to screens. Today users are spending lot of their time on various gadgets, sites, and devices. Users carry a lot of preconceived notions when they visit a site. Emerging trends like AJAX, Web2.0, mobile apps has trained users in completing lots of tasks. Users carry a sense of standard with them. This sense starts with their day to day experience with TV screens to complicated touch screens. Humans are good at classifying things and hence try to remember things using patterns. These patterns slowly get embedded in to the user’s expectation, and software not honoring existing patterns and creating benchmarks for new patterns based on the user’s task efficiency is bound to fail.

In this article we will try to approach this issue, we will try to help readers understand the importance of developing a UX with Task First Designing.

How it is different from Scenario Focused Engineering

Before we look more into Task first designing, it will be a good thought to look it in the light of Scenario Focused Engineering. Scenario focused engineering is a good tool to find out a user’s needs and help him to help us in creating better software. It deals with what a user is trying to do with software. How we can we better satisfy the user’s needs?  It requires us to write SPICER user stories.

Task based designing is not an alternative to SFD, but it can integrate well with SFD and helps to reduce the gaps between UX and various software modules. It helps to create a better abstraction on top of the underlying business modules to let the UX focus more on the prime tasks a user is going to complete on a screen and through some focal points and task fragrance on screen. Various studies have captured the user’s eye ball moment and came up with supportive data that a user is not looking at the beauty of a screen, but he is scanning the screen continuously to find out keywords. Users scan different templates in different ways, thus creating a hotspot and cold spots on the screen.

Where the problem lies

The current problem in software making is the big disconnect between the look and feel designer and the UX developer. In the past UX was often confused with the look and feel. There has also been a time where a designer was responsible for the UX. Designers are artistic people, they can do magic with color, font, images, and style, however with the lack of UX development guidelines this magic often becomes a nightmare for users. Users may be happy about the color and theme of a site, however at the same time he might find the site less productive. A designer need not be blamed for it, rather we should let a UX developer and a designer talk more often.

UX has recently picked up as a main line skill set. With the advent of SFE, agile and prototyping methodologies, UX has got much deeper attention now, which it truly deserves. Usability testing has come up as a big progressive field. There are lots of people out there who have done a remarkable job to make the UX needs understood by the industry.

A client often looks at the prototype and screenshot of a system. It’s not important to put all the actions possible on screen, the more important thing is to understand in which screen what links will appear, and most importantly what a user might be doing on that screen. What is his motto, how and why he might be landed there, and if he is there what is he supposed to do? Do we have the task fragrance on the page? Does the current screen provide and highlight links in the hotspots or are they there in the cold spots.

TFD process

Here I will try to explain how we can achieve a TFD. I am trying to focus only on the main canvas area. We can design different pages based on the table given below. However this table can be extended to put various other factors, e.g., is the current page the home page or is it part of some wizard?

We can divide a screen into the following sections:

Once we have determined what all screens we have in our system. We can create a table like the above for each screen. It will work as a checklist to find out if we are missing something in our screen. It can also help testers to come up with a test case for each screen; it is similar to the TDD approach here.