A customer on a phone requests a collection from a distributor. She enters the site address, selects a time window and taps submit. The connection drops before a confirmation appears. She taps again. The office receives two collection requests and sends two drivers. The portal looked attractive, accepted every required field and passed its desktop demonstration. It failed at the moment the customer needed to know whether her request existed.
For a buyer considering web application development in Kenya, that moment is a better starting point than a list of technologies. Decide what the user should be able to accomplish and what the business must do afterwards. Define the result when a connection slows, a person changes their mind or two staff work on the same request. Then ask developers to demonstrate those conditions on the devices and networks relevant to your customers.
This guide uses a fictional collection portal. It could belong to a distributor collecting empty containers, a maintenance firm collecting equipment or a supplier arranging returns. The workflow has a clear beginning and an observable end. That makes it a useful example for comparing proposals whether your actual application handles bookings, applications, orders or service requests.
Start with the decision the user came to make
The customer wants to arrange a collection and know what happens next. She did not come to create an elaborate profile, learn internal department names or determine which database will store the request. Describe the task in her words. What will be collected, from which site, when, and which reference should she keep? Decide what information the business truly needs before it can accept the request.
Write the outcome as a testable sentence. After submitting a valid request, the customer sees a stable reference and its current state. The collection team sees one actionable request with the same reference. If the office must confirm availability, the portal says the request is awaiting confirmation instead of promising a driver. This small distinction prevents the interface from making a commitment operations has not approved.
Identify people who use the portal differently. A regular account customer may have saved sites and authorised contacts. A first time customer may need to enter a location without creating a permanent profile. A branch officer may submit on behalf of an authorised customer under your policy. Map those differences before designing the form. A mandatory account can add needless friction for one audience and be essential for safeguarding records for another.
Decide who owns the work after submission. If nobody monitors the collection queue, the portal merely makes a neglected request easier to submit. Name the team, hours of operation, expected acknowledgement process and escalation route. A user experience includes the response from your business. A technically successful submission that waits unnoticed for three days still fails the person who needs a collection.
Give the request a lifecycle
Distinguish draft, submitted, under review, confirmed, collected and cancelled under terms your team understands. The exact names matter less than the fact they describe different commitments. A customer can submit a request before dispatch confirms a slot. A collection can be confirmed before a driver reaches the site. A driver can arrive without successfully collecting the item. One completed checkbox cannot express all of these events.
Draw the allowed transitions and who may perform each one. The customer can edit a draft. Dispatch can confirm an available slot. A driver can record arrival or a failed attempt. A supervisor may resolve a dispute under the agreed process. Define what happens when an edit arrives after confirmation or a cancellation arrives while the driver is already en route. These transitions produce most of the difficult commercial conversations.
Use a clear reference throughout. The customer should see it on the confirmation page and subsequent notifications. Dispatch should find the same reference in its queue. A payment, attachment or driver note should connect to it without replacing it. If an amendment creates a new version, show its relationship to the original request. Customers should not need to remember a new number merely because they corrected a gate contact.
Test an abandoned request. A customer begins the form and leaves before submission. Decide whether the application stores a recoverable draft, how long it should retain it under your policy and what the user can do next. Dispatch should not receive an actionable request simply because someone opened the form. A conversion report that counts drafts as submitted requests will give management an inflated view of demand.
Design the form around real information
Ask for the information customers can reasonably supply at the time of the request. A site name, contact route, collection description and preferred window may be enough to start. A precise internal product code may be useful to dispatch but unknown to the customer. Offer a search or an authorised follow up route instead of forcing customers to invent values just to get past validation.
Separate an address from directions. A customer may know the building and neighbourhood but need a short note about the loading entrance. A driver needs enough detail to reach the site without exposing unrelated personal information. Test with a large compound containing several gates and with two customers using similar site names. Give dispatch a way to clarify an uncertain location before confirming a slot.
Offer time windows the business can honour. If exact availability depends on staff review, present preferences as preferences. If the application reserves slots automatically, define how long a reservation lasts while the customer completes the form and what happens when two customers request the final slot. Rechecking availability when the user submits can prevent a stale page from promising a collection the team cannot perform.
Show errors where the customer can act on them. A message that says invalid request leaves the user guessing. Identify the field, explain the correction in ordinary language and preserve valid entries. Test a missing contact detail, an unavailable time window and an attachment that exceeds your approved limit. The user should not have to retype the entire form because one upload failed.
Make a slow submission safe to repeat
Return to the dropped connection. The server may have received and saved the request even though the customer never saw the response. The application must distinguish a repeated attempt from a genuinely new collection. Ask developers to explain their proposed method in business terms and then demonstrate it. One intended request should result in one collection reference and one dispatch task.
A temporary disabled button can reduce accidental double taps, but it does not solve retries after a page refresh or connection loss. Design an identifier or equivalent mechanism for a particular submission attempt and keep the server’s handling consistent when it sees that attempt again. The user should regain the reference or a clear route to recover it. The business should avoid issuing a second collection solely because the response was lost.
Now test a genuine second request from the same customer at the same site. A broad rule that suppresses everything similar may discard a valid request. Distinguish resubmission of the same attempt from a deliberate new request. Ask the development team to show both cases side by side in dispatch. This is a practical acceptance test even for a buyer who never sees the technical implementation.
Record enough diagnostic information to investigate uncertainty. A support officer should be able to find the reference, time and request state without asking the customer to send private screenshots to a general group. A failed submission message should provide an appropriate next step and avoid falsely stating that nothing happened when the outcome is uncertain. Clarity at this boundary can save an unnecessary driver journey.
Test phones before approving the desktop design
Choose representative devices and real tasks. Open the portal on a modest phone, increase text size, rotate the screen and use it on an interrupted connection. Ask a customer unfamiliar with the project to book a collection while standing at the sort of site where they would normally use the service. Observe the work without pointing to the next button or supplying information the form itself does not explain.
Read the page at a narrow width. The customer should see the action, its consequence and any unresolved error. A calendar control can be technically responsive while requiring precise taps or showing months outside the screen. Try entering an address using an onscreen keyboard. A fixed footer that looked attractive on a desktop may cover the field the customer is trying to correct.
Use the portal with a keyboard and with ordinary accessibility features relevant to the audience. Check whether fields have meaningful labels, whether focus moves sensibly after an error and whether status changes are expressed in words as well as colour. A green icon alone cannot tell every user that dispatch has confirmed the request. Include a user who approaches the interface differently from the designer.
Measure the complete task rather than the home page alone. A small landing page may load quickly while the booking form downloads a heavy calendar or every available site. Try a customer account with many previous collections and a first time customer with none. A useful proposal sets performance expectations for the actual paths, devices and workload the business needs, then shows evidence from representative tests.
Give dispatch a queue people can operate
The collection desk needs a queue showing new requests, confirmed visits, exceptions and items awaiting customer clarification. Give each item an owner or a clear process for claiming it. Two dispatchers opening the same request should see what the other has done before they both send confirmations. Test concurrent edits and inspect the message shown to the person working from an outdated version.
Give the dispatcher the context needed to decide. The preferred window, site instructions, item description and customer contact route may be enough. Private attachments or unrelated customer history may not belong on the main queue. Use role specific views and access checks. A driver needs the assigned collection details without the entire customer database. An account manager may need the outcome without permission to change a driver’s record.
Make age visible. A request submitted late on Friday and another submitted during staffed operating hours may need different handling under your agreed service arrangements. Define when the response window starts, how weekends or closures are treated and who escalates overdue work. The portal should give customers honest expectations and staff a useful list of commitments, rather than a generic promise of immediate response.
Test a handover between shifts. The outgoing dispatcher has contacted the customer but is waiting for a gate reference. The incoming dispatcher should see the outstanding question, last action and owner without reading a private message thread. A short structured note attached to the request is often more useful than a long conversation copied into the system. Agree what information belongs there and who may read it.
Make authentication match the information at risk
A public enquiry and a portal showing a customer’s full history need different access decisions. Map which actions can be public, which require verification and which require restricted staff authority. Ask what a person could learn or change if they obtained a link, reused a shared device or knew another customer’s reference. Design controls around those actual consequences.
Use two fictional customers. Sign in as the first, open a collection attachment and copy its address. Then sign in as the second and try the address. The server should enforce the current user’s authority for the record and file. Hiding the attachment link on the page is insufficient. Try the same exercise with a downloadable report and an edit request as well as the ordinary details screen.
Test account recovery and contact changes. A customer may lose access to a phone or email address. Define how the organisation verifies the new contact and what staff may do on the customer’s behalf. A recovery route that bypasses all normal checks can defeat the rest of the access design. Rehearse the process using fictitious accounts and preserve an appropriate record of sensitive administrative actions.
For a technical acceptance discussion, the OWASP Application Security Verification Standard gives developers and buyers a common reference for selecting and testing relevant controls. Ask the supplier to identify applicable requirements, the version used and evidence for the agreed scope. A generic claim that a portal is secure gives a buyer little to review. OWASP Application Security Verification Standard.
Treat uploads as a workflow of their own
The customer may attach a photograph or supporting document. Decide which formats, sizes and purposes the business accepts. Explain those limits before the user selects a file. A form that fails only after a large upload consumes time and data unnecessarily. Where an attachment is optional, let the user proceed without it and identify any later review needed before dispatch confirms the collection.
A file can upload successfully while the request itself fails, or the request can succeed while an attachment remains pending. Define how the application represents those situations. A customer should know whether dispatch received the essential request and whether the file requires another attempt. Staff should avoid making decisions from an incomplete attachment without a visible indication of its state.
Inspect who can download the file after submission. A driver may need a photograph of the gate, while finance does not. A supplier’s support technician may need an error reference without the file itself. Apply the appropriate protection to storage and downloads, specify retention under business policy and test a removed user’s access. An attachment should not become permanently public merely because its address is difficult to guess.
Use a fictional image with an unhelpful filename and another with characters likely to cause confusion. Ask a dispatcher to distinguish the files by their purpose and request reference. A sensible display name and upload time can improve review. Keep original evidence intact where your process requires it, and avoid letting a later upload silently overwrite a file somebody has already used to make a decision.
Send notifications that explain the actual event
A notification should tell the customer what happened and what action, if any, is available. Acknowledging submission is different from confirming a collection slot. A driver assignment is different from a completed collection. Draft example messages for each state and read them from the customer’s perspective. A message saying confirmed when dispatch has only received the request can trigger a dispute about a missed promise.
Test delayed and duplicate delivery. A confirmation message may arrive after the customer has already cancelled. A retry may send two copies. Keep the authoritative current state in the portal and give messages appropriate references and dates. Where possible, check the current state before sending an obsolete notification. The operations team needs a view of pending or failed messages rather than assuming every provider accepted and delivered them.
Minimise sensitive content in previews. A general notification can direct the customer to the authenticated portal for details. Decide which information is appropriate for each channel and audience. Shared phones and forwarded emails can widen access beyond the person intended. Test the message with the fictional customers and ask a colleague whether it exposes details unnecessary to its purpose.
Allow customer service to explain the communication history. A person calls after receiving two apparently conflicting notices. The support officer needs to see what triggered each notice, when it was queued and the delivery status available from the provider. A record saying email sent may only establish that the portal handed the message to another service. Use terms that match the evidence actually available.
Plan the connection to the back office
Decide where the accepted collection becomes operational work. Some businesses will use the portal’s own dispatch queue. Others will send requests to an existing job system or enterprise platform. Identify the system of record, the fields exchanged and the expected acknowledgement. An attractive customer confirmation should not hide a failed integration that leaves dispatch unaware of the request.
Test a rejected site code and a temporary connection failure separately. The rejected code needs business correction. The temporary failure may be safe to retry under an agreed method. Give each exception a responsible owner and a reference to the customer request. A developer’s error log can help investigation but cannot substitute for an operational queue showing which customer commitment remains unresolved.
Change a request after the back office accepts it. The customer updates the gate contact or asks for a later window. Define which changes can flow automatically, which require dispatch approval and which are no longer possible after the driver leaves. Preserve the original instruction and current version. The customer and driver should see consistent information or a clearly explained pending decision.
Reconcile the two systems regularly. Count submitted requests, accepted jobs, open exceptions and completed collections for an agreed period. Inspect individual references where totals differ. Balanced counts alone can hide one missing request and one duplicate. Keep the fictional retry scenario in the test pack so future changes to either system do not reintroduce duplicate dispatches.
Set a delivery price around outcomes
Ask for a proposal covering discovery, design, development, integration, testing, deployment, training and ongoing operation. The word portal can describe anything from a simple form to a system containing authentication, documents, scheduling and enterprise interfaces. Give suppliers the same collection scenario and a clear list of expected results. Compare what each offer includes, assumes and leaves to your own staff.
Separate the initial release from later improvements. A first release might accept requests, provide references, support dispatch review and handle cancellation safely. Advanced route planning or rich customer analytics may wait until the business has enough real usage to justify them. Select the first release around a complete usable journey. A large collection of unfinished features delivers less operational value than one request that reaches a dependable outcome.
Clarify the assets and access needed to run the application. Who controls the domain, hosting account, application configuration, source repository, database backups and communication providers? Who can release an urgent correction and who approves it? Which materials can the organisation retrieve at exit under the agreed contract? Test a restore or handover procedure before the usual developer becomes unavailable.
Agree acceptance evidence. Use the fictional customer, two dispatchers, a slow connection, one repeated submission and one legitimate second request. Confirm that the customer sees honest status, staff receive the right work, access boundaries hold and the system can recover from interruption. Price fixes for agreed defects differently from newly requested features. Preserve the examples and decisions so future changes have a known starting point.
Distinguish measurement from surveillance
The business needs to know how often customers begin a collection request, where they give up and which completed requests require manual clarification. Those measurements can guide improvements without recording everything a customer types. Define a small set of events tied to decisions. Opening the form, receiving a validation error, submitting successfully and recovering a reference after interruption tell the product team more about usability than a general count of page views.
Keep sensitive material out of ordinary analytics. A site address, contact number, attachment name or free text description may reveal details unrelated to product measurement. Ask the developer which events and fields are sent to analytics providers, who can access them and how long the organisation retains them under its policy. Use fictional input in the trial and inspect the captured event. A useful metric should explain behaviour without becoming another unmanaged copy of a customer record.
Separate genuine abandonment from technical failure. A person may leave because they are comparing options, because the available time windows do not fit, or because a required field will not accept their information. A falling completion rate alone cannot distinguish these causes. Review error categories and speak to a sample of users through an appropriate process. Change one meaningful part of the form and observe whether the targeted problem improves rather than adding features in response to every drop off.
Measure the office side too. If customers complete the form quickly but dispatch spends ten minutes clarifying every gate address, the application has moved effort between teams. Count requests needing clarification, time to acknowledgement and failed collections attributable to missing information. Avoid demanding more fields from every customer when one clearer prompt would resolve the problem. A short change tested with actual users can improve both completion and operational accuracy.
Rehearse a release while a request is in progress
Imagine a customer opening the collection form before a software update and submitting it afterwards. The field names or validation rules may have changed between those moments. The application needs a predictable way to handle an old page. A message asking the customer to reload can be reasonable if the application preserves their work and explains what happened. Silently accepting incomplete information or losing the entire request creates unnecessary frustration.
Include a dispatcher editing a request while the release occurs. If a database change affects collection states, the team should know how existing requests are treated, which updates remain compatible and what happens if the release is reversed. Ask the supplier to walk through an example using a pending request and a confirmed one. Rollback decisions must account for business actions that occurred after deployment, not just the application files that can be restored.
Decide when to deploy and who watches the first transactions. A release during a quiet window may reduce exposure but can also leave fewer staff available to detect a problem. Select a time when a responsible person can verify a submission, confirmation and dispatch update. Use a controlled test request marked clearly enough that no driver receives a real instruction. Compare the observed result with the preagreed acceptance example.
Keep a customer support route available if the portal temporarily fails. The team needs a way to receive a legitimate request, assign a temporary reference and reconcile it when the portal returns. Document how staff avoid entering a second collection if the customer’s original submission subsequently appears. During the rehearsal, make one request through the temporary route and prove that the eventual record remains singular and understandable.
Give the application a working owner
Appoint someone responsible for the whole collection journey after launch. Dispatch will own operational decisions, IT will own technical responsibilities and customer service will handle enquiries, but one person should monitor how the pieces fit together. Give that owner the authority to convene the right people when repeated errors arise. Otherwise each team may improve its own screen while the customer continues to encounter the same gap between screens.
Set a regular review using actual cases. Pick a request that reached collection smoothly, one that stalled and one that a customer corrected. Compare their histories, identify the decision that changed the outcome and assign a specific improvement. Review access rights, pending exceptions and stale drafts alongside product ideas. Maintenance of the underlying workflow deserves a place beside visible design improvements on the project schedule.
Keep the original fictional collection available as a repeatable exercise. Run it when a developer changes authentication, a provider changes notification behaviour or the business adds a new dispatch branch. The same simple request can reveal a surprising range of regressions because it crosses the customer form, office queue, messages and completion history. Revisiting it costs less than discovering a broken handoff through an unhappy customer.
Finish where the customer finishes
Run the original phone test again. Tap submit, interrupt the connection and recover the request. The customer should find one reference and a clear current state. Dispatch should receive one actionable job. After the driver records the outcome, the customer should be able to see what happened and raise a specific question if necessary. Ask someone who did not design the portal to complete this entire journey unaided.
Keep the retry test in the release checklist even after the application has been operating for months. A modest change to a confirmation screen can alter how users respond to a delay. Ask support to review uncertain submissions after each significant release and report whether staff could recover the original reference. That evidence tells the owner whether normal customers still get the result the team promised.
A finished web application includes the office queue, the failed attempt and the final confirmation as well as the first screen. Put that complete journey in your brief and give each shortlisted supplier the same chance to prove it. For more practical Kenyan software buying guides, visit the ZamaCore blog.