Azeem Alim

UX Designer

Case StudyStudent Finance Northern Ireland

2018 Website Redesign

A desktop and mobile view of the SFNI website


Department for the Economy (Northern Ireland)


Complete rebuild of the Student Finance Northern Ireland website, ensuring a solution that aligned with user needs, streamlined existing content and was responsive across all devices.

Visit the site

My Role

UX Designer

My Responsibilities

  • Stakeholder Interviews
  • Customer Journey Mapping
  • Competitor Analysis
  • Analytics (web, search)
  • Information Architecture
  • Sketching and Wireframing
  • Prototyping
  • User Testing (lab and remote)
  • CSS
  • W3C Accessibility


  • Design Analyst
  • Product Owner
  • External CMS development team

Design Process

Understanding the Problem

The Student Finance Northern Ireland website was over 10 years old, having previously launched in 2006. Limited investment had been made since that time and the number of online customers and growing diversity of products meant that the site was no longer fit for purpose.

To determine the root causes of where the site was failing, a number of research techniques were used to investigate the problem:

Capture User Groups and User Needs

  • Methods used:
    • True Intent Study uncovered valuable insights into demographics and their top user tasks.
    • Surprise that the parents and partners of students made up a large chunk of visitors.
    • Several assumptions were invalidated the more we learned about existing processes, workflows and pain points — particularly during workshops with the Department for Education and Education Authority.
  • Top Task breakdown
    Top Task breakdown


  • Sources:
    • Google Web Analytics
    • Internal call centre reports
    • Web analytics provided solid quantative data surrounding individual page popularity, PDF form downloads and popular search terms.
    • Surprisingly large number of users searching for a specific PDF form, often using only the form's ID/code (i.e. PN1)
    • Gained a good understanding of why students are calling our helplines and where the old site is failing — particularly on guidance surrounding finance eligibility and evidence.
    • Discovered the homepage oftentimes isn’t the first page users landed on when they visit the site.
  • Customer call reasons
    Customer call reasons

Competitor Analysis

  • Consisting of:
    • 1 internal contemporary
    • 1 direct competitor
    • 4 sector best practice
    • Very conscious not to repeat the structural, content and usability failings of our sister-sites.
    • Inspired by numerous Government Digital Service (GDS) approaches to content and structure. With a goal to meet the Digital Service Standard.
    • Breakdown of finance information into a user-centric categories considered.

Content Audit of Existing Site

  • Consisting of:
    • Content inventories
    • Site mapping
    • Finance information unnecessarily duplicated across the site, particularly in sections for new and continuing students.
    • FAQ section used as a crutch to store all miscelleneous content.
    • Students from the European Union being treated as secondary users.
  • The original SFNI website
    The original SFNI website


This research gave us a clear direction to proceed, focusing primarily on:

The core problems included:

  • Poor content structure hampering the findability of information
  • Inflexible platform which impeded further updates and improvements
  • Extremely limited Web Accessibility and a complete lack of mobile responsiveness

This led to the following solutions:

  • Task-led infrastructure
  • Breakdown of financial information based on very specific users groups (i.e. Full-time undergraduate, Northern Ireland students).
  • A provision to include a seperate, non-loan related section for information.

At this point I also defined that our core usability "measure of success" metrics should be derived from the International Standard, ISO 9241-11 — specifically effectiveness, efficiency and satisfaction.

Workshops and Wireframes

Define the Information Architecture

Using the above research, the next step was to begin defining the Information Architecture, driven by key user tasks. One of the largest shifts from previous design patterns was abstracting general information away from the product-specific information.

  • Principles used:
    • Using LATCH principles, we organised content by Time (in regards to a student's "finance journey") to complement the existing categorization of Categories
    • Proposed two distinct areas of the site: "Types of Finance" to house specific loan information, and "Student Finance Explained" to house general student finance information.
    • Given the complexity of loan eligibility being based on numerous circumstances, a self-identification flow was developed to guide users along.
  • Student finance eligibility flow
    Student finance eligibility flow

Tree-testing of the Information Architecture

In order to validate the Information Architecture, an online tree-test was conducted with three user groups: current students, prospective students and the parents or partners of students.

  • Testing details:
    • 2 tree variants
    • 3 user groups
    • 10 scenarios-based tasks
    • Overall high student success rate for all tasks in each IA variant. High direct sucess with mimimal backtracking.
    • Sponsors found some tasks difficult to complete, but the post-test questionaire gave insight into their mental models.
    • Some general confusion/uncertainty with some of the terms used.
  • Tree-test analysis
    Tree-test analysis


With the Information Architecture successfully validated, I began developing detailed wireframes to map out the information flows, page types and their individual requirements based primarily on our identified user groups and their key tasks.

  • Tools used:
    • Paper prototypes
    • Balsamiq
    • Low-fidelity wireframes proved to be incredibly useful for engaging with internal stakeholders and colleagues.
    • We eventually presented these design intentions to both the Department for Education and Education Authority for approval.
  • Low-fidelity wireframe in Balsamiq
    Low-fidelity wireframe in Balsamiq


Happy with the progress, we progressed to the next stage of developing interactive prototypes

Prototyping and User Testing


  • Tools used:
    • Axure RP
    • HTML/CSS
    • Photoshop
    • Medium-fidelity prototypes of most pages were developed initially in Axure and eventually used in user testing.
    • A HTML/CSS prototype of the entire site served as a living design spec and proved to be invaluable to our external dev team, who were not used to working from such detailed designs.
    • All pages contained real content, which was being written alongside the design.
    • Early exploration of the site's visual design was also undertaken at this point.
  • Medium-fidelity prototype in Axure
    Medium-fidelity prototype in Axure

User Testing

Users testing sessions took place in Belfast over several months, where test subjects were Northern Ireland residents. This was key in order to test certain residency based tasks.

  • Testing details:
    • We sought to test our riskiest task-assumptions early. Notably the student self-identification flow where they can check if they are eligible for funding based on their residency status.
    • The first two rounds of user testing focused on usability, interaction and taxonomy. The third round focused on the accessibility/understandability and clarity of content and policy.
    • Core metrics that were measured were completion rate, time taken and satisfaction.
  • User testing observation in Belfast
    User testing observation in Belfast

Post-Test Iteration

    • Gained valuable insight on how Republic of Ireland nationals identify themselves in terms of nationality, the political sensitivities in using certain terms and how this sometimes clashed with our own definition of "residency".
    • Overall, expected task difficulty vs. actual difficulty was favorable, with most users being surprised at how straighforward many tasks were to complete.
    • We learned the sponsors usergroups generally had dificulty using the Form Finder, so we began exploring a new approach.
  • User testing metrics analysis
    User testing metrics analysis


User testing was enormously helpful to the project and gave us numerous actionable results. It allowed us to validate new concepts, iterate flows and refine content.

UI Design, Mobile and Accessibility

UI Design

    • When writing the CSS, I adopted a Mobile First approach, starting with a modified 12 column layout from the Bootstrap framework.
    • Many pages were organised primarily by three design elements that repeat throughout the site — Tiles, Cards and Buttons.
    • By using these three simple elements, I was able to ensure a structured, consistent and mobile-friendly approach to the interaction across the site.
  • UI card pattern breakdown
    UI card pattern breakdown

Mobile-Specific Considerations

    • To design the site with only responsive design in mind was not enough to ensure an acceptable standard of mobile usability. Certain elements that made up the pages were scrutinised and then redesigned to be more appropriate for its intended resolution.
    • On mobile resolutions some content is organised into accordions (specifically to reduce vertical space) but on desktops this was less of a concern, so the accordions seamlessly upgrade into a fully tabbed layout when viewed on larger resolutions.
  • Differences between tabs on a mobile and destop resolution
    Differences between tabs on a mobile and destop resolution


    • Achieving a AA level of Web Accessibility was one of my main objectives from day one, and so it influenced various design decisions throughout development.
    • Checkpoints were taken from W3C's Web Content Accessibility Guidelines 2.0 (WCAG) and the British standard BS 8878 framework.
    • Post-launch, an external accessibility audit was performed to assess if it met our goals. While the site performed favourably, there were a few important accessibility issues that were identified and subsequently fixed.


  • Vast reduction and simplification of content
  • High success rate and satisfaction for top tasks
  • Tasks much simpler to complete than what users originally expected
  • Highly modular and customisable design patterns


What Worked Well


Visit the site