Useful, clear and thoughtful tools that make an important job easier, safer or more effective.
Back to the basics.
We will build our work on two foundations. If an activity does not strengthen either one, we should question why we are doing it.
Reliable delivery, careful adoption and lasting support—so a good idea becomes a genuinely better experience.
Our mission
To make great tools for people changing our world in positive ways—small and big.
What we expect from you.
At Genlab Solutions, developers are product thinkers. Whether you are new or experienced, these are part of the job—not optional extras.
Never begin with “the system needs.” Name the person, their job and the real-world consequence of their work.
Ask questions, observe the current workflow and confirm the problem. Do not turn assumptions into features.
Consider clarity, speed, safety, reliability, accessibility and support.
Remove steps, concepts and code before adding more.
Explain what your choice improves, what it costs and what good work it displaces.
Test with the intended customer or credible evidence. “It works on my machine” is not completion.
A great product is only half the work.
Implementation is the experience of bringing our tools into people’s real work. It includes every relationship, conversation, training session, response and follow-through with customers, system users, funders and stakeholders.
Our service promise
Make every person feel heard, respected and supported.
The quality of our relationship must match the quality of our product.
Be human, patient and genuinely interested. Learn their names, responsibilities, environment and definition of success.
Let people finish. Ask questions. Confirm what you heard in their language before proposing a solution or defending the system.
Acknowledge concerns promptly, even when the full answer will take time. One person owns the issue until it is resolved—customers should not have to chase us or repeat themselves.
Provide clear call and chat channels, dependable availability and an obvious route for urgent needs. When immediate resolution is impossible, say what happens next and when.
Tell the person what changed, what did not change and why. Their input must never disappear into silence.
Know the people, goals, workflow, constraints and measures of success.
Agree on responsibilities, readiness, timing, training and communication.
Guide adoption, observe real use and make help readily available.
Acknowledge, own, update and resolve concerns with urgency.
Turn feedback into better products, support and future implementations.
The customer is the authority on their problem and experience. Treat their input with the seriousness a boss deserves. This does not mean building every request exactly as proposed; it means understanding the need, making a thoughtful decision and always explaining what we will do next.
Implementation self-review
Use this throughout onboarding, deployment and ongoing support—not only at the end.
Before you build anything.
For every component, feature, bug fix or product, start with the customer experience and work backward to the technology. You should be able to tell this story before implementation begins.
01
Know the person
Identify the specific customer. Understand their role, environment, responsibilities and the people who depend on their work.
02
See today clearly
Observe the current experience as it really is—not as a process document says it should be. Find the delays, risks, confusion and workarounds.
03
Describe the better experience
State what should become faster, clearer, safer or more empowering. This desired experience defines the innovation we need.
04
Find the constraint
Identify what currently prevents that experience. Then choose the simplest effective product, process or technology that removes it.
Should I work on this?
Use this gate before starting and whenever the work changes. Answer honestly. “I do not know” means pause and find out.
The five-question decision gate
Choose yes or no for every question. The recommendation will appear below.
01
Can I name the specific customer?Not “users.” A real role in a real context.
02
Do I understand their current and desired experience?I can describe the difference in the customer’s language.
03
Does this work remove an important constraint?It addresses a root cause, not merely an interesting symptom.
04
Will the customer experience become meaningfully better?Safer, clearer, faster, more reliable or more empowering.
05
Is this the simplest valuable solution—and important now?It earns the time and attention it takes from other work.
Answer all five questions.
Good work begins with clarity, not code.
What good reasoning looks like.
A feature proposal should be explainable in a few clear sentences. Here is a simple example.
Worked example
Notify a clinician when a critical result is ready
Customer
A clinician treating a patient whose laboratory result requires urgent action.
Current experience
The clinician must repeatedly check the system or wait for a manual call, causing uncertainty and possible delay.
Desired experience
The right clinician is alerted promptly, understands why the result matters and can acknowledge it.
Constraint
The system does not reliably connect a critical result to the responsible clinician at the moment action is needed.
Decision
Build the smallest reliable alert-and-acknowledgement flow. Do not begin with a general-purpose messaging platform.
How our interfaces should feel.
Calm, obvious and respectful of the user’s attention. Simplicity is not decoration removed for its own sake; it is complexity understood and resolved.
At one glance, the user should know what matters, understand what to do next and feel confident doing it.
One page, one main message.
Decide what the user should remember after a single glance. Make that message unmistakable through placement, scale and restraint. Secondary information must support it—not compete with it.
Typography creates hierarchy.
Use no more than two font families unless an additional face has a clear informational or functional purpose. The minimum type size is 11px, and 11px should appear only in rare, non-essential supporting text. Important content must be comfortably readable.
Color must mean something.
Build the interface primarily with black, white and neutral tones. Reserve each product’s brand accent—such as LabXpert green—for emphasis, status and intentional actions such as primary buttons. If everything is highlighted, nothing is highlighted.
Space is part of the interface.
Use generous, consistent white space to group related information, separate ideas and give the user room to think. Do not fill empty space merely because it exists.
Remove until clarity suffers.
Every icon, line, shadow, label and piece of text must clarify meaning, establish useful depth or enable an action. If removing it changes nothing for the user, remove it.
Make the obvious action obvious.
Primary actions should look primary. Labels should say what will happen. Familiar patterns beat clever interactions when the user needs to work quickly and safely.
Care lives in the details.
Alignment, spacing, language, states, feedback and error handling should feel intentional. A clean screen that fails in loading, empty or error states is not a complete experience.
Interface self-review
Complete this before requesting design review or marking interface work ready.
If an item is unchecked: refine the interface or explain the intentional exception. “It looks good” is not enough; every decision should help the customer understand or act.
How we know the work is great.
Good intentions are not enough. We measure the reliability of the system, the success of its implementation and the quality of the experience developers deliver.
Is the product accurate, reliable and responsive when people depend on it?
Is the product being adopted and producing the intended operational result?
Is the interface fast, stable, accessible and technically well delivered?
System key performance indicators
These are service commitments. Teams should review them regularly and investigate the cause of every sustained miss.
| Indicator | Target |
|---|---|
| Data accuracy | 99.9% |
| System uptime | 99.9%At least 95% of critical issues resolved each month. |
| Mean time to respond to non-technical user queries | Within 2 hours |
| Mean time to resolve critical data-quality issues | Within 1 working day |
| Mean time to resolve critical system bugs | Within 1 working day |
| Mean time to deploy requested non-critical improvements | Within 5 working days |
| User-experience rating | 5 stars |
Implementation key performance indicators
A working system is not a successful system until it is consistently used and improves the real service.
| Indicator | Target |
|---|---|
| GeneXpert monthly reporting rate | At least 85% |
| mPima monthly reporting rate | At least 85% |
| Riders tracking samples through ResTrack each month | At least 95% |
| Samples with impossible or negative turnaround times | 0% |
| Samples with incomplete tracking, such as picked up but never delivered | Below 5% |
| Clinician requests in IRRDS without sample-collection information | Below 1% |
| Dispatched results downloaded or viewed at the requesting site | At least 95% |
| Hub commodity requests to CPHL receiving a response within 2 working days | At least 95% |
Developer experience and quality indicators
Run Lighthouse on representative, production-like pages. Use field data where available because laboratory tests cannot reproduce every user’s device, network and interaction.
| Indicator | Target |
|---|---|
| Lighthouse Performance score | 90 or higherTest representative mobile and desktop journeys. |
| Lighthouse Accessibility score | 90 or higherCritical accessibility failures must still be fixed; the score is not a substitute for manual review. |
| Lighthouse Best Practices score | 90 or higher |
| Largest Contentful Paint (LCP) - main content visible | 2.5 seconds or less |
| Interaction to Next Paint (INP) - response to user interaction | 200 ms or lessMeasure from real-user field data where possible. |
| Total Blocking Time (TBT) - laboratory proxy for responsiveness | 200 ms or lessUse in Lighthouse when INP field data is unavailable. |
| Cumulative Layout Shift (CLS) - unexpected visual movement | 0.1 or less |
Measure Core Web Vitals at the 75th percentile of real page loads, separated by mobile and desktop where practical. Lighthouse scores can vary with hardware and network conditions, so use a consistent test setup and track trends rather than relying on a single run. Technical thresholds follow current Core Web Vitals and Lighthouse scoring guidance.
When to stop or ask.
Stopping unclear or low-value work is responsible engineering. If you cannot pass the decision gate, do not quietly guess.
Every “yes” consumes time, care and attention. We choose deliberately.
Continue
When the customer, desired experience, constraint, expected improvement and priority are all clear. Implement simply, test the experience and share what you learn.
Pause and clarify
When any answer is unclear or “no.” Speak with the product owner, a domain expert or the customer. Revise, reduce, defer or stop the work—do not hide uncertainty under more code.
We do not measure your impact by how much code you ship. We measure it by how much better people can do their important work.
The Genlab Solutions product principle