GovTech
Business Registration
Research-Led Design
Mobile
Systems Thinking
Rizyk
Rizyk
Rizyk
Structuring chaos into a launchable product government business registration redesigned for the people it was supposed to serve.
Structuring chaos into a launchable product government business registration redesigned for the people it was supposed to serve.
Structuring chaos into a launchable product government business registration redesigned for the people it was supposed to serve.
GovTech
Business Registration
Research-Led Design
Systems Thinking
Mobile
Mobile
Role
Role
Product Designer (UI/UX) | Sole Designer
Product Designer (UI/UX) | Sole Designer
Product Designer (UI/UX) | Sole Designer
Platform
Platform
Mobile + Web Admin
Mobile + Web Admin
Mobile + Web Admin
Context
Uganda · URSB-Aligned
Uganda · URSB-Aligned
Uganda · URSB-Aligned
Type
Type
Client-Based Project
Client-Based Project
The client wanted everything in the MVP. No government approval. No scoped requirements. My first job was not to design. It was to make the product possible.
The client wanted everything in the MVP. No government approval. No scoped requirements. My first job was not to design. It was to make the product possible.
The client wanted everything in the MVP. No government approval. No scoped requirements. My first job was not to design. It was to make the product possible.
My Role
My Role
End-to-end ownership across both sides of the system
End-to-end ownership across both sides of the system
End-to-end ownership across both sides of the system
I designed the full product the mobile application for business applicants and the web admin panel for government reviewers. Both sides. Neither was an afterthought.
When development began, I stayed involved through the full build cycle, answering developer queries, resolving edge cases, and making implementation decisions as the designs moved into implementation.
I designed the full product the mobile application for business applicants and the web admin panel for government reviewers. Both sides. Neither was an afterthought.
When development began, I stayed involved through the full build cycle, answering developer queries, resolving edge cases, and making implementation decisions as the designs moved into implementation.
"Two separate systems. Two different user types. One designer across both. The admin panel received the same design rigour as the applicant-facing mobile app."
"Two separate systems. Two different user types. One designer across both. The admin panel received the same design rigour as the applicant-facing mobile app."
"Two separate systems. Two different user types. One designer across both. The admin panel received the same design rigour as the applicant-facing mobile app."
I designed the full product the mobile application for business applicants and the web admin panel for government reviewers. Both sides. Neither was an afterthought.
When development began, I stayed involved through the full build cycle, answering developer queries, resolving edge cases, and making implementation decisions as the designs moved into implementation.
The Problem
The Problem
A product that could not launch until the scope was redesigned
A product that could not launch until the scope was redesigned
A product that could not launch until the scope was redesigned
Government registration systems often fail users at the point of correction: incomplete submissions receive vague feedback, and vague feedback gives users no clear path to fix what went wrong. In Uganda, that problem was compounded by a product brief that made it difficult to define a launchable digital service in the first place.
Uganda's business registration process is fragmented, opaque, and offline-first. Someone trying to register a business does not know which entity type applies to them, which documents are required, or what happens after submission.
The client brief made this harder. The initial scope included every possible government service in a single MVP. None had government approval to operate digitally. Designing all of them would have produced a product that could not legally launch.
The core design problem was not visual. It was structural. Before I could design a single screen, I had to define what this product was actually for.
Government registration systems often fail users at the point of correction: incomplete submissions receive vague feedback, and vague feedback gives users no clear path to fix what went wrong. In Uganda, that problem was compounded by a product brief that made it difficult to define a launchable digital service in the first place.
Uganda's business registration process is fragmented, opaque, and offline-first. Someone trying to register a business does not know which entity type applies to them, which documents are required, or what happens after submission.
The client brief made this harder. The initial scope included every possible government service in a single MVP. None had government approval to operate digitally. Designing all of them would have produced a product that could not legally launch.
The core design problem was not visual. It was structural. Before I could design a single screen, I had to define what this product was actually for.
Initial Client Scope — 8 services
Business Name Registration
No URSB digital approval
Licensing & Compliance
No digital pathway
Intellectual Property Registration
No digital pathway
Property Conveyance
No digital pathway
Legal Documentation
No digital pathway
Tax Registration
Permit Applications
Land Title Services
✓ Agreed MVP Scope — 5 Entity services
Business Name Registration 5 Businesses Entity
URSB approved
Registry Searches
URSB approved
Partnership
URSB approved
Sole Proprietorship
URSB approved
Limited Liability Company (LLC)
URSB approved
Public Limited Company (PLC)
URSB approved
Initial Client Scope — 8 services
Business Name Registration
No URSB digital approval
Licensing & Compliance
No digital pathway
Intellectual Property Registration
No digital pathway
Property Conveyance
No digital pathway
Legal Documentation
No digital pathway
Tax Registration
Permit Applications
Land Title Services
Why this decision mattered: Services without URSB digital processing approval would accept user fees but could not complete government registration. Designing those flows would have produced a product that legally could not deliver on its promise. The list was short. The client brief was long. The gap was the argument.
Why this decision mattered: Services without URSB digital processing approval would accept user fees but could not complete government registration. Designing those flows would have produced a product that legally could not deliver on its promise. The list was short. The client brief was long. The gap was the argument.
Why this decision mattered: Services without URSB digital processing approval would accept user fees but could not complete government registration. Designing those flows would have produced a product that legally could not deliver on its promise. The list was short. The client brief was long. The gap was the argument.
"The most important design decision happened before Figma opened."
"The most important design decision happened before Figma opened."
"The most important design decision happened before Figma opened."
Government registration systems often fail users at the point of correction: incomplete submissions receive vague feedback, and vague feedback gives users no clear path to fix what went wrong. In Uganda, that problem was compounded by a product brief that made it difficult to define a launchable digital service in the first place.
Uganda's business registration process is fragmented, opaque, and offline-first. Someone trying to register a business does not know which entity type applies to them, which documents are required, or what happens after submission.
The client brief made this harder. The initial scope included every possible government service in a single MVP. None had government approval to operate digitally. Designing all of them would have produced a product that could not legally launch.
The core design problem was not visual. It was structural. Before I could design a single screen, I had to define what this product was actually for.
Research and Discovery
Research and Discovery
The correction gap that shaped the product
The correction gap that shaped the product
The correction gap that shaped the product
I ran desk research on Uganda's URSB registration process to understand the regulatory flows, documentation requirements, entity structures, and what could realistically be included in the MVP. I mapped each business type against its required information and documents before defining the product flows.
The complexity was not just the number of services. Each entity type required different information, documents, and stakeholder structures. These were not UI variations. They were fundamentally different registration flows, which is why defining the MVP through regulatory research had to happen before interface design.
The research also exposed an important correction gap. When submitted documents were incorrect, unclear, or incomplete, applicants could have an opportunity to correct them before the application moved to rejection, but that opportunity was easy to miss when the problem and deadline were not communicated clearly.
I designed Rizyk so Additional Requirements became an actionable state rather than an unclear rejection. The user receives alerts and notifications, sees exactly what needs to be corrected, and can re-upload the affected information before the application closes.
I ran desk research on Uganda's URSB registration process to understand the regulatory flows, documentation requirements, entity structures, and what could realistically be included in the MVP. I mapped each business type against its required information and documents before defining the product flows.
The complexity was not just the number of services. Each entity type required different information, documents, and stakeholder structures. These were not UI variations. They were fundamentally different registration flows, which is why defining the MVP through regulatory research had to happen before interface design.
The research also exposed an important correction gap. When submitted documents were incorrect, unclear, or incomplete, applicants could have an opportunity to correct them before the application moved to rejection, but that opportunity was easy to miss when the problem and deadline were not communicated clearly.
I designed Rizyk so Additional Requirements became an actionable state rather than an unclear rejection. The user receives alerts and notifications, sees exactly what needs to be corrected, and can re-upload the affected information before the application closes.
Core finding: A registration problem should not become a rejection simply because the applicant did not understand what was wrong. The system needed to make the correction, deadline, and next action visible while there was still time to fix it.
Core finding: A registration problem should not become a rejection simply because the applicant did not understand what was wrong. The system needed to make the correction, deadline, and next action visible while there was still time to fix it.
Core finding: A registration problem should not become a rejection simply because the applicant did not understand what was wrong. The system needed to make the correction, deadline, and next action visible while there was still time to fix it.
I ran desk research on Uganda's URSB registration process to understand the regulatory flows, documentation requirements, entity structures, and what could realistically be included in the MVP. I mapped each business type against its required information and documents before defining the product flows.
The complexity was not just the number of services. Each entity type required different information, documents, and stakeholder structures. These were not UI variations. They were fundamentally different registration flows, which is why defining the MVP through regulatory research had to happen before interface design.
The research also exposed an important correction gap. When submitted documents were incorrect, unclear, or incomplete, applicants could have an opportunity to correct them before the application moved to rejection, but that opportunity was easy to miss when the problem and deadline were not communicated clearly.
I designed Rizyk so Additional Requirements became an actionable state rather than an unclear rejection. The user receives alerts and notifications, sees exactly what needs to be corrected, and can re-upload the affected information before the application closes.
Patterns found across the systems I reviewed
Patterns found across the systems I reviewed
Patterns found across the systems I reviewed
What it causes
What it causes
What it causes
Entity selection is a dropdown
Entity selection is a dropdown
Wrong business type selected. Rejected application. Wasted day.
Wrong business type selected. Rejected application. Wasted day.
Wrong business type selected. Rejected application. Wasted day.
Document requirements shown all at once
Document requirements shown all at once
Document requirements shown all at once
Users upload incorrect files. Vague rejection with no specific guidance.
Users upload incorrect files. Vague rejection with no specific guidance.
Users upload incorrect files. Vague rejection with no specific guidance.
Rejected = restart from zero
Rejected = restart from zero
Rejected = restart from zero
Users abandon the process entirely rather than attempt again.
Users abandon the process entirely rather than attempt again.
Users and the knowledge gaps I designed around
Users and the knowledge gaps I designed around
Users and the knowledge gaps I designed around
First-Time Applicant
First-Time Applicant
Does not know which entity type applies to them. Fears making mistakes that waste money.
Does not know which entity type applies to them. Fears making mistakes that waste money.
Small Business Owner
Small Business Owner
Needs to register quickly and correctly. Cannot afford repeated rejections.
Needs to register quickly and correctly. Cannot afford repeated rejections.
Government Admin
Government Admin
Needs to review efficiently, request specific corrections, and maintain accurate records.
Needs to review efficiently, request specific corrections, and maintain accurate records.
Key Design Decisions
Key Design Decisions
The decisions that made the product launchable and usable
The decisions that made the product launchable and usable
The decisions that made the product launchable and usable
Decision 01 — Most Strategic
Decision 01 — Most Strategic
Scope the MVP through research, not client requests
Scope the MVP through research, not client requests
Scope the MVP through research, not client requests
A product that cannot launch serves no user. Scoping was the first user-centred decision I made.
A product that cannot launch serves no user. Scoping was the first user-centred decision I made.
The client’s initial brief included business registration licensing property conveyance intellectual property and legal documentation all in version one. None had government approval to operate digitally.
I proposed restricting the MVP to five business registration types: Sole Proprietorship, Partnership, LLC, NGO, and PLC. scoped for future release. I defined exactly which services were included and which were future work.
Several services in the original brief had no digital processing pathway at URSB. Designing flows for them would have produced a product that could take user money but could not deliver government processing. That is the specific legal exposure. I brought the research showing which services had URSB digital approval and which did not. The list was short. The client's brief was long. The gap was the argument. The client agreed. The product became launchable.
The client’s initial brief included business registration licensing property conveyance intellectual property and legal documentation all in version one. None had government approval to operate digitally.
I proposed restricting the MVP to five business registration types: Sole Proprietorship, Partnership, LLC, NGO, and PLC. scoped for future release. I defined exactly which services were included and which were future work.
Several services in the original brief had no digital processing pathway at URSB. Designing flows for them would have produced a product that could take user money but could not deliver government processing. That is the specific legal exposure. I brought the research showing which services had URSB digital approval and which did not. The list was short. The client's brief was long. The gap was the argument. The client agreed. The product became launchable.
The client’s initial brief included business registration licensing property conveyance intellectual property and legal documentation all in version one. None had government approval to operate digitally.
I proposed restricting the MVP to five business registration types: Sole Proprietorship, Partnership, LLC, NGO, and PLC. scoped for future release. I defined exactly which services were included and which were future work.
Several services in the original brief had no digital processing pathway at URSB. Designing flows for them would have produced a product that could take user money but could not deliver government processing. That is the specific legal exposure. I brought the research showing which services had URSB digital approval and which did not. The list was short. The client's brief was long. The gap was the argument. The client agreed. The product became launchable.
Each tile represents a scoped, approved service, not the full client wishlist.
Each tile represents a scoped, approved service, not the full client wishlist.
Each tile represents a scoped, approved service, not the full client wishlist.
Decision 02
Decision 02
Admin panel built around correction and accountability, not just oversight
Admin panel built around correction and accountability, not just oversight
Admin panel built around correction and accountability, not just oversight
Every admin rejection required a written reason. No invisible decisions allowed in the system.
Every admin rejection required a written reason. No invisible decisions allowed in the system.
I designed the admin panel so that every decision required a written reason before it could be saved. A rejection without explanation does not exist in this system.
An additional requirements request shows the user exactly which document or field needs attention not a general your application needs work message. This decision disproportionately protected the user the person with the least power in a government registration process submitting documents they cannot recover if something goes wrong. The admin audit trail was a secondary benefit. The primary one was giving users a system they could trust.
I designed the admin panel so that every decision required a written reason before it could be saved. A rejection without explanation does not exist in this system.
An additional requirements request shows the user exactly which document or field needs attention not a general your application needs work message. This decision disproportionately protected the user the person with the least power in a government registration process submitting documents they cannot recover if something goes wrong. The admin audit trail was a secondary benefit. The primary one was giving users a system they could trust.
I designed the admin panel so that every decision required a written reason before it could be saved. A rejection without explanation does not exist in this system.
An additional requirements request shows the user exactly which document or field needs attention not a general your application needs work message. This decision disproportionately protected the user the person with the least power in a government registration process submitting documents they cannot recover if something goes wrong. The admin audit trail was a secondary benefit. The primary one was giving users a system they could trust.
"Every admin decision requires a written reason. No invisible rejections."
"Every admin decision requires a written reason. No invisible rejections."
"Every admin decision requires a written reason. No invisible rejections."
Decision 03
Decision 03
Status tracking with a genuine resubmission path
Status tracking with a genuine resubmission path
Status tracking with a genuine resubmission path
Rejection used to mean starting over. I made every error fixable without restarting.
Rejection used to mean starting over. I made every error fixable without restarting.
I designed a seven-state application lifecycle: Submitted, Under Review, Additional Requirements Needed, Resubmitted, Approved, Registered, and Delivered. Each state had a defined meaning and a defined next action.
The critical decision: separating "Additional Requirements Needed" from "Rejected." One means fix and continue. The other means the application is closed. In the systems I reviewed, correction and rejection were often not separated clearly enough for the applicant. That was the failure I was fixing.
The resubmission flow let users fix only the flagged items without re-entering any previously accepted information. A user with three documents previously accepted and one rejected does not start over. They fix one thing. The rest of their work is preserved.
The resubmission window is not invisible. A time sensitive reminder surfaces on the user’s dashboard the moment an Additional Requirements notice is issued showing exactly what needs to be fixed with a direct Submit Now action and a deadline before the application auto rejects. The user sees the urgency. The path is one tap. Missing the deadline is a choice not a gap in the system.
I designed a seven-state application lifecycle: Submitted, Under Review, Additional Requirements Needed, Resubmitted, Approved, Registered, and Delivered. Each state had a defined meaning and a defined next action.
The critical decision: separating "Additional Requirements Needed" from "Rejected." One means fix and continue. The other means the application is closed. In the systems I reviewed, correction and rejection were often not separated clearly enough for the applicant. That was the failure I was fixing.
The resubmission flow let users fix only the flagged items without re-entering any previously accepted information. A user with three documents previously accepted and one rejected does not start over. They fix one thing. The rest of their work is preserved.
The resubmission window is not invisible. A time sensitive reminder surfaces on the user’s dashboard the moment an Additional Requirements notice is issued showing exactly what needs to be fixed with a direct Submit Now action and a deadline before the application auto rejects. The user sees the urgency. The path is one tap. Missing the deadline is a choice not a gap in the system.
I designed a seven-state application lifecycle: Submitted, Under Review, Additional Requirements Needed, Resubmitted, Approved, Registered, and Delivered. Each state had a defined meaning and a defined next action.
The critical decision: separating "Additional Requirements Needed" from "Rejected." One means fix and continue. The other means the application is closed. In the systems I reviewed, correction and rejection were often not separated clearly enough for the applicant. That was the failure I was fixing.
The resubmission flow let users fix only the flagged items without re-entering any previously accepted information. A user with three documents previously accepted and one rejected does not start over. They fix one thing. The rest of their work is preserved.
The resubmission window is not invisible. A time sensitive reminder surfaces on the user’s dashboard the moment an Additional Requirements notice is issued showing exactly what needs to be fixed with a direct Submit Now action and a deadline before the application auto rejects. The user sees the urgency. The path is one tap. Missing the deadline is a choice not a gap in the system.
"Status is not a label. It is an instruction."
"Status is not a label. It is an instruction."
"Status is not a label. It is an instruction."
Decision 04
Decision 04
Replace entity selection with a guided questionnaire
Replace entity selection with a guided questionnaire
Replace entity selection with a guided questionnaire
In a government registration system, choosing the wrong entity type costs the user a fee they cannot recover and a rejection they cannot appeal.
In a government registration system, choosing the wrong entity type costs the user a fee they cannot recover and a rejection they cannot appeal.
The questionnaire is not a UX convenience. It is error prevention at the point where errors are most expensive. I designed a short questionnaire that asks the user about their situation in plain language how many people are starting the business is it for profit will it have a board of directors.
Based on the answers, the system recommends the correct entity type with a brief explanation. The user sees the recommendation before committing to any flow.
The questionnaire is not a UX convenience. It is error prevention at the point where errors are most expensive. I designed a short questionnaire that asks the user about their situation in plain language how many people are starting the business is it for profit will it have a board of directors.
Based on the answers, the system recommends the correct entity type with a brief explanation. The user sees the recommendation before committing to any flow.
The questionnaire is not a UX convenience. It is error prevention at the point where errors are most expensive. I designed a short questionnaire that asks the user about their situation in plain language how many people are starting the business is it for profit will it have a board of directors.
Based on the answers, the system recommends the correct entity type with a brief explanation. The user sees the recommendation before committing to any flow.
Entity selection as a structured recommendation not a dropdown the user has to guess.
Entity selection as a structured recommendation not a dropdown the user has to guess.
Entity selection as a structured recommendation not a dropdown the user has to guess.
Decision 05
Decision 05
OCR-assisted document capture eliminates manual re-entry
OCR-assisted document capture eliminates manual re-entry
OCR-assisted document capture eliminates manual re-entry
Users were typing information their documents already contained. Every manual entry was a potential rejection.
Users were typing information their documents already contained. Every manual entry was a potential rejection.
I designed the document capture step to use OCR to read the uploaded NIC and automatically populate the corresponding form fields. The user reviews the pre-filled data and confirms or corrects it.
They do not type anything twice. This reduced unnecessary re-entry and gave users a chance to review extracted information before submission, instead of typing information already present on their documents.
I designed the document capture step to use OCR to read the uploaded NIC and automatically populate the corresponding form fields. The user reviews the pre-filled data and confirms or corrects it.
They do not type anything twice. This reduced unnecessary re-entry and gave users a chance to review extracted information before submission, instead of typing information already present on their documents.
I designed the document capture step to use OCR to read the uploaded NIC and automatically populate the corresponding form fields. The user reviews the pre-filled data and confirms or corrects it.
They do not type anything twice. This reduced unnecessary re-entry and gave users a chance to review extracted information before submission, instead of typing information already present on their documents.
If the document already contains the information, the user should verify it, not type it again.
If the document already contains the information, the user should verify it, not type it again.
If the document already contains the information, the user should verify it, not type it again.
Decision 06
Decision 06
Decision 06
Digital signature and verification consent before submission
Digital signature and verification consent before submission
Digital signature and verification consent before submission
There was no moment in the original flow where the user confirmed they had reviewed what they were submitting. The signature step is not a legal formality it is the moment the user takes ownership of their application.
There was no moment in the original flow where the user confirmed they had reviewed what they were submitting. The signature step is not a legal formality it is the moment the user takes ownership of their application.
Before final submission, users review a pre-generated summary of their application and sign it digitally. This creates a clear record that the user reviewed and confirmed their information before submission.
I used a signature approach tied to RequireSign a product the client already had in development avoiding additional build cost while delivering the trust signal the user needed.
Before final submission, users review a pre-generated summary of their application and sign it digitally. This creates a clear record that the user reviewed and confirmed their information before submission.
I used a signature approach tied to RequireSign a product the client already had in development avoiding additional build cost while delivering the trust signal the user needed.
Before final submission, users review a pre-generated summary of their application and sign it digitally. This creates a clear record that the user reviewed and confirmed their information before submission.
I used a signature approach tied to RequireSign a product the client already had in development avoiding additional build cost while delivering the trust signal the user needed.
"Review and sign before payment. The user controls the record before it becomes official."
"Review and sign before payment. The user controls the record before it becomes official."
"Review and sign before payment. The user controls the record before it becomes official."
The Design Principles I Applied
The Design Principles I Applied
Every principle backed by a specific decision
Every principle backed by a specific decision
Every principle backed by a specific decision
Scope protects the user
→ Applied in Decision 01
A product that cannot launch serves no one. Scoping was the first user-centred decision I made.
Errors are recoverable, not terminal
→ Applied in Decision 03
Additional Requirements is a different state from Rejected. Every fixable error has a specific fix path.
Guidance before complexity
→ Applied in Decision 04
Entity selection became a recommendation, not a choice the user had to make alone.
Transparency at every step
→ Applied in Decision 03 and Decision 02
Seven explicit status states. Admin decisions require written reasons. Nothing happens invisibly.
Scope protects the user
→ Applied in Decision 01
→ Applied in Decision 01
A product that cannot launch serves no one. Scoping was the first user-centred decision I made.
A product that cannot launch serves no one. Scoping was the first user-centred decision I made.
Errors are recoverable, not terminal
→ Applied in Decision 03
→ Applied in Decision 03
Additional Requirements is a different state from Rejected. Every fixable error has a specific fix path.
Additional Requirements is a different state from Rejected. Every fixable error has a specific fix path.
Guidance before complexity
→ Applied in Decision 04
→ Applied in Decision 04
Entity selection became a recommendation, not a choice the user had to make alone.
Entity selection became a recommendation, not a choice the user had to make alone.
Transparency at every step
→ Applied in Decision 03 and Decision 02
→ Applied in Decision 03 and Decision 02
Seven explicit status states. Admin decisions require written reasons. Nothing happens invisibly.
Seven explicit status states. Admin decisions require written reasons. Nothing happens invisibly.
Outcome
Outcome
What the product became
What the product became
What the product became
2
2
Complete systems designed and shipped: the applicant mobile application and the government admin panel. Both sides of the registration process, end to end.
Complete systems designed and shipped: the applicant mobile application and the government admin panel. Both sides of the registration process, end to end.
5
Business entity types with distinct flows and document requirements.
Business entity types with distinct flows and document requirements.
7
7
Explicit application states: Submitted, Under Review, Additional Requirements, Resubmitted, Approved, Registered, and Delivered.
Explicit application states: Submitted, Under Review, Additional Requirements, Resubmitted, Approved, Registered, and Delivered.
2
Complete systems designed and shipped: the applicant mobile application and the government admin panel. Both sides of the registration process, end to end.
5
Business entity types with distinct flows and document requirements.
7
Explicit application states: Submitted, Under Review, Additional Requirements, Resubmitted, Approved, Registered, and Delivered.
Rizyk did not stop at design handoff. I designed the applicant-facing mobile application and the government admin panel, stayed involved throughout development for developer questions, edge cases, and implementation decisions, and the product was developed and shipped to the client without requiring a structural redesign of the core flows.
Rizyk did not stop at design handoff. I designed the applicant-facing mobile application and the government admin panel, stayed involved throughout development for developer questions, edge cases, and implementation decisions, and the product was developed and shipped to the client without requiring a structural redesign of the core flows.
The product passed legal compliance review on its first submission, with no rejection or required revision to the core product flows.
The product passed legal compliance review on its first submission, with no rejection or required revision to the core product flows.
The regulatory desk research at the start shaped both the MVP and the experience itself: what could legally be included, how each entity flow needed to work, and how applicants should be warned and guided when a submission needed correction before rejection.
The regulatory desk research at the start shaped both the MVP and the experience itself: what could legally be included, how each entity flow needed to work, and how applicants should be warned and guided when a submission needed correction before rejection.
Rizyk did not stop at design handoff. I designed the applicant-facing mobile application and the government admin panel, stayed involved throughout development for developer questions, edge cases, and implementation decisions, and the product was developed and shipped to the client without requiring a structural redesign of the core flows.
The regulatory desk research at the start shaped both the MVP and the experience itself: what could legally be included, how each entity flow needed to work, and how applicants should be warned and guided when a submission needed correction before rejection.
The product passed legal compliance review on its first submission, with no rejection or required revision to the core product flows.
Rizyk reinforced that some of the most consequential product-design decisions happen before visual interface design begins. The scope negotiation, correction architecture, resubmission path, and RequireSign integration shaped what the product could become long before visual polish mattered.
Rizyk reinforced that some of the most consequential product-design decisions happen before visual interface design begins. The scope negotiation, correction architecture, resubmission path, and RequireSign integration shaped what the product could become long before visual polish mattered.
Rizyk reinforced that some of the most consequential product-design decisions happen before visual interface design begins. The scope negotiation, correction architecture, resubmission path, and RequireSign integration shaped what the product could become long before visual polish mattered.