Mobile eLuminate App
Designing a Mobile Version of a Client Management Software Application
Problem Definition:
As with any company in the online case lead generating market space, a companion lead and case management program is a necessary supplemental software to assist clients in staying organized, getting the most out of their investment, and maximizing the return on their investment. As such, the marketing company eGenerationMarketing, which generates online case leads for law firms practicing in the Social Security Disability, Personal Injury, Workers’ Compensation, and FDCPA violations market spaces, provides its clients with a comprehensive eLuminate case management software. This software provides a wealth of tools to help streamline the intake, processing, and management of potential and signed cases from initial intake through final court proceedings and settlements.
Currently, eLuminate does not have such a version, and this could potentially hinder the ability to market the product to smaller scale law firms or sole practitioners, who may not have the resources and staff of a larger firm and may have to do a lot of their work on-the-go while traveling between court hearings and client appointments.
Screen from mockup of updated desktop version of eLuminate.
Background Research:
At the outset of this project, I conducted some background research on designing mobile versions of desktop applications, and found some of the following key points:
Enable frequent users to use shortcuts
Because of the size constraints, much greater possibility for distractions, and the fact that many instances of mobile device use either require or encourage single-hand use, it is imperative to provide ease of use and to minimize the amount of user input that is require. Additionally, because time may often of concern when a user is accessing an application from a mobile device, it is important to reduce the number of interactions the user must undertake to regular tasks.
Use slim and deep architecture
Because of the need to maximize the little screen real estate that is available, it is essential to chunk important information into relevant segments presenting the user with the most important information first, and then allowing them to choose which information they view next in sequence. Whether is printed on a page, or viewed on a screen, chunking of information allows users to expand the capacity of their working memory and more easily absorb and retain information when it is arranged in some meaningful way.
Offer informative feedback
Whenever the user performs some action, there should be some form of feedback to the user, whether a visual cue, audible sound, or some form of haptic feedback. Additionally, said feedback should be clear to the user what message or meaning it is trying to indicate.
Reduce memory load with meaningful icons
In order to save screen space and to reduce the memory load of the user, especially for repetitive tasks, it is important to use meaningful icons in place of textual information whenever possible.
Design dialogs to yield closure
When users perform actions within an app, those actions should be segmented in logical steps such as beginning, middle, and end to provide the user with some sense of completion. This both ensures that tasks are fully completed and are not accidentally abandoned part way through as well as relieving the user of any sense of anxiety that may be felt if he or she is unsure if the task has actually been completed or registered as completed by the system.
Design Process
Initial Sketching
At the outset of this project, I began by sketching some ideas of how I wanted the basic UI to be arranged. Coinciding with my initial research, a major concept of my design was to partition the various modules of the application into different segments that made up the primary navigation located within the footer of the application.
Within each module, remaining functionality would be divided into a secondary navigation in the header comprised of various user actions, and a tertiary navigation tab would sort the Leads, Contacts, and Matters segments lower in the information hierarchy.
Low-Fidelity Prototyping and Informal Evaluation
After sketching out some ideas, I created a low-fidelity paper prototype and conducted some informal user testing. During this phase of testing several test subjects expressed that there was too much navigational clutter in one area at the top of the screen. As a result, I relocated the tertiary navigation tabs to the left side of the screen. This would provided the added benefit of reducing the chance of user error by accidentally tapping on the wrong navigation item, that was far more likely when the secondary and tertiary navigation were located next to each other at the top of the screen. Furthermore, my relocating the tertiary navigation to the left side of the screen, it enables the user to make better use of his or her thumb if he or she is trying to use the app with a single hand.
During this initial evaluation, It was also deemed best to relocate the Home button, originally placed in the top left part of the screen, down to the primary navigation at the bottom of the screen. Being part of one of the five main modules of the application, it was felt that it should be located along with shortcuts for the four other modules, that is: Records, Tasks, Events, and Search.
In addition to relocating the home button to the primary navigation on the bottom of the screen and moving the tertiary navigation tabs on the Individual Record Viewer to the left side of the screen as they were on the Main Records Viewer page, another change that came about as a result of the informal evaluation was adjusting the architecture of the secondary navigation. In line with the “narrow but deeper architecture” philosophy of mobile design, I decided that rather than give Convert and Delete, their own buttons within the secondary navigation, they should be placed one level lower, as options within the Actions dropdown menu in the secondary navigation. This was to have the added benefit of reducing clutter on the top level of the architecture, as well as reduce the risk of the user accidentally deleting a record.
High-Fidelity Prototyping and Formal Evaluation
Upon reviewing the results from the informal evaluation, I created a high-fidelity prototype in Sketch and InVision, and then proceeded to conduct a formal user test of the mobile version of the application. After conducting the formal evaluation, there were several aspects of the design that I changed. One common critique of the prototype was that with so much blue as the only real color throughout the Main Record Viewer page, visually, the users felt that it was sometimes confusing to understand exactly where within the hierarchy of the application they were currently located. Several test subjects had expressed that they felt it sometimes confusing to initially tell right away which segment of records they were currently viewing, whether Leads, Contacts, or Matters, or whether or not they had actually moved between segments when they wanted to.
Thus, one of the first improvements I had made to the prototype after the formal evaluation was highlight each record with a different color based on which segment to which they belonged. Blue was assigned for Leads, orange was assigned for Contacts, and Red was assigned to Matters. The goal of this was to provide a visual cue to better assist the user in differentiating between the different segments of records.
Furthermore, to better reduce the overabundance of the color blue throughout the page that several test subjects had described as distracting and overwhelming, on the updated version, I replaced the blue in header with a dark gray, and reduced the amount of blue used in the footer navigation to indicate the active module. Additionally, several test subjects had expressed that they thought for the Leads and Contacts segment it would be more useful to have that person’s phone number listed rather than the case type in the main table.
Another aspect of the prototype that was discovered to need improvement was the fact that it was often difficult for the user to experience moving through different levels of the architecture - namely, there wasn’t much appreciable difference between the Main Records Viewer page and the Individual Record Viewer page. To solve this, I adjusted the color scheme for the Individual Record Viewer to better portray to the user being in a different level of the system architecture. The dark gray header in the Main Record Viewer was replaced with a light gray header in the Individual Record Viewer, and the left side tertiary navigation that was blue in the Main Record Viewer was changed to a teal color in the Individual Record Viewer. The spacing between rows in the Individual Record Viewer was also increased to decreased the crowded feeling and to increase the ease of reading information in the table.
Design Features
-
Primary navigation in footer with relevant icons
-
Secondary navigation with various functions and actions in header
-
Tertiary navigation on left side to avoid clutter and abate user error
-
Different color themes to better indicate various locations within system architecture
Interactive Prototype
An interactive, clickable prototype can be viewed on InVision by clicking the following link:
Mobile eLuminate Interactive Prototype
Style Guide