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
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.
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:
Focal point of page.
Actions from screen
Action lead to this screen
Follow up and trailing actions
Add an Item
Data entry screen
List all items
Add link on some other page.
Save, cancel, add another
Go back to previous page.
Show List all items sorted by date.
Header bar links, footer bar links, bulk upload link.
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.