The Saint Line

Case study

Loola

Pre-launch

A QA platform that puts test management, quality and risk scanning, and regulatory compliance in one loop, with AI that drafts test cases for people to review.

The scripted part of this conversation carries the verified facts. Live answers only use what's on this site.

Role
Product Designer · Studio Doresh client
Timeline
Jul – Aug 2026
Status
Pre-launch

Hi, this is Loola, a QA platform I designed for The Bug Detective through Studio Doresh. It's in pre-launch. Ask about anything, or just scroll.

What is Loola?

Thought for 2s

Loola is a QA platform that puts three jobs most teams spread across tools into one product: test management, quality and risk scanning, and regulatory compliance. Its line is "Quality, on loop": findings from a scan flow back into the tests, and the tests feed the compliance picture. It's a product of The Bug Detective, and it's in pre-launch, with early access open at withloola.com.

Loola project overview: activity breakdown, test coverage and defects by severityLoola scan report: a Trac Score with quality, risk, security and compliance scores and an executive summary
Test management and a scan report, in one product.
pillars: test management, quality and risk, compliance
3pillars: test management, quality and risk, compliance
product screens designed
75product screens designed
design system shared by every screen
1design system shared by every screen

What did you do on Loola?

Thought for 3s

Loola is a Studio Doresh client, and I worked on it from July to August 2026. I designed the product: the information architecture across the three pillars and every flow from sign-up to evidence package. The logo already existed; from it I created the full design system the screens are built from. Engineering is The Bug Detective's. The screens use sample workspaces and companies to look real; none of them are Loola's customers.

What problem is Loola built for?

Thought for 4s

Quality work in a growing software team usually lives in three disconnected places: test cases in a spreadsheet or a dedicated tool, security scans in another, and compliance as a checklist someone fills in before an audit. Each one knows nothing about the others, so a failed scan doesn't become a test, and a passing test suite says nothing about regulatory risk. For Nigerian fintechs, that last gap carries real penalties.

Then · Usually

Test cases in one tool, scans in another, compliance in a spreadsheet before the audit. Nothing connects.

Now · With Loola

One workspace where scan findings become tests, and tests and scans feed a compliance posture you can hand to an auditor.

Why put three products in one?

Thought for 2s

Because the value is in the connections. A scan finds an unencrypted payments endpoint; Send findings to Test Management turns it into tracked work; the next scan confirms the fix; the compliance view shows PCI-DSS moving from failing to passing. I gave the three pillars one sidebar and one visual language, so moving between them feels like changing views of the same product, not switching apps.

Quality, risk, security and compliance checks run against a URL, an APK or an API spec.

Loola Projects: every project with its test cases, open defects and coverage, and the three pillars in the sidebarMy Scans: a risk-score trend and every scan across the workspace's apps

How does a team get started?

Thought for 3s

Sign-up runs straight into a four-step setup: name the workspace and its sector, create the first project, pick a sector template, and invite the team. The templates are pre-built test case libraries for fintech, healthcare, e-commerce, SaaS and education, so a fintech team starts with payment, wallet and KYC cases instead of a blank page.

Loola sign-up: create your accountWorkspace setup: sector and team sizeStart with a template: fintech, healthcare, e-commerce, SaaS, education or blankYou're all set: workspace, first project and template applied
Sign-up to a working project in four steps.

Where does AI come in?

Thought for 4s

In Trac with AI. You describe your app with a URL, an APK or an OpenAPI spec, and Loola generates test cases for it. I designed the results as a review step, not an import: every generated case shows its scenario, priority and module with Keep or Remove, and nothing lands in the project until you choose. Generations are counted on screen, so the cost is never a surprise.

Trac with AI: describe your app with a URL, APK or OpenAPI specScanning in progress: Loola crawls the app and maps findingsAI-generated test cases to keep or remove before importTest cases imported, and editable afterwards
Generate, review, then import.

What does day-to-day testing look like?

Thought for 2s

Each project opens on an overview: total cases, passed, failed and blocked, coverage against what's been executed, and defects by severity. Defects link back to the test case that caught them and carry the environment they were found in. At the end of a sprint, a QA summary report is a click away, previewed before it's downloaded as a PDF.

Project overview: activity breakdown, coverage and defects by severityDefect list linked to test cases, with severity, status and environmentReports across projectsSprint QA summary report, previewed before download

How does a scan work?

Thought for 3s

You pick a target (a URL, an APK or an API spec), choose how Loola signs in, and toggle the modules: quality, risk, security and compliance. While it runs, the scan shows its pipeline step by step (crawl, quality checks, security scan, compliance mapping, AI synthesis, report assembly) with pages, issues and endpoints counted live, so a long scan never looks stuck.

Submit a scan: target, authentication and modulesScanning: the pipeline step by step, with pages, issues and endpoints found

What does the report tell you?

Thought for 4s

It leads with a Trac Score and a score for each pillar, plus how confident the score is. Below that, an executive summary ends in the top three actions, ranked by what matters most. Technical findings map to standards like OWASP and CVEs with a fix for each, and the compliance posture shows which regulations are failing. Every finding can go straight to Test Management.

Scan report: Trac Score, pillar scores and executive summary with the top three actionsTechnical findings by severity, mapped to OWASP and CVEs with a fix for eachCompliance posture: PCI-DSS, NDPR/NDPC and CBN Cybersecurity statusScan history with a risk-score trend

How do you make compliance less intimidating?

Thought for 2s

By starting with the question teams actually ask: what rules apply to me? Choose a country and an industry and Loola lists the frameworks, their controls and what failing them costs, free, before any scan. A short company profile sharpens it: process payments and PCI-DSS applies; handle health data, serve children or operate in the EU and other rules join. Try the logic below.

Tap to tryCountry: Nigeria

Applicable frameworks

  • NDPR / NDPC Act
  • CBN Cybersecurity Framework
  • CBN Open Banking
  • PCI-DSS v4.0
4 frameworks applyBefore any scan

Mirrors the triggers on Loola's Company Profile screen. An illustration of the design, not legal advice.

What rules apply to me? Frameworks for a Nigerian fintech with their controlsCompany profile: the questions that decide which frameworks applyRegulatory findings: every control mapped to its statusA finding opened: what failed, where it was detected, and how to fix it

How does it help when the auditor arrives?

Thought for 3s

An evidence package gathers the timestamped scan report, certificates and the findings log behind a shareable, read-only link for auditors and investors. And where Loola can't verify something, it says so: the self-assessment gives a quick provisional posture in a few questions, labelled "Estimated, not verified" until a full scan confirms it.

Evidence package: a shareable read-only link, documents and the fine and penalty referenceSelf-assess complete: a provisional posture, clearly labelled as estimated, not verified
Proof for an auditor, and honesty about what's only estimated.

How did you build a design system from one logo?

Thought for 4s

I started from the existing logo and grew everything else from it. Its blues became a primitive scale, then semantic tokens (border, icon, action, status), so a status colour means the same thing on every pillar. Type pairs the UI face with IBM Plex Mono for code and IDs. Each component is documented with when to use it and which tokens it uses, and one badge set covers test status, severity, compliance state and pillar. That system is what kept 75 screens consistent.

The Loola wordmark
The existing wordmark the system grew from. I didn't design the logo.
Semantic colour tokens: border, icon, action and statusDisplay type: Quality, on loop.
Colour tokens and type.
Button component with when-to-use notes and the tokens it usesBadge set for test status, severity, compliance state and pillars
Components, each documented with when to use it and the tokens it uses.
semantic colour tokens
33semantic colour tokens
spacing steps
14spacing steps
badge variants for status, severity and pillars
17badge variants for status, severity and pillars

What would you take into the next product?

Thought for 2s

That a platform with several products inside is held together by the connections between them, not by any one screen. That AI output should arrive as a review, not a fait accompli. And that a compliance tool earns trust by being honest about what it can't verify yet.

  • Design the loop, not the pillarsThe send-to-tests button matters more than any dashboard.
  • AI proposes, people decideGenerated test cases are kept or removed before they count.
  • Answer the real question first"What rules apply to me?" before any scan or sign-off.
  • Label estimates as estimatesA provisional posture says so until a scan verifies it.

The scripted part of this conversation carries the verified facts. Live answers only use what's on this site.