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.
