UX Case Study: Improving the ARMS application process

Jacob Camilleri
16 min readApr 24, 2022

Disclaimer: I want to preface this case study by stating that this is a concept project. I am not affiliated with ARMS and I have the utmost respect for the designers and engineers from ARMS. I simply took on this project to improve my UX skill set.

Background

What is ARMS?

ARMS Ltd. (Automated Revenue Management Services) is the sole utility company in Malta that provides water and electricity for homes and workplaces. Acting as a subsidiary company for Enemalta PLC and Water Service Corporation (WSC), the government entity is responsible for issuing bills, collecting debt and handling customer inquiries. In addition, ARMS Ltd. offers more than 30 different services ranging from installing smart water and electricity meters to implementing renewable energy solutions.

Problem Statement and Objective

Applying for water and electricity should be a seamless and fluid process. While browsing through the ARMS website, I stumbled upon a clean homepage UI and a secure eID login portal. Afterwards, things started to get complicated. The task of choosing the right service from an array of 30+ services is burdened with cognitive load and lacks help and documentation throughout the user journey. Furthermore, the application process can get confusing especially for first-time users instructed to undergo the archaic process of downloading, printing, filling out, scanning and sending an application form back online. To this extent, I decided to address this problem by suggesting a redesign of the ARMS UI.

While there are certainly many UX challenges that need to be addressed, I understand that designers of ARMS are nonetheless aware of the situation and that trade-offs between UX and business decisions are constantly battled. However, the company holds a monopoly over the distribution and billing of water/electricity services in Malta so it would not be wise to approach a system overhaul and redesign their domestic offering solely from my research efforts. Despite this, I believe that a native and streamlined application process is a step forward for 2 ethical reasons:

  1. Human Effort: Reliability and convenience for users pressed for time and wishing to apply for water and electricity from the comfort of their own home.
  2. Human Rights: Transparent and error-free billing process as a result of a streamlined and centralized application process.

Design Process

A UX overhaul requires an iterative and non-linear approach to the design process. To uncover underlying and ill-defined problems, I’ve implemented the following 5-stage research and design process:

  1. Empathize Ψ
  2. Define 🎯
  3. Ideate 💡
  4. Design 📐
  5. Learn 📝

Empathize Phase: User Research

The first order of business was conducting structured user needs assessments with 5 Maltese participants who applied for different services with ARMS in the past 3 years. After a thorough discussion with users about their experience and expectations after purchasing a premise and managing their utilities, I developed an affinity map illustrating aggregated experiences across different stages of the application process. The following is my interview protocol:

1 - Warm-up

  • How long have you been a homeowner?
  • Why are you registered with ARMS?
  • How often do you use their website and services?
  • In general, are you happy with ARMS?

2 - First-time user experience and application process

  • Can you tell me about the first time you visited the website and applied for a service? (Secondary Questions: How did you start? Which service did you apply for? Did you present any additional documents? Did you go offline at any point?)
  • Was the user interface easy to understand?
  • Did you seek help when initially applying for the service? If so, was it useful?
  • How long did the process take? Do you think that this duration is reasonable?
  • Based on your previous experiences with government websites, what were your expectations when performing the task?
  • Do you think that the process was successfully completed?
  • Would you say this was a typical way to apply for a service?
  • What changes would you recommend? You can mention examples of good websites and services

3 - Conclusion

  • Can you elaborate on any other issues you faced after the application process?
  • What are your thoughts on receiving and paying bills?
  • Would you say this was a typical way to apply for a service?
  • Can you think about one thing you liked the most about the website?
  • Would you recommend ARMS to a family member or friend?

Define Phase: Addressing User Needs

Warm-up Q&As and Participants’ Application Process
Warm-up Q&As and Participants’ Application Process
Affinity maps: Pre-application, application and post-application stages
Affinity map: User suggestions

For the sake of clarity, I’ve clustered and organized my interview findings into 3 user stages. A similar structure for the design phase was adopted to better explain the user flow:

  1. Pre-application: eID login
  2. Application: eForms portal, manual process and in-person application at the ARMS department
  3. Post-application: Service payment, service delivery, utility bill estimation, receiving utility bills and paying utility bills

Data analysis revealed user pain points and suggestions that go beyond the application process (such as archaic systems in other services and a lack of utility provider options to choose from in Malta). For the sake of brevity, I will highlight the 3 types of application processes:

  • ARMS Department: PPT04 and PPT05 went straight to the ARMS department to apply for a service
  • Manual Process: PPT02 and PPT03 opted for the old-fashioned procedure (downloading -> printing -> filling out-> scanning -> online submission)
  • eForms + Manual Process: PPT01 tried to apply for a service through the eForms portal but was advised by ARMS representatives to undergo the manual process

The latter application process turned out to be the most frustrating experience. PPT01 even conducted a usability test on the eForms portal to reinstate his disdain for the process. The scenario was that he wanted to apply for the shifting of water service for his new townhouse. After collating all that I had learnt from PPT01’s think-aloud usability test, I formulated a user persona, empathy map and user journey map around his experience.

John’s empathy map

The proposed human-centered design was based around John, a tech-savvy individual and busy bee who appreciates an intuitive and communicative system. Based on my text mining approach conducted on Python (word frequencies: NLTK; topic modeling: LDA model and sentiment analysis: Flair), I found that ARMS’ timing, customer service and follow-up procedures were highly frustrating for John.

John’s user journey map

Visualizing John’s goals, behaviors and pain points when applying for a service allowed me to brainstorm better usability opportunities, which in this case lie in the eForm selection, eForm submission and application status.

To conclude the define stage, my user research identified the following pain points:

  • Users found the eForms UI to be confusing
  • Customer support is lacking
  • Limited service-related information
  • Confirmation and post-application follow-up are insufficient

Ideate Phase: Generate and Brainstorm Ideas

Going about the design process wasn’t a head-scratcher. But before moving forward there were some HMWE statements that needed to be addressed:

  • How Might We encourage users to apply for a service online?
  • How Might We give users more help and documentation during the application process?
  • How Might We help users who have no idea of how to apply for a service?
  • How Might We provide an application process that saves time and effort?
  • How Might We generate post-application designs that keep users informed?

Furthermore, I took a deep dive into Usability Heuristics and made sure that the new process features met the requirements of Heuristic Evaluation:

  • Help and Documentation: The new process should be laden with service-related information across different website features
  • Flexibility and Efficiency of Use: The process should reduce the learning curve and overall interaction cost
  • User Control and Freedom: The process should promote task correction
  • Visibility of System Status: The process should clearly communicate users’ application status as quickly as possible

In conclusion, STREAMLINED, NATIVE AND INFORMATIVE APPLICATION PROCESS

It felt reasonable that the ARMS redesign I propose would be suitable and necessary for the desktop version, the reason being that applying for any service is typically driven by the need to meticulously fill out information and upload documents on a larger screen. The redesign of the ARMS mobile version will be the subject of a future UX case study.

Current user flow #1: Manual process
Current user flow #2: eForms portal

Part of the ideation process included mapping out a user flow that visually illustrated the user decisions and screens needed to apply for a service through the eForms portal. After familiarizing myself with the original application flow, I illustrated two different routes:

  • Manual Process: The manual process was baffling for first-time users without eID credentials, starting online to download the form and then undergoing the archaic process of filling out, scanning and sending the form back online. Furthermore, the ‘apply for services’ section in the FAQs page was profuse with unnecessary questions, cluttered answers and form links leading to an error 404 page.
  • eForms Portal: On the other hand, the eForms route is more centralized, definitive and secure. The process required eID login credentials to access the majority of the eForms, a feature highly necessary for security reasons.
Proposed eForms user flow

I felt that two different application routes didn’t cut it. Users want an intuitive design that brings them directly to the delivery of water and electricity. By getting rid of unclear navigation, I formulated a centralized user flow incorporating manual and eForms routes into one portal. Although this flow has more homepage interactions and application steps (such as eSignature and uploading additional documents), the application process will be less prone to errors and completed in no time.

Website Chatbot and Facebook Messenger user flow

Chatbot functions for both ARMS website and Facebook page were also conceptualized. The former system will allow users to interact using free-text typing with autocomplete and link selection. Results will be generated in a logical way but limited in its knowledge base. For more personalized interactions specifying open-ended inquiries, I’ve opted for Facebook Messenger to direct users from bot to ARMS advisor.

I went straight ahead with designing low-fidelity wireframes on Draw.io. During the ideation process, I gathered enough user feedback to prioritize the aforementioned usability heuristics that would exert a fast and stress-free application experience.

Design Phase: Building High Fidelity Solutions

1 - Pre-application Stage: Homepage, FAQs and Chat Functions

Before and after comparison of the above-the-fold homepage content

I took action by prioritizing and refactoring help-related content on the homepage using Figma. The original homepage had a slider with 3 CTAs (registration, e-billings and e-forms) which are already integrated below the fold. I thought of the homepage as an important starting point for first-time users’ inquiries and expectations, so it made sense to position a “Call an Advisor” CTA below an ad copy conveying the message that ARMS promotes comfort, control and reassurance through smart technology.

The navigation panel and “easy access to services’’ have been retained to direct users to specific content. This time I’ve included new sections which direct users to a centralized eForms portal (with the option to download the form) and a free web call with an ARMS advisor.

Application Timeline Slider

I’ve also created an application timeline slider for the 4 types of application processes: services, changes in tariff/billings, readings and payments. Users want to know what the process is all about and click the “Apply” CTA with reassurance from the get-go. The main assumption here is that users haven’t chosen their preferred eForm from the array of 30 services, hence the generalized application timeline.

Before and after comparison of the FAQs page when searching for the eForm pertaining to the replacement and/or shifting of water service
Before and after comparison of the FAQs

The redesign of the “apply for services” section in the FAQs page was an attempt to reduce search time for the FAQ related to the replacement or shifting of water service and to favor the eForm application process:

  • I’ve reduced the word count for most of the FAQs and shifted unrelated ones to other sections.
  • A search function with a personalized “How can we help you?” statement makes all the difference for a multi-purpose service such as ARMS.
  • Questions and answers were adjusted for color and font size in order to be distinguishable.
  • Each question was accompanied with an informative application-related description (overview, service delivery and eligibility) and 2 CTAs: “Apply Now” and “Download Form”. Information on ARMS’ services was scrapped from servizz.gov.mt
Website chatbot icon
Website chatbot conversations: Filling out the right eForm
Facebook Messenger conversation: Filling out the right eForm

For the chat conversations, I’ve created scenarios in which users experience difficulty in selecting the right eForm and require additional service information and post-application follow-up. A free web call service and help-related information from WSC and Enemalta will be integrated into the chatbot algorithm to accommodate customer support functionalities. Despite the chat functions serving to inform the user throughout the application stages, the user’s status in the process will be more accentuated on the “My Account” page.

2 - Application Stage: eForms Page and Form S (Replacement or shifting of water service)

Before and after comparison of the eForms page
Before and after comparison of the eForm titles
Before and after comparison of Form S: Replacement or shifting of water service

Consistency in UX writing between the FAQs and eForms pages was maintained. I’ve eliminated the terms “application” and “registration” from the eForm titles altogether in an attempt to reduce search time. Displaying a service guide, specific onsite work details and information regarding eligibility above the fold of Form S would allow the user to validate their desired service accurately.

The goal of the eForm redesign was to find a balance between reducing eForm completion time and providing additional steps and guidelines to further validate the application process. Best practices here would be to declutter form-related content and conserve screen space.

As opposed to the cluttered original design, the redesign was envisioned by contrast and accordant separation of sections on the eForms layout. To accommodate these design principles, I’ve retained the English text and placed the white sections (description, profile, project, documents and declaration) on a light green background.

When applying for services that require the presence of a technician or proof of service, I sought to include another upload box allowing users to upload a photo of the device/supply needing servicing. The option would facilitate both the validation of the application process and onsite work.

I’ve designed additional features that increase flexibility, improve efficiency and reduce errors in eForm completion. The final designs included an eSignature box in the declaration section and “Clear all” + “Save” buttons at the bottom of the page. Furthermore, users shouldn’t go through a guessing game when filling out eForms. Good practice here would be to include information boxes specifically for time-consuming input fields.

eForms side menu and applicant type dropdown menu

The original eForm navigation menu was taking up space in the eForms portal. A side menu will allow users to go back and forth when selecting e-forms and direct their attention toward filling out the online form. In addition, users would have to choose between applying for a service as an individual or as part of an enterprise when filling out personal details in the profile section.

3- Post-application Stage: “My Account” Page and Chat Functions

Form submission message in homepage
“My Account” Page with application status tracker
2 types of message prompts for application assessment and approval
Website chatbot conversations: Application follow-up

Visibility of system status is a fundamental tenet of any application process. User research in this study indicated that users were anxious not knowing their application status. For this reason, I decided to include an “application status tracker” on the right side of the user’s account page. Realistically, the process goes through vetting checks, application payment process and scheduling of onsite work, so I made sure to provide transparency in the user’s case timeline. In addition, I’ve designed a form submission message with the clear goal of creating validation and avoiding confusion after submitting the eForm.

Learn Phase: Gather User Feedback

The last stage of my UX case study was gathering feedback from previous participants on the proposed solution. Positive feedback came thick and fast once they evaluated ‘before vs. after’ images of the ARMS application process:

“Website seems more legit”

“The eForm has clearer sections and is easy on the eyes”

“The application process is more concise”

“Appreciate the idea of communicating process delays and meeting expectations”

“Message prompts are good”

Areas of Improvement and Future Avenues of Research

I have a huge list of features to add to the ARMS redesign but without an actual deadline I’d continue researching forever and never close the loop. Here is where I spare room for improvements and make the designs develop at a later date:

  • Users felt that user completion time and ARMS completion time for every stage of the application process need to be more differentiated, well-defined and consistent across the application timeline slider, eForm descriptions and application status tracker.
  • “Registration” and “Application” can be retained as part of the eForm titles but should dictate a logical user flow. One user concluded that the former is more applicable to first-time users submitting Form A (new electricity and/or water services), whereas the latter is more applicable to registered users applying for the rest of the services.
  • Users had second thoughts about the word “Project” as an eForm section title and instead opted for “Service”
  • One user recommended placing all file attachments into one section.
  • Users preferred a multiple-page eForm format, as opposed to the proposed 1-page format. They believed that interruptions with internet service would deter their progress in filling out the eForm all at once. Having said that, it is also key to have a “Save & Continue” button predominately placed in the screen as users progress from Profile to Documents.
  • Visibility of system status was highly regarded as the most important usability heuristic during feedback sessions and users recommended an efficient email notification system.

The post-application stage is still a work in progress and the delivery of water and electricity will be at the forefront of a future redesign. With this in mind, I intend to take the following steps for both mobile and desktop versions:

  • Designing a calendar interface allowing users to schedule an appointment with an ARMS technician after application approval
  • Design a separate secure payment portal for processing application fees
  • Designing a map portal to detect interruptions in water and electricity services across Malta and Gozo.
  • A deep dive into researching more about the billing experience and exploring ways to integrate ARMS, WSC, Enemalta and other government services as a one-stop-shop.
  • Understanding the main pain points ARMS advisors face when processing eForms and coming up with innovative workflow automation and document management solutions.

Conclusion

With the proposed redesign of the ARMS application process formulated during the COVID-19 pandemic, Maltese households and enterprises can set up utilities with ease and convenience. Apart from focusing solely on applying for services, the UX overhaul also sheds light on promoting a positive customer experience throughout.

To conclude, I’ve drawn some insights and thoughts from the process of working on the ARMS concept project:

  • Quantifying qualitative data is essential in UX: It’s astonishing how conducting text mining on interview transcripts provides actionable recommendations.
  • User feedback and empathy determine product success: Having access to user insights is beneficial to the design iteration process, giving any business a profitable edge and a positive customer experience. Furthermore, empathizing with users helps to achieve user-centric goals for systems and services that are essential to everyday life.
  • UX design isn’t just about outsmarting your competitors: Businesses should offer seamless experiences which follow ethical and universal UX design principles, an objective that must be continuously emphasized in any business having a monopolistic-type control over the market.

This case study has been a challenging yet rewarding stepping stone into the world of UX. If you have any suggestions or feedback, feel free to leave your comments below.

--

--

Jacob Camilleri

📝 Writer & Researcher | Psychology and Cognitive Science Graduate | UX Enthusiast | VoC Advocate | Text Analyst