Inspera AS (EdTech / B2B / Webapp) - 2025
Dashboard proposal reduces item retrieval time from 30s to 7s
User research
Wireframing
Prototyping
A/B testing
Visual Design



TEAM
1 Product Designer
1 Product Manager
1 Tech Lead
2 Back-end Engineers
1 Full Stack Engineer
TIMELINE
7 Months
BACKGROUND
Inspera Assessment is a digital exam platform used by universities and awarding bodies. An Item Bank is the container for assessment content, questions and question sets. It is the source exams are built from, and the architectural foundation for Automated Test Construction (ATC), IRT, psychometrics and analytics for assessing an exam's objective and planning.
A limited version of Item Banks existed, but the goal was to take them to General Availability for Higher Education (other customers). The constraint was to do it without disrupting existing awarding-body customers, and without over-serving a segment that ranges from a single academic working in isolation to consortia running consistent exams across 20+ campuses.
The working analogy the team adopted was a workspace in Confluence or a project in Jira: a place that defines who has access, what they can do, and how content is treated across its lifecycle.
MY ROLE
Item Banking touched permissions, metadata, roles, analytics and automated test construction, a complete system with possibilities. I worked the problem in sequence: understand the users, audit the current product, benchmark the category, then scope the design against a phased roadmap. I proposed a dashboard for improved work flow, data management, and future features, which came out of that process.
"I joined Inspera as one of the five designers in the company. Although I mentored a Junior Designer, for this project I was the only designer responsible to drive and lead product design initiatives across key parts of the application experience."
User Research
Planning, workshops and archetype synthesis with the product managers, tech team and customers.
Current-state analysis
Audited how Item Banks, sharing and permissions worked today, its limits and what worked.
Competitor analysis
Benchmarked against Questionmark, ExamSoft and Canvas, and weighed feature possibilities.
Insights
and roadmap
research + analysis into decision-ready findings, and planning deployment features.
Dashboard proposal
Concluded a need for a new discovery surface; which got implemented into the pipeline.
THE TANGIBLE AND INTANGIBLE IMPACT
Design and the product experience played a crucial role in the overhauling of this project. The value added speaks for themselves. The quantitative figure reflects a task-timed comparison of locating a known item under the current list model versus the proposed dashboard. The qualitative gains are capabilities the roadmap did not previously have a place for.
Tangible
Time to locate a specific item in a bank,
a ~4× reduction
on the most repeated task in an author’s day.
Stakeholder alignment
One agreed problem framing and a sequenced of planned features in the roadmap, agreed across PM, engineering and Business strategy.
Foundation for rebuild
A home for bringing AI led decision making for authors, using ATC, IRT and analytics, which depended on banked, well-tagged metadata of content.
Access and governance
Role-specific workflow and visibility of who can access a bank or co-create, with grant, revoke and copy permissions
Space for real retrieval
Dashboard proposal enabled a robust query builder across metadata, learning outcomes, status and usage, replacing title-string search.
PROBLEM STATEMENT
Content had outgrown the model that held it.
As a bank’s content grows, authors lose overview of what they have. Questions sit in one list, filterable only on the most basic categories. Sharing is done one item at a time. And once a user has access, they can do anything to the content - including break it. We quickly realised we couldn't ship the product in its current state.
The four horsemen of fundamental gaps
Discovery.
No meaningful filtering or querying. No reliable way to find an item to reuse, or know which version was current, or find the item you worked on last night.
Control.
In current version, Item Bank access meant full control. The lack of role-specific permissions, QA workflow or audit trail decreased credibility.
Access.
No master view of who could see what. Sharing was manual and could only be done via email, making it impossible to organise and audit.
Trust.
With no visibility into where an item was used or how it performed, authors rewrote rather than reused, which was a data storage concern
Research plan, then evidence
Because every PM held a slightly different model of the problem, I structured the research before running it: two facilitated FigJam sessions to agree what we needed to learn, feeding three live customer workshops and synthesis against Inspera’s user archetypes.



Method
A UX research plan defined the questions, participants and timeline; an alignment workshop set the shared frame for problems, assumptions, success criteria and scope.
- Research workshop
- Alignment workshop
- 3 Customer sessions
- Archetype fabrication
Cross-functional participants across design, product and engineering.



"Psychometrics and ATC mattered, but customers ranked everyday access and retrieval first. The foundation had to come before the ambition."
Author Feedback
"Users asked explicitly for and/or/not conditions and inclusive vs exclusive filtering across multiple tags, an ask which could be fulfilled by a query builder."
Author Feedback
"Authors couldn’t see which question sets or tests an item was used in, so they duplicated instead of reusing, which eroded item bank integrity and inflating volume."
University Sessions
"Codes and abbreviations were being embedded in question titles because the product offered no other route to find content. A retrieval problem, surfacing as a naming problem."
Customer Workshops
“Someone left the post; someone new needs the same access” came up repeatedly, with no way to copy or transfer a person’s permissions."
Alignment Workshop
THE USER AND THEIR LAYERED ROLES EXPLAINED
A single person can hold multiple roles, for example, the question paper author can also be the grader of the examination paper. There is a scope of external faculties too. Hover/tap to interact, switch the toggle to see user role functions.
Key Insights
The insights were cruicial to understand our multilayered users and their requirements.
Primary
Author
Compose clear questions aligned to learning objectives.
Pain
-
Discovery hindered by weak organisation and manual process; low awareness of what’s reusable; no bulk handling; repeats outdated items for lack of performance data.
Opportunity
-
Ease content management with metadata, hierarchy and structure; surface data that encourages reuse of strong items.
Primary
The Admin
Manage users, groups and their access to roles based operations at scale.
Pain
-
Balancing efficient administration with security and integrity; custom roles (e.g. external graders) are fiddly to create and keep consistent.
Opportunity
-
A comprehensive interface to track and oversee access, and an easier path for custom-role use cases.
Supporting
Planner · Grader · Proctor
Design, mark, invigilate and sit exams built from banked content.
Their significance
-
Item Banking sits upstream of everyone: planners assemble tests from banks; graders depend on well-tagged, psychometric data (bloom's taxonomy), versioned items; candidate integrity rests on trustworthy content.
Implication
-
Decisions on roles, metadata and versioning ripple far beyond the author.
DESIGN GOALS
Before sketching screens, I turned the research, current-state audit and competitor benchmark into explicit targets splitting into UX parameters (how it should feel to use) and product parameters (what it must enable). These became the yardstick every design decision was measured against.
UX parameters (experience)
-
Findability. Locate a known item by querying, not scanning a list.
Target · faster content finding capability
-
Expressive retrieval. Filter with and/or/not logic across multiple tags.
Outcome · query success without workarounds
-
Disambiguation. Tell versions and duplicates apart at a glance via status and provenance.
Signal · fewer “which one?” moments
-
Low-friction access change. Grant, revoke or copy a colleague’s access in a few steps.
Outcome · fewer access support tickets
Product parameters (capability)
-
Governance. Role-specific permissions, a QA workflow and an audit trail on shared content.
Enables · trustworthy shared banks
-
Reuse over rewrite. Surface where an item is used and how it performs, so reuse feels safe.
Outcome · reuse rate up, duplication of file down
-
Scalability. One model serving low-to-high sophistication without disrupting awarding bodies.
Constraint · no disruption to AWBs
-
Extensibility. A foundation ATC, IRT and analytics can plug into later.
Enables · the forward roadmap
MY DESIGN APPROACH : SOMETIMES YOU GOTTA RUN BEFORE YOU CAN CRAWL
WHY I PROPOSED A NEW UTILITARIAN DASHBOARD?
The research and analysis pointed the way. Access and retrieval ranked highest, provenance blocked reuse, filtering needed logic, the category treated content as a governed, searchable surface. Banks, roles and metadata answered structure but none of it was visible in one place. The missing layer was a surface that made the new structure usable.
So I proposed a dashboard, and put a measured case to the product team.
...is the drop in average time spent on finding the items you worked on yesterday. Solving what faculties use the most, and a gateway for scalability.
Discovery
Find any item in seconds
Quick access via dashboard, a real query builder across metadata, outcomes, status and usage.
Access
See and grant access
A master view of who can access a bank, with grant, revoke and copy-access, with multi-level admin access.
Operations
Act in place
Move content, set QA status, and manage duplicates with item health checker without leaving the page.
The dashboard was presented as evidence-backed scope, opening the door to future scalability, tied directly to the needs and the current-state gaps. It was well received and taken into the pipeline as the discovery surface for Item Banking, and the natural home for the capabilities the roadmap adds later (ATC, IRT, analytics).
Older Flow:
Here I show a comparison between the older flow and the newer flow. The flow is of creating a new Question Set after logging in as an Author.

New Flow:

Other parts of the project that was under the scope, hover to know more.
What the work moved
Goals, revisited: the targets were met, along with the utilitarian dashboard that I proposed (30s → ~7s) file retrieval, governance and access-change moved from workarounds to first-class flows, scalability and extensibility were secured by designing for Run and scoping backwards.
A shared problem frame
The alignment sessions replaced competing mental models with one agreed framing of problem, vision and scope.
Evidence-led scope
Research, current-state and competitor analysis converged on the same priority — discovery and governance before advanced features.
A proposal in the pipeline
The dashboard was accepted as the discovery surface for Item Banking, and the home for later ATC/IRT/analytics work.
A roadmap the business could commit to
Crawl / Walk / Run gave sales, onboarding and engineering a sequenced path from low-sophistication HE to awarding bodies.
Reflection
The most useful judgement call was resisting the instinct to keep adding capability. Banks, roles and metadata were all worth building, but the evidence said they’d go unused without a surface to reveal them. Naming that, and backing it with ranked needs and a category benchmark, is what turned an idea into accepted scope.
Next, I’d instrument the dashboard from day one, supported by demonstration to customers, users and testing through high fidelity prototypes. moving a 30+ second task-timed observation to a continuously measured baseline of under 10 seconds, providing scalability of the product for the use of item-health signals, item reuse directly, with good copy and UX to improve the workflow.








