Application maintenance and release review Design concept
Sanad Technology
An Arabic workspace for a Kuwaiti technical team linking issues, changes, checks and approval before a release is published.
We designed Sanad Technology for a software studio in Shuwaikh maintaining commercial applications for local clients. The project lets account managers and developers see what changed, what was checked and what remains before release. One record connects the issue, files, checks and person responsible for the release decision.
Client in the design study
Sanad Technology Studio
Shuwaikh, Kuwait
Project brief
A design study for a fictional Kuwaiti software studio reviewing client-app maintenance and documenting release approval.
Design scope
- Arabic identity and issue workspace
- Change details and owned verification checks
- Release comparison and approval gate
01 / The project challenge
The project challenge
An apparently small problem, such as confirmation disappearing on a slow connection, is not resolved operationally merely by closing a ticket. The team needs change review, a normal-path check, slow-network testing and client approval. Scattered conversations and development logs blurred successful builds with completed business review and concealed the next action's owner.
02 / The solution we designed
The solution we designed
A release workspace connects three defined issues and compares the published version with the candidate. Five required checks cover linking, change review, the normal path, slow networking and client approval. Three are complete and two pending, matching the visible rows. Reviewers, times, build results and file links sit beside each state; publication remains unavailable until mandatory requirements are complete.
03 / The experience
The experience
Engineer Yusuf Al Kandari opens the checkout-confirmation issue and its Android reproduction steps. He reviews the state and retry files and records the normal-path result. Account manager Noura Al Mutairi then reviews the release comparison without reading every code-log line. She requests the remaining slow-network test and client decision, each with a named owner. Requesting review is never presented as an already approved or published release.
04 / What it could do
What it could do
Traceable issues
Connect the description, reproduction steps and changed files to the original ticket and its reason.
Owned checks
Show every result, reviewer and time, separating technical success from a person's pending decision.
Release comparison
List included issues and files alongside the published version and candidate build reference.
A clear release gate
Keep publication pending until requirements are complete and point to the remaining action.
05 / A typical journey
A typical journey
Identify the issue
Yusuf reads reproduction steps and their effect on checkout confirmation.
Review the change
He compares linked files and records the candidate build and normal-path result.
Complete the requirements
Noura checks three completed items and requests slow-network testing and client approval.
Decide on the release
The owner reviews the final comparison and audit history after requirements are complete.
06 / Inside the interface
Inside the interface
Arabic interfaces with right-to-left reading and sample workflows set in Kuwait. Open the images to explore the details.
Explore the screens.
Open any screen to explore the complete project gallery.
07 / Design direction
Design direction
A working dark-blue and light-grey interface replaces the terminal-illustration appearance. Sanad's Arabic mark suggests a supporting link; compact tables and tabs use concise Arabic states. Only necessary file and build identifiers remain in technical notation. Issue and release screenshots show consistent records and named reviewers without oversized slogans or unexplained performance figures.
Discuss a similar idea
