Incorporating user experience #ux in your daily tasks

Lot has been talked about usability of user interfaces be it a website or a desktop app or even a mobile app.The term 'Usability' is mostly associated with the ease of use of a software and its user interface.However, after undergoing few courses/training on Usability I have felt the need of incorporating it not only in your software but in anything that has a user interface.

'A picture is worth a thousand words' , holds so true here.Anything if represented pictorially is much faster to understand to a human. Few examples that I have incorporated my usability knowledge into, may justify the above statement :

Example 1 -> Leave Plan representation : Say I have a vacation plan that looks too big looking at the date range but is actually not that big as it sounds , since there is a work from home, long weekend and few official holidays n between in the plan.

Say the plan is :

• Work from home from 17 to 21st Oct 2014
• Leave from 22nd to 31st Oct 2014  where 23rd, 24th are declared official holidays(Diwali)

So, the date range of absence from office is looked at, it is : 17th - 31st Oct which is like 14 days. If applied as above text , the chances of it getting approved are less and may require an explanation.

However, applying it as a pictorial representation may avoid confusion leading to lesser chances of rejection/modification of the plan.Here s the pictorial representation of the plan:

The above picture helps to :

• Express the plan smartly
• Quick and clear access to the leave plan
• Avoid locating the text in the mail and then reading it. 

Lately when I encountered a difficulty in remembering leave plans of my peers I realized, had it been a pictorial info it would have been quicker and easier to refer to.

Some may be already using it while some may feel, the above example may not be worth spending so much time in doing a minor task such as applying a leave.That s absolutely true, but with the above example I just want to focus on the importance of usability and its application to your day to day tasks.

Also, I spent a total of 7 mins in making the above image (Message me to know how @garimakalra25 ).

Example 2 -> Minutes of Meeting : One of our retrospective meetings involved discussion around the process of parallel tasks of two sub teams(Development and QA) within our team. Discussion involved the tasks that each team would be doing in parallel in all the phases of development cycle. After the meeting minutes of the meeting had to be published across the team. I volunteered for it and here is what I came up with :

I agree, that the above is not a rocket science and is a simple flowchart made using MS Office Smart Art.Many of you might be already using it at places, but the focus here is the pictorial representation of a 5 step process. The process was result of minutes of meeting and many would have used paragraphs/bullets to explain it, failing half of the readers to even go through it.

Example 3-> Use of shapes/pictures in documentation to avoid long paragraphs and allow fast interpretation of the content: Once while preparing a document for one of my projects I was suppose to add a text as : "A fuel tank attribute, A can have 3 status's Green,Red,Yellow based on its current inventory level and boundaries for different status's are as follows :

Green: Greater than X

Red: Less than Y

Yellow: X-Y

'A' will be decided based on current inventory level of the tank.So if current inventory level is somewhere between X and Y , then A will be Yellow.

The above paragraph was replaced by a picture as below :

• Studies have shown that humans look first at pictures and then at the text.
• Most of you must have seen the pictorial representation before even reading the text , in all the above cases.
• Another advantage of using pictures is that once you are able to visualize what the text is trying to state, you feel more connected and comfortable with the text too, improving the overall user experience and usability of the content.

Conclusion : Usability can be applied to almost all of your daily tasks, provided the main goal of conveying the actual information that is intent of the task is not defeated.

Tried but Failed: Usability Learning Experiences

Tried but Failed:  Usability Learning Experiences

1.Adding drag n drop feature to a functionality which can otherwise be performed by a simple button click: 
A functionality to assign certain entity to a user could be done with a simple selection of the entity and clicks add option.
In our application, we tried to make it more sophisticated by adding a drag n drop option to do this. So now user had two options to do the same action and this is how they look:

 

Differences in both designs:

Design 1:
1.Old typical look and feel.
2.Number of steps to complete the task was one step more than Design 2.
3.Cheap (Cost wise) to implement.

Design 2:

1.More latest in look and feel.
2.Number of steps to complete the task was one step less than Design 1.
3.Expensive to implement.

Any guesses for which option you think was used more??

Well! It is Design 1.Due to its ease of use and intuitiveness, design1 was more used.
Drag n drop is more sophisticated in look and feel and is also easy to use otherwise, but in this case:

• Lack of intuitiveness: User had no clue that drag n drop was also a way of doing the same action. The green add/remove icons on the right hand side of Design 2 were displayed only when user clicked on the entity and dragged it.So even if the user was told this way of doing the action, in user-training, it was not intuitive enough. So user couldn't recognize and rather had to recall each time of this option. As a result user used option he/she could see at first instead of remembering how to do it. 

• Not very easy to use: Drag n drop works in a way that , the source is supposed to be dropped at the target. So it works well when distance to drag is shorter and the target is bigger. In this case the distance to target could be bigger and not very easy for the user to keep dragging till that distance.

Lessons Learnt here were:
•Heuristics/Principles of a subject are important. They can be avoided at times but cannot be ignored. In the case above, one of the major design principles of design “Shorter distances bigger targets" was being avoided.
•Visual affordance: A design should be intuitive enough visually such that user doesn't have to recall about its functionality.

2. Giving "+Detail" option in a table: 
"+more”, "+details" have been lately used to display details on demand. At first glance user can see only the information that user can absorb and can see more info on request if he/she is interested.
We implemented this feature in one of the grids/table displaying data of reports generated by the user.
At first glance details shown were: Report Name, Time of Report Generated, Type of Report, and No. of rows in the report.
There were various filters available which could be applied in a report. But there was no way of seeing it after the report was generated except downloading the report and opening it to see what it contains.
Best solution crafted to address this issue was adding +Details with the every report displayed. This is how it looked:

As a team we were really excited to design this feature. We thought this feature will be quite helpful to the user as there was no way of looking out the details earlier than this was implemented except downloading the report and opening it.
However, it is still a doubt whether users are actually using it or not. We are assuming that most users are not using it since this section is not being well maintained in the sense, that any enhancements done to the filter section (on the left side of above screenshot) needs an effort in this newly designed details section as well.
But this effort is not being put as it is termed as "low priority" and as a result it has become stale / outdated not being at par with other functionality.

Lessons Learnt here: It is good to know your users and interview them before the designing phase, however it is very difficult to have access of actual users especially in a project where your client is not the actual end user.
The challenge is to understand what works and what does not with the end users when there is a limited/no access to the actual end user.
One way to understand this without having access to the end users understands user patterns through analytic. There are ways to record user actions/clicks. This data can further be used to analyze success/failure of a feature/functionality.
I have no experience to share on this area yet. Shall keep this blog posted if at all I get a chance to work on this area.

3.Accommodating additional information in tool tips instead of adding columns to the UI:
An important principle to be kept in mind is that users don’t learn/ remember too much information present on the UI.
One of the articles I read related to User Experience describes it really well. It associates user experience with the snowplow. Below is the, very interesting portion taken from that article:

“Let’s take a moment to ponder the humble snow plow. It’s a device of unquestionable value. It keeps roads safe and can be called upon in snowstorms and blizzards to clear paths to otherwise unreachable locations. 
In many areas around the world it’s an essential public safety tool.But if you owned a snow plow, would you drive it to the corner grocery store? Or to work every day?
Probably not, unless you lived in Antarctica. Most of us live in climates that require the use of snowplows only periodically, during the worst weather conditions – if at all. 
In fact, many people have never benefitted from a snow plow. But where they’re needed, they’re indispensable.
So what does this have to do with user experience and interface design? Think of building an interface with a great deal of unnecessary information and capabilities as the metaphoric equivalent of using a snowplow for one’s daily commute. 
Sure, it gets you there – but what portion of the capabilities are actually needed? Would a smaller, more efficient vehicle work just as well? Is it possible to achieve the goal without firing up the heavy equipment?”

Packing too much information on an interface causes confusion and most of the times users get distracted with extra information resulting in poor user experience. This is what happened with our web app.

There was a requirement to show type of an entity displayed as a column in the table. A user should be able to know type for each of the entity Open inventory, Delivery, Sales, Close Inventory ([1] Screenshot above) displayed as columns in the table.
The values (6000, 3675, 7897 and 7000) in [2] in above screenshot could be of Type A, Type B or Type C. So it was required to display its type.

[3] In above screenshot shows the horizontal scroll giving hint of number of columns already present in the table.

Two solutions were proposed: 
1.Add type column for each entity. There were 4 entities so in all 4 columns were required to be added.
2.Display type as a tool tip on each entity. So when user hovered on value 6000 its Type will be displayed in tool tip.

Differences in both designs: 

Design 1:
1.Uses more real estate.4 columns are to be added which will increase the horizontal scroll even more.
2.Not very easy to use. As the entity column is towards the left and to know its type user has to scroll to extreme right.
3.Displayed upfront on UI.

Design 2:
1.Used less real estate. No columns need to be added.
2.Comparatively easy to use. No need to scroll just hover on the entity to know its type.
3.Information is hidden until the user mouse hovers.

Any guesses for which option you think was chosen??

It is Design 1. The main reason was information was upfront present on the UI.
I strongly recommended Design 2 but couldn't understand the choice of Design 1 as the solution chosen. Snow plow principle described above can be related here.

Lessons Learnt Here: 
You can work on information to be shown or removed, if you get to know the following:

• What’s most needed
• by the greatest number of users
• in the greatest number of high probability use cases.

You can move or remove elements and functions that are less important, which is also called design for probabilities vs possibilities.

Conclusion : At times you may craft  best of design as a way of doing thing but it still may not work with the users/clients.So if you have heuristics or data to prove that your design will work the best it will be more helpful to get it approved.

My Journey to Usability

This is my first blog and starting off has been really challenging. So many thoughts are coming to my mind to make this blog the most insightful one possible. However that seems to delay my writing to endless time, probably. Hence, here I go…

All of this started with the term Usability. A term, I had heard earlier, but didn’t bother to know its significance as it was of no importance to me in my work until I got a task that changed my approach towards this term.

How it originated in our team: As a part of my project I was testing a newly migrated UI for our web app. By migration here I mean, only the look and feel of the app was being changed and not the functionality. It was purely UI testing and not functional. While testing we maintained an excel sheet of bugs that I found that was shared across the involved team. As the days passed by I filled up that sheet with a number of bugs that my developer kept on fixing. However, this task was taking more time than what we actually thought/estimated for, which usually happens with most of us. :)

The management decided to sit and analyze the reasons for all the delay happening. While doing this activity, one task they did was observing the pattern of bugs and found that most of the bugs were not actually bugs but a difference in UI that user expected and that he/she actually observed. This triggered a thought: “Why is it that the user didn’t expect the same thing that we developed or why didn’t we developed same thing that user might have expected”. This was googled, and all searches led to things like: User Centered Design, Usability, User Experience etc..

Next step was how to understand it and achieve it in our app? My manager found a related course HFI-CUA and decided to send 2 of us for this course. At first I was apprehensive about this topic itself leaving aside course, its fee, course structure and my experience which was 1.5yr at that time.

About HFI-CUA: It is a 10 days course which anyone and everyone with usability bent of mind (noticing way users do things their patterns, ease with which they do things, user preferences) can do. There’s no minimum experience/designation required to do this course. Details of the course can be found on their website. HFI-CUA

After completing the course: Few things that need to be addressed before going forward:

•    The course in no way makes you an awesome UI designer.
•   Usability in no way means you will learn latest UI technologies.
•    Course in no way teaches you mobile designing or anything like that.
•   Design cannot be learnt. So do not go to this course with this expectation of learning design.

All the above bullet points were the expectations that we all had from the course but nothing alike happened. However, other amazing things happened. Those were:

Amazing Thing 1 : 

Putting into practice whatever we learnt from the course. In order to do that we modified actual User Centered Design process that we learnt in CUA course. The process we learnt and that we used was:

Though we skipped Step1 - User Centered Analysis part as we didn’t have access to actual end users, still it is a very important part of User Centered Design .In our case the requirements given were by the client and there was no/less scope for understanding the actual user need of the requirement.

 To elaborate more on why this Step1 is very important: Most of the times when we are designing something we are actually redesigning it. That’s because it exists in some way or the other and we are only designing a new way/approach to do it. Therefore, before you start designing it is very important to do Need Finding:

• The way users are doing it currently.
• What are the challenges/hurdles they face doing it the way they are doing it.
• What is their motivation of doing that task?
• Is there a need to redesign?

As a part of Step2 & 3 (Design and Usability Testing) we created low fidelity wireframes (Non-working prototypes that give an idea of UI and how it works).These mockups were shared with client before actual implementation and asked for their feedback. Any changes/feedback(s) given by the client were done in the final implementation.

Benefits of implementing this process:

• No UI changes after the implementation.
• Both the teams onshore/offshore were on the same page in the sense that everybody could now have a visual view of what was being said and done.
• Client was more than happy to see this extra effort of creating and sharing mockups which enabled them visualize what they wanted before it was actually developed.

Amazing Thing II : 

Usability became a practice. It took a lot of criticism and effort to get acceptance for a field that looked so simple and obvious, but trust me it was all WORTH IT .

Initially, Usability as the term implies looked so simple and obvious to everyone that no separate resource was required to get it done, leaving aside a so called “Expert”. No body except few thought making mock ups could in any way help the team; however we practiced it against all odds. There were times when people thought making wireframe was a complete waste of time and they could implement a feature in that time while mock was still being done.

Few Lessons Learnt here were: 

• Keep a low fidelity wireframe really a low fidelity one. DONOT spend too much time in making early prototype so that team rejects the complete usability process altogether.
• Keeping things simple is easy said than done. People say what they developed is very simple because they have developed it and they know how it work and expect everyone to know it. For instance see at the below picture : 

Q: What do you see at first glance?

A: Some see a rabbit with ear and some see a bird with beak.

Why do all people not see same thing. This is what happens with our designs.

By now usability was so much talked about that every member somehow looked at things with user’s point of view. Client too, was happy with the results of this process and started adding usability related enhancements to our sprints.

Few examples of my work done to improve usability of the web app for which I am working as a QA: 

Example 1: As a part of my project, we were developing calendar functionality, where a user could configure events for particular date. Initially we developed a design where, to add a new event we gave a button on the top right of the calendar view thinking it will be clearly visible on the top. (Figure 1)

Before : Figure 1

The feature was successfully developed and while in testing phase, I was standing behind one of my testing peer, waiting for her to complete the task she was doing as I wanted to break for tea. While waiting for her to complete I observed that each time she wanted to add an event she would click on the date for which she intended to add a new event. After clicking she realized that event has to be added using the Add button which was on the top right corner. This increased number of clicks and also the design didn’t match her mental model. This was a redesign opportunity and I decided to get this small but significant change done.

The re-design was to match user’s mental model and get an event added by clicking on the date itself. Re-design not only saved user clicks, it also saved user from selecting Date of the event which user had to do in the earlier design. In contrast in this design the date field was pre populated with the value of date on which user clicked to add the event. (Figure 2)

After : Figure 2

Example 2: Another requirement was to accommodate 5 pie charts in a single screen. Following are the before and after designs of the same screen:

Before: All the pie charts were simply put on screen as per the screen size.

 After : 

The pie charts were categorically grouped and placed such that one of the pie charts of the group was in maximized state and others were miniatures which when clicked on was swapped with the maximized one. So user could choose which pie chart to focus on.