In my previous post on Task Centered Design, I have described what a Task Profile is and how to build one. Today I would like you to follow me, as I’ll demonstrate how even a seemingly straightforward and easy workflow can be further optimized using Task Centered Design principles. I promise that by the time you’re done reading this article, you will understand the advantages and see the opportunities TCD offers.

 

Example Workflow: Sign Up

Majority of business or community websites, and all SaaS sites require that users register an account before enjoying their features. One would expect that with so many businesses out there solving the same problem, the common solution is already optimized and as streamlined as can be.

Or is it?

Well, that’s what we’re about to find out. Of course, since I’m using this to demonstrate the ability of TCD to optimize your workflows, you can already suspect that the optimization in Sign-Up process is not quite that good, but let’s pretend we don’t know that, yet, and take a look at the most common Sign-Up workflow pattern.

As a new soon-to-be-member of a website, user needs to locate the Sign Up form. Sometimes that, on its own, can be challenging – but visual representation is not part of the Task Profiling, so we’ll simply state “user locates the Sign-Up form”. In the next step of the workflow, the user is asked to fill in some mandatory information, such as desired Username, Password, and Email. More often than not these forms require that users confirm their chosen password by retyping it into a second form field, so let’s count that in.

Once the user submits the form, they need to wait for a confirmation/activation email, containing a link or URL that they can use to verify their email address and activate their account. After activating their account, they can finally sign in with their new account.

This workflow can be broken down into three distinct Tasks under TCD principles:

  1. Sign Up: Locate Sign Up form, fill in required data, and submit the form.
  2. Validate Account: Open email client, locate the Account Validation email, locate the activation link or URL and click or copy&paste it into a browser to validate the account.
  3. Sign In: Locate the Sign In form, fill in required information, and submit the form to sign in.

 

Task Analysis

To adhere to principles of Task Centered Design, we need to define each of the three Tasks and their desired outcomes. Next, we will break them down into individual interactions, mark their Cost and calculate Complexity for each of the Tasks. I have described this process in my previous post, therefore I will not waste your time by going through the detailed steps again. Instead, let’s look at the completed Task Profiles.

TODPC-Old-Register“Register” or Sign Up describes step #1, in which user enters their login name, password, and email, and submits the form. After submitting the information, we should present the user with a feedback – a confirmation page which would explain that they should check their email account and follow the activation link.

This step of the process ends up with Complexity of 2, because of the multiple information the user needs to fill in. As we’ll see later on, this will become one of the key points of simplification. However for now, we need to simply document the current process with all its imperfections.

 

 

“Validate Email” is step #2, in which the user needs to open their email client, locate the appropriate email, find the activation link or URL, and use it.

As you can see, this step has also ended up being Complexity 2. There are not many inputs to fill in, but switching from one program (web browser) to another (email client), is a distraction and deserves a whole 1 point. This applies even if the user uses a web-based mail and only needs to switch to another tab – it still is a distraction, and pauses the main workflow.

Note that we do not concern ourselves with individual interactions needed to find the email in the email client. An email client is out of scope for optimizing our User Experience. We, nevertheless, acknowledge the discomfort of having to switch to it, by assigning it a whole 1 point.

 

TODPC-Old-SignIn“Sign In” is the final stage of the workflow, step #3. Having successfully activated the account and validated their email address, the user is able to sign in using credentials they’ve established in step #1.

Sign in is a very straightforward Task with only three simple interactions, therefore it ends up being Complexity 1. At the end of this Task, we want to display the user’s personal starting (or landing) page with all appropriate tools and data.

 

 

 

This concludes first part of our demonstration. We have defined three Tasks within the workflow, identified their goals and interactions, and assessed their Complexity. All three of them should be assigned Frequency of 1, because – after all – a user only registers once, and probably doesn’t use the Sign In dialog more frequently than once in a work session.

However, the whole workflow comes out with total Complexity of 5, which is really not good. It equals, for example, logging in five times. At this point, we know that we can improve on this – but how?

 

Task Optimization

That’s what the next phase is about. We all know that registration process usually works the way we’ve described above. During the Optimization phase, we will act as if that didn’t matter – because, to be honest, it does not.

There is also one more practice specific for this phase that you may find cringeworthy, but which will make a lot of sense after you’ve been using TCD approach for a while. While in the Optimization phase, all interactions listed on any of the Task Breakdowns are fluid: we can, and usually will, move them around – move them to another Task Breakdown, or get rid of them entirely. That’s okay, as long as the workflow still makes sense and does its job.

Let’s take a look at the Sign-Up Task first. We know that Complexity “2” is too high for a task that should preferably cost the user no effort at all. After all, we want users to sign up as quickly and easily as possible, not discourage them by forcing them to spend too much time and effort. Therefore, our goal is to lower this Task’s Complexity to “1”, and we have a good chance of achieving just that, since there are six interactions in the Breakdown. If we manage to get rid of at least two, the raw complexity would drop from 1.6 to 1.4, and that would lower the rounded Complexity to 1.

By looking at the Breakdown, we can identify that there’s a pointless redundancy: the “retype password”. To tell the truth, having to “retype” anything in a form is a bad practice of its own, because it leads to just as many mistakes as not using it, and it costs the user more time and effort. And we’ll save 0.1 Complexity by removing it, which brings us down to 1.5. We still need to get rid of one interaction, but we will not achieve that unless we take a step back and think about what the Sign Up is about.

Why do we force the user to validate their email address? The usual answer is: to provide first layer of protection from bots, and to verify that the email address is correct. A follow-up question instantly comes to mind: And what happens if the user fails to validate their email address? The answer is: The account will not be activated.

Which, in fact, is a way of saying that we’ll have a dead account sitting in the product’s database, with password and username and a fake email address. Most solutions also check user names to see whether they are unique or not, and that brings another problem: If a real person wants to register an account, but their selected username has already been taken by a dead account, we force them to stop and think of another. And eventually, a developer will need to think of a mechanism to purge dead accounts.

There is, however, a purely UX-based solution that kills all these problems with one stone. Or with one input field, to be exact.

Remove the “user name” and “password” from the Sign Up form entirely, and only leave a single field: Email Address. After all, that’s all what we truly need at this point. We do not need to know username and password, we do not need to create a potentially dead user account. We just need an email address, so that we can generate an Activation/Validation Email and send it.

There, problem solved. No more dead accounts, no more blocked usernames, no more need for purging them from database. And, what is most important, by doing this, we have dramatically lowered the raw complexity of this Task from 1.6 to 1.3, which translates into final Complexity as “1”. Mission accomplished.

That leaves us, however, with two critical input fields “floating around” in the workflow: the user name, and password. The only chance we have of putting them back on the map is, if we assign them to the Validation Task.

In the “Validate Email” task, user needs to open their email client, find the email and click a link that will take them back to our website. And that’s where we’ll place the “username” and “password”.

TODPC-New-ValidateIf I could read your mind, I’m quite sure I’d be able to read something along the lines of “Wait, but that’s just moving stuff around – you simplified the Sign Up, but you’re making the Validation more complex!”. Yes, I am. But note please, that the Validation’s raw complexity is 2, on the dot. One point as base complexity, and one full point for having to navigate away from the site.

If we add 0.3 points to the raw complexity by adding the “username”, “password” and “submit form interaction”, it still remains Complexity 2, rounded down from 2.3. At this point it feels like pushing numbers, but the costs are very real, and simply adding the “Set Your Credentials” form to a page that is already displayed is one of the easiest things to do – especially because of what’s next.

Remember the old workflow? Once the account was validated, we allowed the user to sign in. We were not able to prepopulate the login form fields, of course. With the new process, submitting the “Set Your Credentials” can result in two effects at the same time: First, the user account is created and activated (after all, the user has already validated their email address), and Second, we can remove the Sign In completely, and sign the user in right away.

And by removing the need to Sign In, we have effectively decreased the total complexity of the workflow by another 1 point, not to mention shortening it by an entire step!

 

Optimization Results

Let’s do the math: While the old workflow was valued at 5 points of Complexity (2 Register + 2 Validate Email + 1 Sign in), the optimized workflow only has 3 points (1 Register + 2 Validate Email). And if doing it by the numbers isn’t your thing, compare how easy and simple the optimized process feels.

But if you are interested in some numbers that further prove usefulness of Task Centered Design, and Task Profiles in particular, take a look at the following visualisation.

TOD-CostVisualisation

A seemingly simple Sign Up process was optimized by 40%, from Complexity 5 to Complexity 3. I have stated at the very beginning of this article that a user should really only sign up once. But let’s look at how significant this optimization becomes when it’s a task that the user performs five, ten, or twenty times a day.

And with that, I rest my case for the Task Profiles and Optimization for today, and thank you for your patience!