Introduction

Brief

This final assignment is based in the area of design systems and accessible or universal design. The task is to design a high-fidelity interactive prototype to address a particular need while considering usability / inclusive design. The key aims of the brief are as follows.

  • Minimal proto-personas and scenarios
  • Secondary research to inform personas and problem
  • Research design systems and use to inform mobile prototype
  • Produce an interactive, high fidelity prototype
  • Document design problems and decisions in 4 main blog posts

Chosen System

The system chosen for the final assignment is the Irish Revenue Commissioners Project and Portfolio Administration system (PPA). In particular, the requirements sign off tracker has been looked at in detail. This section of the system manages the tracking and updating of requirements and functional specification documents. It allows staff responsible for the administration of various projects to track documents associated with the development and maintenance of Revenue systems.

The process for this is done through selecting the required quarter of the year the project is being developed in, and then accessing the Sign Off tracker section of the application, followed by its live release date, the system test release date and finally the requirement. From there updating of the various issued and received dates associated with the requirement and functional specification documents may be amended or viewed.

Analysis of Current PPA System

Currently, the PPA system cannot be used on a mobile phone and no attempt has been made to make it responsive so that it may be used on various devices, this will be one of the key problems which will need to be addressed.  The main navigation system on the left is slightly confusing (fig 1, Section 1) with certain items existing outside the defined area. A very similar colour is used for the menu title as well the hover state and selected menu item and the buttons break most established norms for the creation of buttons (Babich, 2016).
The second section of (fig 1, Section 2) shows how the requirements tracker represents the scheduled list of live releases, these are presented in an accordion manner with a very faint line dividing them, they could possibly have been managed better by a drop down or by providing more clear separation and affordance. Use of affordance allows users create meaningful information without developing internal representations of their environments (Kaptelinin, 2013). This is not a major problem until they are expanded and the system test releases associated with the live release are presented (fig 1, Section 3).
There is no indicator or separation to show the user has moved a level deeper, also the use of the same colour for all text and visual dividers further adds to the cognitive load for the user as they are forced to define divisions through investigation.
This cognitive load is further added to when viewing the contents of a system test release (fig 1, Section 4).  Once again there is a lack of affordance with the failure to include an indicator prompting the user to expand the system test release to view the list of requirements for that release. When the user does click it, they are presented again with a deeper level of content with no clear separation and the same use of colouring for both labelling and graphic dividers of content.

PPAEdit
Fig 2: PPA Sign of tracker, view mode

Within the requirement (fig 2, Section 4) there is a colour indicator as to the status of the requirements and text informing the user of its state. The decision to partially fill some of the requirement with the status colour is probably unnecessary and only adds to the already confusing layout. The functionality is provided to edit the date fields but it is not immediately clear as to what the ‘Edit’ button is mapped too, and as discussed by Cooper, Reimann, Cronin, (2014) poor mapping forces users to stop and think about relationships breaking their flow and once again increasing the cognitive load.

When the user enables the edit functionality they are presented with a set of date selectors and drop downs (Fig 2, Section 1). When editing is enabled the screen jumps quite significantly due to the input boxes being loaded and the existing layout needing to change to accommodate them, this is extremely jarring.  The status colour of the requirement if similar to that of the one above overflows into one solid block forcing the user to discern where the division is. To understand what the input fields map too the user must repeatedly scroll to the top of the release number to see the labels “Issue Date, Sign-Off Date and Status” (Fig 2, Section 2), again an example of poor mapping.

As can be seen the cognitive load on the user at this stage is quite considerable forcing the user the learn how the system functions. Due to the fact that the system is not used on a daily basis, this learning must take place to some degree each time the system is used. As suggested by Cooper Alan,‎ Reimann Robert,‎ Cronin David, (2014) for transient web applications, such as the PPA system which is not used regularly, it is critical that clear orientation and navigation is provided.

PPAEdit
Fig 2: PPA Sign of tracker, edit mode

Besides the issues mentioned above which affect all users, the PPA system also suffers from a number accessibility issues which affect users with motor issues and visual impairments.

In the case of labelling, there is little to separate major and secondary label items such as headings and subheadings beyond bolding of text. This makes the decoding of the hierarchy of information difficult for all users, but particularly those with a visual impartment. This lack of a hierarchy of information forces the user to spend time decoding the interface and can lead to frustration and abandonment of tasks (Cooper et al. 2014). This failure to clearly define headings and subheadings breaks W3C guidelines (W3C, 2015) on accessibility.

The spacing between the various input fields and their layout is poor with labels for the next text input field following directly after the previous text field. Recommend best practice for ease of legibility is that form fields are stacked horizontally (fig 3) with labels directly above and sufficient spacing to make them easily discernable (Apple, n.d.; Babich, 2016; Microsoft, n.d.; National Disability Authority, n.d.;  ).

Rules For Efficient Form Design – UX Planet
Fig 3: 10 Rules For Efficient Form Design, UX Planet

Where stacking is not possible Google material recommends a horizontal layout which has clear spacing, padding and labels  are stacked a top the input field (fig 4).

Text fields-Components-Material Design
Fig 4: Google material, Horizontal form layout

Revenues PPA system also suffers from colour accessibility issues, the use of colour as the main indicator of status is not visible for most type of colour blindness (fig 5). Making it impossible for users to identify current status without reading the text of each item, which given its size would make identifying status near impossible .
The contrast on the site may initially appear not to be an issue but due to the size of text used this does become a very serious issue for users who experience issues with contrast (fig 6).

ColorBlindnessSimulator_Blue-Weak-Tritanomaly
Fig 5: Colour Blindness Simulator, Blue Weak /Tritanomaly
Color Contrast Analyzer
Fig 6: WCAG 2.0 Colour Contrast Analyzer

As-Is Process Map

The current system takes the approach of fitting as much content on the same screen as possible, this causes the user to become overwhelmed and when editing functionality is enabled this issue is compounded (Fig 7).

image003
Fig 7: Requirements tracker edit functionality

The current as As-Is process leaves the user to find the relevant items they are looking for rather than trying to guide or prompt them in any way. Although this may make development and maintenance simpler it leads to a complex and difficult user experience as can be seen in previous screenshots, and is also shown in the process flow in the select requirement stage (fig 8)

As-Is
Fig 8: As-Is Process Map

To-Be Process Map

The To-Be process has been broken out into further stages so as to reduce the amount of content at the various stages and increase the level of findability of requirements. Users will be guided through the process in stages rather large amounts of content being displayed to the user, so they will no longer be forced to manually filter. The first iteration of this failed to take into consideration user needs when it came to requiring an overview of requirements in need of attention, due to either missing data or falling behind schedule. This came to light while talking to Revenue staff members during persona creation, the revised process can be seen in figure 9.

To-Be
Fig 8: To-Be Process Map V1
newprocess.jpg
Fig 9: To-Be Process Map V2

Proto – Personas

To aid in creating empathy and an understanding of users, two proto-personas or provisional personas have been created. Although not ideal proto-personas are better than no personas at all, and still aid in being rhetorical tools which help communicate assumptions about important users, enforcing thinking about serving particular user needs (Cooper et al. 2014).

The personas are in part informed by my own use of the current PPA system and the frustrations I have encountered. Half a day was also dedicated to canvassing and interviewing other team leads and two members of senior management. All of these staff members use the current system on a once weekly or bi-weekly basis. The primary persona is informed in a large part by my interviews with members of the senior management team one of who retires this year, while the secondary persona would more closely represent team leads who would use the system more regular and hence have a reduced need to relearn the system.

Primary Persona

The primary persona Mark, represents users with accessibility issues. In Marks case, he suffers from the early stages of age-related macular degeneration (AMD).  This is a disease that causes the gradual loss of sight due to blurring or loss of central vision.

Seven percent of Irish people aged 50 years or older suffer from AMD. Making it the leading cause of sight loss in this age group, in the coming years, this number will increase due to our ageing population (fightingblindness.ie, 2013). There are two types of AMD, wet and dry. The dry form is more common (around 85% of people with AMD have the dry form) but it is less severe and vision degenerates over a longer period of time (fightingblindness.ie, 2013), this is the type which our persona Mark suffers from.

AMD.png
Fig 10: AMD. From left to right. Normal Vision, Wet AMD & Dry AMD

Mark also suffers from a slight tremor in the right hand. It is the most common of all involuntary movements and not only can it be embarrassing to some people it can also make it harder to perform daily tasks. Mark suffers from a postural action tremor which occurs when the person maintains a position against gravity, such as holding the arms outstretched, this can make the use of a mobile phone difficult (Medicinenet.com, n.d.).

These two conditions combined can make it very difficult for Mark to use systems with small text and interactive items or where items are positioned to close together. Mark is reasonably IT literate due to performing I.T management tasks in his day-to-day, he has been chosen as the primary persona as addressing his issues should ensure both personas issues are sufficiently addressed.

Pain Points

  • Difficulty reading small labels or text
  • Clicking on small buttons or links is difficult
  • Hitting the wrong button or input
  • Items in PPA not clearly separated
  • Can use PPA on a tablet or phone
Goals

  • Get a clear overview of the status of all requirements
  • Wants staff to update requirements in a timely manner
  • Needs to be to check dates quickly in tracker and update as needed
Mark
Fig 11: Primary Proto-Persona – (Full size)

Secondary  Persona

Mary represents the average team lead in Revenue. She is highly I.T literate and has a large amount of experience in the development and use of I.T systems. She originally comes from a systems development background and still enjoys getting her hands dirty but also enjoys defining and fleshing out systems and has a strong interest in business process modelling and analysis. She finds administration of being a team lead can be overly burdensome and feels the time could be better used elsewhere.

Pain Points

  • Poorly designed systems such as PPA which have no user input
  • Locating requirements in the PPA system
  • Editing causes confusion as the screen moves
Goals

  • Wants to be able to stay on top of updating requirements
  • Wants to be able to see clearly the status of requirements
  • Want to spend less time doing admin and working out how PPA works
Mary
Fig 12: Secondary Proto-Persona – (Full size)

Sketches

The initial rudimentary sketches were based on the To-Be process model with some nebulous guiding principles of easy to use & clarity of purpose. The very early sketches were completed before the core principles were fully defined, which is discussed in the design language post.

1. Login Screen

Although not currently a requirement for accessing the PPA system, this would be needed if users wished to access the system from outside Revenues main office. Given that the prototype is a mobile-first experience and will be used by senior staff when outside the building I felt it was best to include this as an additional screen. The initial sketch did include a header and navigation menu (fig 14, screen 1), the menu was removed in the later high fidelity prototype as it was unnecessary until the user was logged in.

2. Select Team and Period of Year

To begin using the PPA system the user must provide the team name and year quarter. The PPA system combines both the team name and the year quarter into a predictive text input (fig 13). The user must know the naming convention used for the team as well the year quarter and must be aware how both of these are combined. On top of this, none of the main navigation will work correctly until this information is provided, as whats displayed throughout the site is dependent on the team entered.  This makes for a lot of frustrated guessing.

teamsleect.png
Fig 13: Team select screen

The solution to this was to simply break the required pieces of information into separate inputs with values that can be selected from an options list (fig 14, screen 2). Since the activation of the menu is dependent on these options being selected, the menu would slide from the out from the right, indicating it had been activated and informing the user it was now available for use.

001.jpg
Fig 14: Sketches Screens 1-3 (full screen)

3. Menu Panel

Due to the size and importance of the menu for accessing the other areas of the site and its poor implementation, I felt it was necessary to include it in the redesign. The original menu can be seen below in figure 15. There appears to be little logic as to highlighting and bolding of menu items, the hover states are the same colour as active menu states, and the overall container appears to encompass different items depending on what is selected.

In the early sketches, I decided to go with a full-screen menu which would be activated using a hamburger style menu (figure 14, screen 3). The full-screen decision was based on making the most of the available space so it would be possible to have large fonts and touch areas, so as to address accessibility issues, the BCC, Apple and Googles design guidelines all specify large touch areas when developing for mobile to ensure. maximum accessibility (Apple, n.d.; Google, n.d.; BBC, n.d.).

Although there has been a trend towards arguing against the use of the hamburger menu (Kumar, 2017), due to the discoverability being cut almost in half by hiding a website’s main navigation & perceived task difficulty increasing (Pernice & Budiu, 2016), there is still a strong argument for its use. The issue is not the hamburger pattern itself but the taking of sufficiently good mobile design pattern and applying it to desktops where it does not work as well (Pernice & Budiu, 2016).  It may have been possible to re-engineer the information architecture of the PPA system so as to remove the need for the hamburger menu, but this would have required dedicating a serious amount of time to properly research and test alternatives which I felt given the time allotted wasn’t feasible. Also given that  NNGroup itself suggests the following “If your site has more than 4 top-level navigation links, the only reasonable solution is to hide some of these”  (Pernice & Budiu, 2016). I felt that I was reasonably well justified opting for this solution.

menu
Fig 15: PPA Menu

4. Requirements Sign Off tracker

All content and releases for the Sign off Tracker are currently managed on one screen. As already discussed this is very overwhelming. Figure 16 below shows this screen

Callouts
Fig 16: Requirements Sign off Tracker
  1. Main Menu
  2. List off Live Releases
  3. List of System Test releases
  4. List of requirements per system test release

This overloading of information makes for a heavy cognitive load for the user (something I can personally attest to) making it difficult to find what they are looking for and causes a sense of frustration that can lead to task abandonment  (Franganillo, 2017; Rogers, Preece & ‎Sharp, 2015 ). I felt to rectify this it would be best to break this information out into two distinct sections. The first of these (fig 17) would allow the user specify the live release, the system release and the actual requirement for updating or viewing. Initially, the idea had been to use progressive disclosure for each drop-down and the final trigger button, but I decided against this ins the final prototype for two reasons. One its mainly used for encouraging the user to move from completing simple tasks to executing more complex ones (Interaction Design Foundation, n.d.), which is not the case here and secondly, animations can be confusing for screen readers and individuals with screen readers and visual impairments (W3C, n.d.).

002.JPG
Fig 17: Requirement selection screen. (full screen)

The second stage presents the requirement with the edit functionality enabled (fig 18). initially, I had prototyped this as two separate view modes, view and edit. But after defining the core principles I decided to opt only for the edit mode. This removed the need for the existing view mode and allowed the user direct access to the edit functionality removing the additional step of enabling editing. I felt this made sense as all users no matter their privileges currently have and need access to edit, and it also supported the core principles of being Visibly Informative, Simple & Easy to Use, Helpful (getting out of the way of the user).
At this early stage, I was also considering accessibility and the primary persona by making the calendar buttons as large as possible so as to maximise the touch target area as well as ensuring large font sizes.

003.JPG
Fig 18: Requirement screen (full screen)

Figure 19 shows the final stage of the requirements sign off process, the adding of dates to both requirement and functional documents. I was aware at this stage that the overarching container is called the requirement which contains the tracking dates for both requirement documents and functional documents. Although this may seem a little confusing it would require a complete overhaul of current naming conventions and staff mental models across revenue to change this. Something which was well beyond the scope of this project.

The first screen in Figure 19shows the original concept which was to have the user scroll down to view the functional dates causing the requirement dates to scroll off the screen. This idea was abandoned in the later early workings of the high fidelity prototype, which I will discuss later. At this stage, I also realised there were issues with the calendar picker as it was not usable for the primary persona due the touch targets and small text sizes. Also, the status indicator (show in the first and last screens) was also proving to be a problem.

006.JPG
Fig 19: Requirement screen with Functional data inputs and Calendar (full screen)

Finally, figure 20 shows the prototype sketches for the solution to the calendar picker problem. I felt that filling the screen with the calendar would solve the touch targets and small text issues. At this stage, I was also being to consider the overall feel of the application and was beginning to be influenced by Googles Material Design system.

005
Fig 20: Calendar prototypes (full screen)

Post Conclusion

The current PPA system suffers greatly from what appears to be a lack of overall planning. There has been little if any consideration is given to either users or the overall user experience. The accessibility issues are numerous and affect not only users with disability issues but also those without.  Use of colour is extremely poor and little thought has been given to the layout of inputs, labels and text.

The next post will discuss the design language, its research, and application.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: