SaaS product design · New features & redesigns
SaaS product design from a new account to useful work.
Your product may have the right capabilities, but users still need to understand what to do first, how their role changes the interface and what happens when something goes wrong. I work with founders and product teams on coherent workflows, from task definition through prototypes and implementation guidance.
I'm Mohammed Noushad, from Kerala and based in Dubai for 11 years. I work with UAE teams and collaborate remotely.
For a product decision, not just a screen request
- An early product needs a clear first-use journey and a defined release scope instead of an ever-growing feature list.
- A new feature touches dashboards, permissions and existing workflows, and needs to fit the product rather than sit beside it.
- An established platform needs a workflow redesign while preserving familiar operational rules.
First deliverable: a workflow and release brief
We define the target role, the task they need to complete, the starting and success states, and the constraints behind the release. The brief separates essential paths from later features and records assumptions that still need validation.
Design around the work your product must support
Information architecture and task flows
Map navigation, role-specific entry points and the steps between setup and a useful result. Make dependencies and permission boundaries visible before high-fidelity screens.
Wireframes and prototypes
Explore alternative flow structures and use interactive prototypes to review decisions with stakeholders. Agree user testing separately where participant evidence is needed.
Product UI and edge states
Design the agreed responsive screens and reusable patterns, including empty, loading, error and restricted-access states relevant to the workflow. Reuse your existing design system where it fits.
Handoff and acceptance guidance
Prepare organised Figma files, behaviour notes and an agreed state checklist. Engineering can raise feasibility questions before implementation; post-build design review can be scoped explicitly.
Where the scope stops
This offer focuses on product UX and UI. Brand identity, marketing websites, participant recruitment, production development and ongoing product ownership are separate requirements. Design work does not establish product-market fit or guarantee activation, retention or revenue.
A sequence of product decisions, with review points
- 01
Choose the slice
Review users, business goals, current product and technical constraints. Agree the feature or journey, collaborators and deliverables rather than treating the entire roadmap as one brief.
- 02
Resolve the workflow
Use low-fidelity flows and prototypes to review task logic. Track unanswered questions and revise the direction before polishing the interface.
- 03
Detail and hand over
Develop the agreed screens and states, review them with engineering and document expected behaviour. Agree what evidence the team will collect after release to evaluate the design.
Product work relevant to complex SaaS journeys
Valmont: enterprise workflows and role-based interfaces
Enterprise application work covering information architecture, data-heavy screens and a shared component library. Explore role-based navigation and complex operational workflows.
Read case study →FinFlow: a financial product under development
A mobile savings-app design with goal-based tracking and behavioural nudges. Currently under development, with a case study focused on the product and interface decisions.
Read case study →Voyacher: a connected travel platform
Discovery, voucher balance and checkout design for a Qatar-based travel service, connecting multi-step booking journeys across devices.
Read case study →Questions about SaaS product design
Can we start with one feature rather than a full redesign?
Yes. A contained workflow is often a clearer brief: define who uses it, the problem it addresses, the states it touches and its dependencies. We can decide whether it needs a local change or broader navigation work.
Do you work with an existing product team?
The engagement can be structured around your product and engineering review process. Share who makes decisions, the current design assets and expected collaboration so responsibilities are agreed before starting.
Do prototypes include user research?
A prototype is a design artifact, not proof of usability. We can define research questions and discuss testing as a separate scope, including participant access and who will conduct it. Stakeholder approval is not presented as user validation.
How do we agree the timeline and evaluate the work?
We scope the journey, access, review points and engineering dependencies before agreeing a schedule. Define the intended user task and a practical validation plan alongside the deliverables, so your team knows what to review before and after implementation.
What should your users be able to do next?
Describe the product stage, target users, feature or journey, existing design assets and engineering constraints. Mention your intended release window so we can discuss a realistic scope.
Scope, fees, availability and any next steps are agreed before an engagement begins.