Five lenses,
one inspection.
Every Bayrust audit uses all five. Each lens looks at your product from a different angle, so together they catch what a single kind of test would miss: from a confusing label to a payment rule that quietly breaks on salary day. Here is exactly what each one covers.
Usability
Can people finish what they came to do?
If people can’t complete the task, nothing else matters. Usability rust shows up as support calls, abandoned journeys and staff who keep a cheat sheet taped next to the screen.
- Task completion on your most important journeys
- Clarity of labels, instructions and error messages
- Navigation, dead ends and loops
- Forms: required fields, defaults and validation
- Consistency across screens and platforms
Typical rust we find
What you get
Each journey scored from start to finish, with the exact step where people get stuck.
Accessibility
Does it work for everyone?
Customers who rely on screen readers, larger text or a keyboard are locked out when the basics are missed. Accessibility is also increasingly expected by partners, funders and regulators in public and financial services.
- Screen-reader walkthroughs with TalkBack and VoiceOver
- Keyboard-only navigation and focus order
- Colour contrast and text resizing
- Labels, alternative text and error announcements
- Every failure mapped to WCAG 2.2 AA
Typical rust we find
What you get
A WCAG 2.2 AA conformance summary you can share with partners and regulators, with every failure tied to its criterion.
System logic
Do the rules behave as the business intends?
Logic rust is the most expensive kind. Nothing looks broken; the product just quietly does the wrong thing, like charging twice or approving what should be rejected.
- States and transitions: pending, paid, failed, reversed
- Business rules and their edge cases
- Integrations: payments, SMS and third-party services
- Error handling and recovery
- Permissions and roles
Typical rust we find
What you get
A map of every state we tested, with each contradiction and silent failure marked.
User habits
Does it fit how people really behave?
Products are designed for an ideal user. Real users share phones, switch languages, screenshot their codes and invent shortcuts. When the product fights those habits, people work around it.
- Interviews and observation with real users or staff
- Device, language and connectivity patterns
- Workarounds and shadow tools: notebooks, spreadsheets, WhatsApp
- Feature discovery and repeat use
- Analytics review, where data is available
Typical rust we find
What you get
A habits profile of your users, showing where the product works against them.
Operational requirements
Does it survive real conditions?
A product that works in the office can fail in the field. Network drops, shared devices, peak days and shift changes are normal conditions, not edge cases.
- Slow, unstable and offline connections
- Mobile-money, card and USSD payments followed end to end
- Low-cost and older devices
- Shared devices, sessions and sign-outs
- Peak days such as month-end and salary day
- Handovers between staff, shifts and branches
Typical rust we find
What you get
A conditions report showing how the product behaves in each environment we tested.
Rust rarely belongs to one lens
The worst problems sit where lenses overlap. A payment that confirms too early is a logic error, made worse by slow networks, and confusing to the customer who sees it. Looking through all five at once is how we find the cause, not just the symptom.
Payment marked successful before the mobile-money callback returns
- CauseSuccess is shown before the payment callback returns.
- Made worseOn 3G the callback arrives 2 s later, so the gap grows.
- Felt asCustomers pay again, sure the first payment failed.
One fixShow a pending state until the callback confirms.