You are now reading case study for:
Overview

Mobile Application Development.

Hutchison Telecom Ltd was ready to embrace the digital age and create an mobile application of their own.

My Role

This app would provide an alternative chanel for customers to check their bills, ask questions and gain customer support instantly. Other functions such as payments reminder will also be included.

I worked closely with one designer, two developers and the project manager. I was responsible to provide the user flows, wireframes, information architecture and some part of UI designs.

The Process

Stakeholder Interviews

As soon as I joinned the team, I began by articulating the goals and target audiences for the app through a series of interviews with each team members. This  would allow me to summarize their responses across the board, and look for any inconsistencies in strategy and vision.

 

After I've conducted a few interviews with my team members, I immediately raised two red flags in my mind:

  1. No one knew what the objective of the project was.

  2. When asked about who the target audience was, stakeholder responded: It is for everyone!

 

I  asked our project manager what the objective of the project was but it was clear that he didn't know either. I knew it was important to keep everybody on the same page at the begining as it will make everything else down the line go much smoother. So, I made something up that looked very ligiminate and got everybody to agree on it. ( I think I kinda did what the PM was supposed to do...Oh well, someone has to do it.)

 

As for point two, I did nothing about it. Why? Because back then (June 2013) I didn't have the UX mind set that I have right now and it sound perfectly normal to me at that the app was for everyone at that time.

 

Flow Diagrams, Storyboard, Wireframes & Information Architecture 
 

We skipped a lot of UX procedures because A) This project had a very tight shedule and B) Some procedures will just never take place in this company due to its culture.

 

If you were looking for how I did market & user researches, personas, usability tests, visual guides...etc in this case study, you won't find them here because it simply did not take place. I also omitted the process of how I deisgned the wireframes and the information architecture on purpose because I value your time and I don't want you to read the same thing twice. Everything that is not included or omitted in this case study is well covered in my other case study

 

So well else am I going to show you?

 

Forms.

 

Forms

Why Form Matters

The attention you pay to your form reflects the attention you pay to your users. If a form was badly designed, you are communicating the message to your users that you don't pay much attention to them because obviously you didn't put yourself in your user's perspective upfront or else you would have spot the usability problems right away. 

 

It is hard to design a good formThere were tons of things to consider in a form and they could all be easy to be overlooked. If you didn't pay enough attention to your work or understand your users properly, you will end up desigining a form that everybody hates because it confuses people. When people were confused, chances are they won't fill in the form the way it was intented.

 

The design of forms requires a lot of decision making and critical thinking and I believe it is worth a case study on its own. Heck, someone had even written a book just about forms so I think my point couldn't be clearer: form matters.

 

From Web to Mobile

One of the requirements for this mobile app was to include everything that we have from our website, forms were certainly part of it. Before I joinned the team, the team has already designed a prototype for the mobile form. Picture on the left was the online version for the "Contact Us" form, the one on the right was the original version of the mobile form. 

 

 

 

 

Fonts & Styles

The first thing I noticed about this form was that the "enquiry" field has very little vertical space (The field above the grey submit button). I also noticed the fonts were quite small and it reduces the readability on a mobile screen. The reason for that was because the form labels was taking too much vertical space, in order to fit in everything on screen without scrolling the team were forced to use a smaller font.

 

I decided to pit the form labels into the form field to make use of the vertical space so that it would allow us to increase the font size. I also changed the color of the field into a lighter grey to increase readability (Translation for the field names: Name, Company, Contact Number).

 

Copy Writings

I had some concerns about the way the copy was written for the radio buttons. Here is a translation of what was written on the radio buttons:

 

Topic:

- Individual service

- Technical issue

- Customer service

 

First, the word "Topic" had done a poor job to categorize the radio fields below it. This is a "contact us" form, so in this context it would make more sense to use "Enquiry type" instead of "Topic". No one is writting an essay here.

 

Second, you might wonder what is the difference between "Individual service" and "Customer service". I had the same questions back then so I asked everyone including the PM but nobody seemed to knew the answer. However, when I suggested to remove "Individual  service " in the sake that might help users to make decisions quicker, our PM said it would be safer to have the word synchronizes with our website. Since the website was out of our jurisdiction, the "Individual Service" option will remain as it is for the sake of consistency.

 

Although I could not remove one of the confusing options of the radio buttons, I did something else to improve the overall user experience. First, I removed the fieldset legend "Topic" because I thought the radio buttons were self explanatory already. Next, I made the radio buttons inline to reduce the vertical space and I also increased the padding of the radio buttons to make them easier to select.

 

 

 

 

Adding icons

I decided to add icons next to the form fields. Not only will icons improves the overall visual of the form, icons also acts as visual cues that help users navigate the form more efficiently. Instead of reading the words on the fields, users can scan for the icon that represents the task they’re trying to do.

 

 

Icon Issues

Here is the slightly improved form. We have introduced some brand identity (the red), increased the fonts, added some nice looking icons and we have more vertical space. However, this form was far from perfect. 

 

First, the icons were placed on the right, it was a miscommunication between me and the developer. When I asked him to add icons next to the fields, I meant placing icons on the left side of the fields. I have learned a very important lesson here that I shouldn't assume everybody will understand what I meant. It is always better to double clarify than to get things wrong.

I explained to the devloper in order for icons to serve as a visual scanning aid, users need to see them before they see the form label. According to eye-tracking research, we read in an "F" pattern, so icon placed on the left will help to describe what the text on the right is about and icons on the right will serve nothing better than a decoration.

 

Serious Usability Problem
The keyboard has blocked the "Submit" button 
The "Submit" button was right below the text box

Until now, we have been working on the visual side on the form but we havn't actually try to fill in the form yet. So, I wasn't suprise to discover some serious usability problems once I did some testings on my own.

 

Take a look at the picture on the left, when you have finished imputing your text, where do you click "Submit"? The "Enter" button on the bottom right of the keyboard? WRONG. The "Enter" button brings you onto the next line. So, where is the "submit" button? Well, it was right below the text box ( as shown in the picture on the rigth) but you cannot see it because the keyboard has completly blocked it. 

 

I tried to slide the page up be that  to see the "submit" button but that won't happen becuase the height were fixed. In order for me to see the "submit" button, I have to close the keyboard. To do that, I have to hit the physical "back" button on my phone (Android).  

 

To overcome this problem, we simply add some simple scripts push the page up when the text box is focused, as shown on the picture below. That way, the "Submit" button is always visible. 

The "Submit" button is now always visible
Improving The User Experience

To ensure the user experience for this form would be as smooth as possible, one of the things I did was to ask the developer to change the keyboard dynamically according to the type of the text field. For example, when you were try to type your name on the "Name" field, the keyboard the pops up should not include any "@" or ".com". In other words, the correct keyboard should show up according to the field. 

 

By providing the right keyboard to users, users will not have to waste anytime to switch between keyboards. By illuminating any obstacles the users might face, they can truly focus on the task and what the form was intended.

 

 

 

Why would users need a keyboard that has "@" and ".com" on it when they were trying to fill in their name?
 
 
 
 
Right keyboard for the right field. I wanted users to focus on what matters to them.
Success & Error Messages

One of the things that most online form often overlooked is to provide feedbacks. In our original version, when users hit submit, the app will bring them back to the home page. There were no messages to tell the users whether they have succesfully sent their message or not. The lack of feedbacks will leave users in a confused state of mind and damage the overall experience.

 

The problem I stated above can easily be resolved by providing some simple success or error messages. It is important to always tell your user exactly what is going on as this will provide them a sense of comfort and feeling more in control. In return, they will be more likely to trust your product and the overall user experience will be improved.

 

I told our developer to add a success message after the users hit "Submit".

As for the error messages, I wanted the app to provide a visual focus effect on the field that has problem. However, our developer told me that he was late on schedule and there were other parts of the app that needs more time to work on. In the end we have a simple pop up error messages indicating which part went wrong (as shown below). Not elegant but good enough for now.

Text Overflowing Issue

I discovered this problem when we were very close to the deadline. Previously I did not think of trying to to test the form this way. The issue was when contents extends beyond the border of the box, the default setting was to hide the overflowing contents. Somehow, the app did not allow users to scroll up and down to see what they have written. This wasn't an ideal user experience.

 

The default setting was to hide overflow contents

I suggested two ways for our developers to tackle this issue. One is to set the overflow property to scroll. The other was to auto resize the height of the text box just like Whatsapp did to thier text box. However, since we were very close to the launch date when this issue was raised, we chose the first option which requires the least effort.

Whatsapp auto adjusts the height of the text box when the content exceeds the boarder, neat!
The Final Design

Below is the final design of the form. The original form was next to it for you to compare.

Let me be perfectly honest with you, I do not like this form at all. There were so many areas that could be improved, for example:

 

  • There were no focus effect when you tab on the fields. Instead, you will get a flashing vertical line that you saw from Microsoft Word.

  • You were supposed to use the keyboard to complete the whole form all the way easily by just tabbing the "Next" button, but the radio buttons in the middle of the page will force you to stop an select an option. Then you have to tab on enquiy box again to fill it in. The experience is not as smooth as it should be.

  • Maybe we should remove the arrow icon next to the submit button because it was a bad metaphor for "Submit", or maybe the submit button should span the full horizontal space so it would be easier to select.

 

There were a lot of things that I thought were important to the overall user experience of this form. But then I read a book that changed my whole attitude towards development: maybe it just doesn't matter.

 

When I asked my colleagues and families to do some user testings for me, I realised the things I thought that were important didn't really matter that much. They could all successfully complete the form without struggles. That's the moment I realised: Yes it would be nice to have focus effect on fields, Yes it would be nice to increase the size of the submit button., but was it worth to delay the schedule? No. Could I improve it on the next version? Absoultely.

 

In reality, most projects were under a lot of constrains, be it limited time or limited man power. It is really common to see delay in tasks because we humans are terrible predictors. Sometimes, we just have to accept the fact that "Good enough" is what we should go for. As an UX practitioner, it was my job to embrace the constrains and focus on what truly matter to the users.

Thanks For Reading.