Skip to content
Lizzie Teo

Macquarie Radar

Overview

Radar is a research data analytics platform built for Macquarie University to replace manual spreadsheet processes for submitting ERA reports to the Australian Research Council.

It streamlines data entry, researcher negotiations, quality checks and automated report generation. The aim was to help the university identify where to invest for better research outcomes.

Role
End to end UX, discovery through delivery
Impact area
Research and data strategy
Focus
  • Stakeholder alignment
  • Information architecture
  • UI design
  • Usability testing oversight

Macquarie University logo

The challenge

The reframe

A shared platform for negotiating research claims

Researchers competing for the same grant claims often ended up in conflict. Errors were costly, and staff lost significant hours to rework. Macquarie University had no shared platform where researchers could negotiate their claims, or where it could see which research to invest in.

“I shouldn’t have to ring someone to find out what percentage I’m allowed to claim. Just show me.”
The Researcher persona

Success metrics

The project set six targets for Radar.

Target: ERA preparation
30%30% reduction in time spent on ERA data preparation and submission
Target: Investment decisions
20%20% improvement in strategic research investment decision making accuracy
Target: Manual coding hours
15,000+Consensus on reducing 15,000+ manual coding hours
  • Reduction in unresolved FORC claim conflicts between researchers
  • Adoption and positive satisfaction across all four user types
  • Decrease in data quality errors and rework hours

The approach

Research approach

Stakeholder engagement identified four user types, and five moderated prototype sessions followed with Research Champions and Faculty Administrators.

  • Grounded design decisions in user research throughout, not assumptions
  • Ran stakeholder interviews and usability testing to surface the core conflict: researchers negotiating competing FORC claims
  • Facilitated an inception workshop to align cross functional stakeholders
  • Conducted moderated think aloud sessions with Research Champions and Faculty Administrators, producing prioritised findings that shaped the Bulk Coding and Portfolios modules

  1. Stakeholder Alignment

    • Inception workshop with cross functional stakeholders
    • Business Model Canvas mapping
    • Risk and tradeoff identification
    • Product roadmap sign off

  2. User Research

    • Persona development (4 user types)
    • Structured interview question plan
    • Moderated think aloud sessions with 5 participants
    • Synthesis of goals, pains and needs

  3. Design Synthesis

    • 6 key findings identified and prioritised
    • Severity ratings assigned (High / Medium / Low)
    • Design implications mapped per finding
    • Recommendations fed into Phase 2 backlog

Business Strategy Alignment Workshop

Business Model Canvas

  • Mapped value propositions, key activities and partner relationships
  • Established how Radar creates and captures value for the university
  • Identified revenue streams tied to ERA compliance outcomes

Neighbours & Stakeholders

  • Identified 20+ cross functional stakeholders across Library, ADR, DevOps, Finance and Faculty Research
  • Mapped dependencies, influence and sign off responsibilities across teams
  • Agreed communication cadence across distributed and offshore teams

Risks & Tradeoffs

  • ARC rule changes mid development cycle
  • Remote collaboration challenges with the offshore team
  • QA coverage gaps and scope creep from iterative user feedback
  • Dependency on finance data sign off before submission

Product Roadmap

  • Research Outputs and Portfolios (Phase 2 core)
  • Data Quality dashboard and validation workflows
  • Income View with finance team integration
  • Applied Measures and Bulk Coding automation

Key outcomes

  • Alignment on primary goal: a complete ERA solution
  • Consensus on reducing 15,000+ manual coding hours
  • Roadmap signed off across 6 key modules
  • Shared understanding of ARC compliance constraints
  • Agreement on peer review, finance sign off and QA cadence

Personas

The research produced four personas, from the academic claiming a paper to the ERA manager checking the submission.

Research Champion

Faculty Research Manager

A senior faculty administrator responsible for coding research outputs, managing ERA submissions and negotiating FORC claims on behalf of their faculty.

Handles high volumes of outputs across multiple researchers simultaneously, often under tight ERA submission deadlines.

“I need to see what's uncoded, filter by department, and get through it fast, without jumping between pages.”
Persona quote

Goals

  • Bulk code research outputs efficiently across departments
  • Avoid manual spreadsheet errors and version conflicts
  • Optimise ERA submission outcomes and claim percentages

Pain points

  • Coding in Excel is slow, prone to error and hard to audit
  • Hard to filter and manage 400+ uncoded outputs at once
  • No visibility into coded vs uncoded without manual checks

Needs

  • Bulk selection and coding across multiple pages
  • Author name and department as primary search inputs
  • Progress indicators: coded / uncoded / invalid counts
  1. Faculty Research Manager, Research Champion. A senior faculty administrator responsible for coding research outputs, managing ERA submissions and negotiating FORC claims on behalf of their faculty. Handles high volumes of outputs across multiple researchers simultaneously, often under tight ERA submission deadlines. Quote: I need to see what's uncoded, filter by department, and get through it fast, without jumping between pages. Goals: Bulk code research outputs efficiently across departments. Avoid manual spreadsheet errors and version conflicts. Optimise ERA submission outcomes and claim percentages. Pain points: Coding in Excel is slow, prone to error and hard to audit. Hard to filter and manage 400+ uncoded outputs at once. No visibility into coded vs uncoded without manual checks. Needs: Bulk selection and coding across multiple pages. Author name and department as primary search inputs. Progress indicators: coded / uncoded / invalid counts.
  2. Academic / Author, Researcher. An academic author whose research outputs need to be coded and claimed for ERA submission. Often unaware of coding rules and dependent on champions. Works on individual papers; needs to claim FORC percentages and negotiate claims with coauthors or resolve disputes. Quote: I shouldn't have to ring someone to find out what percentage I'm allowed to claim. Just show me. Goals: Claim correct FORC percentages for individual outputs. Resolve coding disputes with coauthors quickly. Understand ERA eligibility without needing external help. Pain points: Conflict with other claimants on shared research papers. Complex, undocumented negotiation process between researchers. Unclear system logic for splitting percentage claims. Needs: Clear visibility of who else has claimed on a paper. Simple dispute workflow with notifications and resolution steps. Plain language explanation of FORC eligibility criteria.
  3. Portfolio & Data Administrator, Faculty Admin. A central administrator who manages portfolios, oversees data quality, and supports researchers and champions across the university. Manages multiple modules simultaneously across faculties, acting as a bridge between system data and ERA submission requirements. Quote: When data shifts across modules after a save, I lose my place, and I'm managing dozens of portfolios. Goals: Assign portfolios and bulk overwrite individual claims. Ensure data quality and completeness before ERA submission. Support researchers and champions across multiple faculties. Pain points: Pagination resets after saving, so the page position is lost. Incomplete or conflicting data across different modules. Slow peer review and sign off workflows block progress. Needs: Persistent page state after save actions. Data quality dashboard across modules, with a validation summary. Peer review tagging and a workflow to flag items for review.
  4. Deputy ADR / Senior Compliance, ERA Manager. A senior compliance stakeholder responsible for validating ERA submission readiness, running scenario tests, and ensuring ARC threshold compliance. Operates at a strategic level, and needs to simulate ERA outcomes under different configurations before committing to submission. Quote: I want to play with the data. Show me what happens to our ranking if I remove these 50 publications. Goals: Validate ERA submission readiness across all research areas. Run scenario tests to optimise grant outcomes. Ensure ARC compliance thresholds are met at four digit FORC level. Pain points: No system to simulate ERA outcomes before lodging. Relying on finance spreadsheets for income coding and sign off. Risk of ARC rule changes partway through development. Needs: Scenario testing with threshold visualisation. Integrated income data with a finance team sign off workflow. Submission readiness dashboard by FORC code and faculty.

Findings

Five think aloud sessions produced six findings, each rated by severity and paired with a design implication.

  • High severity

    Search & Filter Behaviour

    Users search easy FORC codes first and rely heavily on department and author name as primary filters. MQ ID alone is insufficient.

    Design implication

    Department and author name must be primary search facets. MQ ID should be secondary or removed from the default view.

  • High severity

    Results List Priorities

    Title, Author, Journal and ARC Journal FORCs are essential columns. Year is secondary. Abstract and PDF belong under 'More Info'. All columns must be sortable.

    Design implication

    Results list needs a sortable column architecture with progressive disclosure via a 'More Info' expand.

  • High severity

    Bulk Coding Workflow

    100% should be the default FORC percentage. Users want to submit periodically per row, not batch at the end. Selecting across pages is essential.

    Design implication

    Default the claim to 100% automatically. Enable submitting per row, and selection across pages with persistent state.

  • Medium severity

    Invalid Codes Management

    Users expect to sort by invalid status. MVP proposal: show invalid outputs as a separate list, with an option to save them to a custom list.

    Design implication

    The invalid list needs its own view, with an option to save to a custom list. It is a separate workflow, not just a filter.

  • Medium severity

    Scenario Testing

    ERA managers need to simulate submission outcomes: check thresholds and identify which codes to boost or remove before lodging.

    Design implication

    A business intelligence layer is needed: threshold visualisation and submission simulation by FORC code and faculty.

  • Low severity

    Onboarding & Navigation

    The tour is useful for champions but users want to skip straight to search. An option to skip or return to the tour at any time is needed.

    Design implication

    Design explicit 'skip' and 'resume tour' affordances. Don't force onboarding as a gate to searching.

Recommendations from the findings fed into the Phase 2 backlog.

User research

Interview questions

Participants
5
Roles
Research Champions & Faculty Administrators
Method
Moderated think aloud sessions

Discovery & First Impression

  • What is your first impression of the Bulk Coding tool?

  • Would you take the tour or start searching immediately?

  • Is the onboarding tour clear and useful?

  • What would you expect to see on arrival?

Search & Filtering

  • Which categories would you search first?

  • Do you expect additional filters: Author FORC, ARC Journal FORC?

  • Would you prefer a general AND/OR search over fixed categories?

  • How do you prioritise which FORC codes to address first?

Results & Bulk Coding

  • What columns are essential for bulk coding efficiency?

  • Do you prefer to code totally uncoded outputs, or existing claims?

  • What information belongs under a 'More Info' expand?

  • How many items would you want visible per page?

Validation & Workflow

  • How do you identify and handle invalid FORC codes?

  • Would you submit periodically, or all at once?

  • What would you do with a list of invalid claims?

  • How likely are you to return to the coded list later?

Information architecture

I mapped how research outputs, portfolios and coding workflows related to each other before anyone designed a screen. The module structure followed ERA reporting logic rather than visual convention, and it had room for future modules without restructuring.

I workshopped the IA with engineers and Macquarie stakeholders, and the sessions surfaced navigation gaps early. The gaps sat particularly around the ambiguous handoff from individual output coding to portfolio level coding, where claims needed to resolve to 100%.

The IA gave the development team one structural reference. Decisions about data hierarchy, states such as negotiation status and coding complete, and screen flow all came from the same logic, rather than each engineer interpreting them alone.

  • Screen
  • Decision
  • System
  • Future module
Individual output coding

Research Outputs

Every paper, with its claim status: over, under, invalid or valid

view a paper

Output Detail

Researchers add or edit a claim in percentages

Claims total 100%?

Negotiation status

Researchers negotiate their claims to reach 100%

Coding complete

Claims need to resolve to 100%

The ambiguous handoff: individual output coding into portfolio level coding, where claims needed to resolve to 100%.

Portfolio level coding

Portfolios

Faculty administrators create portfolios and assign research papers to them

code the portfolio

Portfolio Detail

Portfolio coding overwrites the individual percentage claims of its papers

room for
  • Researchers
  • Income View
  • Data Quality

The structure could take these modules later without being reworked.

Key decisions

Claim conflicts

The Radar prototype shows the conflict on the paper itself, with both claims marked Conflict and the total over by 100%.

Researchers add a claim to each paper as a percentage, then negotiate until the claims reach 100%. When they coded papers by hand in Excel sheets, that negotiation turned into conflict and wasted time and money.

Claims total 200% — over by 100%. Escalate disputes if they can’t be resolved.

  • Claim

    Conflict

    Benjamin Jackson

    100%

  • Claim

    Conflict

    Sally Kensington

    100%

Phase 1 · Research Outputs

Benjamin Jackson and Sally Kensington had each claimed 100%. They would contact each other and either escalate the dispute to the faculty or negotiate between themselves to split the claim.

Portfolios

Faculty administrators code a whole portfolio, and that coding overwrites the individual percentage claims of its research papers.

Phase 2 · Portfolios module

Faculty administrators create portfolios and assign research papers to them. Radar calculates each portfolio automatically, so users can work efficiently and concurrently.

Data quality

Radar lists every data error by the rule it breaks and the type of record it affects.

Phase 2 · Data Quality module

This module assists managers and administrators in managing data quality of all modules.

The outcome

Achievements

Phase 1

Reporting efficiency
Increased research reporting efficiency by 30% through streamlined data submission
Data preparation
Reduced staff count and hours spent on data preparation
Decision making
Improved strategic decision-making accuracy by 20% by surfacing key research investment areas

Phase 2

Phase 2 added Portfolios, so faculty administrators could code a group of papers at once.

Delivery
Delivered six modules end-to-end, replacing manual spreadsheet processes
Coding accuracy
Reduced coding mistakes across all modules, cutting rework and staff hours
Feedback
Attained positive feedback across all four user types

Phase 2 also brought Data Quality, a module that helps managers and administrators manage data quality across all modules.