GullySystem
UI/UX Design and Prototyping

Design and Prototype Your Software Before You Spend on Building It

GullySystem turns business requirements into user journeys, wireframes and clickable prototypes — so you, your staff and your customers can use the screens and approve them before development begins.

  • A clickable prototype you can test before you commit a build budget
  • Design files any development team can build from, including your own
  • Works for a new idea or software already running in your business
gullysystem.live/prototype Live
Screens Prototyped
Clickable
Before any code
Change Requests
Caught in review
Fixed in the design
Design System
Components & states
Reused across screens
Review Session NotesLive stream
Billing screenApproved
Stock entry: too many tapsReduced to two
Error message unclearRewritten in plain English

Interface and prototype work for distributors, clinics, manufacturers, professional firms, schools and software product teams across India — covering new products, internal admin panels, customer and dealer portals, and redesigns of software already in daily use.

The operational challenge

Does Your Software Make Sense to Everyone Except the People Using It?

!

Staff Ask for Help With the Same Screen Every Week

Your accounts clerk still calls the supervisor to find where a credit note is raised. A new joinee takes weeks to become useful. The software works — nobody can find their way through it.

!

Requirements Exist Only as Words

Scope is agreed across meetings, email threads and WhatsApp voice notes. Everyone nods, and every person is picturing a different screen. The disagreement surfaces only when the build is half paid for.

!

Every Developer Interprets the Screen Differently

Two developers work from the same written brief and deliver two screens that look nothing alike. You pay a second time to make them match, and a third time to fix what broke.

!

The Phone Version and the Desktop Version Are Two Different Products

Field staff learn one layout, the back office learns another, and the two do not even ask for the same fields. Entries have to be corrected at the office before anyone can trust the report.

!

Customers Judge Your Software Against the Apps on Their Phone

Your portal was acceptable when it launched. Now a dealer abandons the order form halfway and phones the order in instead — and your team keys it in by hand, with the mistakes that follow.

!

You Are Asked to Approve Something You Cannot See

Sign-off happens on a scope document full of module names. The first time you actually see the software is at user testing, when changing a flow means changing code that is already written.

!

The Interface Has Grown Screen by Screen

Each module was added by whoever was free that month. Buttons sit in different corners, dates appear in three formats, and the same word means two different things on two screens.

All of this is cheaper to fix on a screen than in code. GullySystem puts something you can click in front of you early, while changes still cost a conversation instead of a change request.

GullySystem Solution

See the Software, Use It, Then Decide to Build It

We begin with the people who will actually use the software — what they are trying to finish, how often they do it, and where they get stuck today. From that we draw the journey, then the screen structure, then a prototype you can open on your own phone and click through. Nothing goes to development until you and your staff have used it and asked for changes.

Journeys Before Screens

We map who does what, in what order, and what must be true before the next step. The screen list comes out of the real journey instead of a wish list written in a meeting.

A Prototype You Can Actually Click

Not a picture in a PDF. A working prototype you open on a laptop or phone, tap through, and hand to the person who will use it every day — before the first line of code is written.

Files a Developer Can Build From

Spacing, type sizes, button states, error and empty screens, and reusable components, all documented — so your team or ours builds exactly what you approved.

Operational ROI

What Design and Prototyping Gives You

Focus on business value before discussing technology. Here is what your team accomplishes in week one.

Before Code

Flows Validated Before Development Starts

Arguments about how a process should work happen on a wireframe, where the fix is a redrawn screen instead of rewritten code.

Clickable

Decisions Made on a Real Screen

You approve something you have used yourself, and so do the staff who will live with it. Sign-off stops being an act of faith.

Less Rework

Fewer Requirement Misunderstandings

Developers build from annotated screens instead of interpreting a paragraph, so fewer screens come back for a second and third round.

One Kit

A Consistent Interface Across Every Screen

One component library sets buttons, forms, tables and messages once, so the tenth module looks and behaves like the first.

Sooner

Faster Adoption by Staff and Customers

When the common action is where people expect it, training is shorter, support calls drop and staff stop keeping a parallel Excel sheet.

Handover

Developer-Ready Output, Whoever Builds It

Specifications, assets and components are packaged so your in-house team, your existing vendor or ours can pick up the build.

Scope of service

What UI/UX Design and Prototyping Covers

Everything required from operational discovery to production deployment and long-term maintenance.

01

Product Discovery and Requirement Mapping

We sit with owners, managers and the people at the counter to understand the work, the exceptions and the rules nobody wrote down.

02

User Journeys and Information Architecture

Step-by-step flows for each role, plus a menu and screen structure that puts daily actions within reach instead of three levels deep.

03

UX Wireframing

Grey-box layouts that settle what goes on each screen and in what priority, before anyone argues about colour.

04

Clickable Prototypes

Linked screens you can navigate on a phone or laptop, share with staff and customers, and take into a funding or approval discussion.

05

Web Application and SaaS Product Design

Interface design for customer portals, dealer portals, booking systems and subscription products, including onboarding and settings screens.

06

Mobile Application Design

Android and iOS layouts designed for the conditions your users are in — one hand, bright sunlight, patchy network, an entry-level phone.

07

Admin Panel and Dashboard Design

Data-dense screens done properly: filters, bulk actions, long tables, printable reports and the numbers a manager checks first thing.

08

Design Systems and Component Libraries

A reusable kit of colours, type, buttons, forms, tables and states so future modules stay consistent without a designer on every screen.

09

Redesign of Software Already in Use

We keep what your staff already know, fix the screens generating the most calls and mistakes, and release the change in stages.

010

Responsive and Multi-Device Layouts

One interface designed for desktop, tablet and phone, so the same task behaves the same way wherever it is done.

011

Usability Testing and Accessibility

Watch real users attempt real tasks, plus readable type sizes, adequate contrast, keyboard access and regional-language layouts where you need them.

012

Developer Handover and Build Support

Annotated specifications, exported assets, a walkthrough session for the development team, and design review of the screens they build.

Practical applications

Where This Work Pays for Itself

Real-world business processes we configure and automate.

A founder who needs something to show

A logistics idea exists as a slide deck, and every investor and pilot customer asks what it will actually look like. We map the shipper and driver journeys and build a clickable prototype. The idea can be demonstrated instead of described, and any development quote is then priced against a defined screen list rather than a guess.

A distributor whose order screen fights the staff

An FMCG distributor’s order-punching screen was built around the database rather than the counter, so staff keep a side Excel for partial dispatches. We rebuild the flow around how an order is really taken, with quick item search and a clear partial-dispatch state, so the parallel sheet is no longer needed and dispatch data stays in one place.

A clinic front desk run by non-technical staff

Receptionists juggle walk-ins, doctor changes and phone calls on a screen designed for a trained computer operator. We redesign around the three things they do all day — book, reschedule, collect — with larger touch targets and fewer confirmation steps, so a new receptionist can work the desk without days of shadowing.

A manufacturer validating a field service app

Service technicians work at customer sites with patchy network and often with gloves on. Before the app is commissioned, we prototype it and put it on the technicians’ own phones for real jobs. Screens that fail in the field get corrected and features nobody reaches for get dropped, while both are still cheap to change.

A SaaS product that looks like four products

A growing platform has modules built by different developers over several years, each with its own tables, buttons and date formats. We build a design system and component library and redesign the shared patterns, so the engineering team has one reference and new modules stop drifting apart.

A school portal used by parents, not staff

Fee payment and attendance are available online, yet the office still handles most parent queries by phone. We redesign the parent journey for entry-level phones, with plain wording in two languages and one obvious path to pay, so parents finish the task themselves instead of calling the office.

Audience fit

Is This Service Right for Your Business?

We partner with established businesses that have outgrown manual processes and want reliable systems.

Founders and Product Owners With an Idea

You need to show investors, partners or an internal committee something real, and you want a defined scope before you fund development.

Businesses Whose Staff Work Around the Software

Your team keeps a parallel spreadsheet, a register or a WhatsApp group because the official system is slower than doing it by hand.

Companies About to Commit a Development Budget

You are close to signing for a build and want the screens agreed and tested first, so the quote is based on something specific.

Owners of Software That Grew Module by Module

Your platform works, but every screen was added by a different person at a different time and it now looks and behaves inconsistently.

Businesses Whose Customers Use the Software Directly

Dealers, patients, students or buyers use your portal without training, and every point of confusion becomes a phone call to your team.

When You Do Not Need This Service

If you need two or three internal screens used by a handful of staff, or your off-the-shelf software just needs your logo and colours, a full design engagement is not worth your money. Tell us, and we will say so and suggest the smaller piece of work instead.

Feature matrix

Enterprise Capabilities in Plain Business Terms

User Flow Mapping

Role-by-role journeys showing every step, decision and exception before screens are drawn.

Wireframes

Fast, low-fidelity layouts to settle structure and priority without debating visuals.

Interactive Prototypes

Linked, navigable screens shared as a private link that opens on any phone or laptop.

Responsive Layouts

Desktop, tablet and mobile versions of each key screen, designed rather than squeezed.

Component Library

Buttons, forms, tables, cards, filters and modals defined once and reused everywhere.

Design Tokens

Colour, spacing and type scales documented so developers apply them consistently in code.

Screen States

Loading, empty, error, no-permission and success states designed, not left to the developer.

Data-Heavy Table Design

Long lists, filters, sorting, bulk actions and pagination that stay readable on a laptop screen.

Form and Validation Design

Field order, input types, defaults and error wording that reduce mistakes at the point of entry.

Role-Based Screen Design

Different views for owner, manager, operator and customer, each showing only what that role needs.

Readability and Accessibility

Contrast, type size, tap targets and keyboard navigation checked against recognised guidelines.

Regional Language Layouts

Layouts that hold up when labels are set in Hindi or a regional script alongside English.

Usability Test Sessions

Structured sessions with your actual users, with findings written up in plain language.

Developer Specifications

Annotated screens with measurements, behaviour notes and asset exports ready for the build.

Execution roadmap

Our Structured 6-Step Delivery Process

A transparent path from your first conversation to a reliable production release.

01

Discovery

We meet the owner or product lead and the people who use the software daily, watch the current process, and collect sample documents and existing screens. From you we need a decision-maker and access to two or three real users.

02

Requirement and Flow Planning

We define user roles, map each journey and list the screens each role needs. You approve the flow map and screen list, and that approved list becomes the fixed scope of the design work.

03

Wireframing

We lay out each screen in grey-box form to settle what appears where and in what priority. You review structure only — no colours, no distractions — and confirm before visual design begins.

04

Interface Design and Prototype

We design the full-fidelity screens for each device size and link them into a clickable prototype. You get a private link, click through it yourself, and mark up anything that does not match how you work.

05

Usability Review and Revision

Where testing is in scope, we put the prototype in front of your actual users, note where they hesitate or take the wrong path, and revise. You give final acceptance on the revised prototype.

06

Handover and Build Support

We package the design files, component library, specifications and exported assets, run a walkthrough with whoever is building it, stay available for questions during development, and review the built screens against the approved design.

Asset handover

What You Receive Upon Project Completion

Everything required to run, maintain, and expand your software without vendor lock-in.

User-flow map for every role
Screen inventory and menu structure
Low-fidelity wireframes for each screen
High-fidelity interface designs
Clickable prototype on a shareable private link
Responsive layouts for desktop, tablet and mobile
Component library and design tokens
Annotated design specifications for developers
Exported icons, images and brand assets
Usability findings and recommended changes
Editable source design files with full access
Connected ecosystem

Connects With the Systems You Already Rely On

We build bridges between your software so you don't have to replace functional existing tools.

Design and Prototyping Tools

  • Figma
  • FigJam
  • Adobe XD
  • Penpot

Handover and Documentation

  • Figma Dev Mode
  • Storybook
  • Design tokens
  • Annotated specification sheets

Front-End Stacks We Design For

  • React and Next.js
  • React Native
  • Flutter
  • Tailwind CSS
  • Bootstrap

Existing Products We Redesign

  • In-house admin panels
  • Laravel and .NET applications
  • WordPress sites
  • Shopify storefronts
Engineering foundation

Selected for Reliability, Speed, and Longevity

Technology chosen to match your operational scale and long-term maintainability.

Design and Prototyping

FigmaFigJamAdobe XDPenpot

Design Systems

Design tokensStorybookTailwind CSSMaterial and Human Interface guidelines

Build Handover

Figma Dev ModeHTML and CSSReact and Next.jsReact NativeFlutter

Assets and Media

SVG icon setsLottie animationsOptimised image assetsBrand typography
The GullySystem difference

Why Business Owners Choose GullySystem

We Build Software Too

Screens are drawn by people who know what they cost to build. You do not get a beautiful design that turns out to be unaffordable or technically impractical at development stage.

Designed for the Person Doing the Job

A warehouse supervisor on a dusty phone, a receptionist answering a call mid-entry, a dealer placing an order at eleven at night. We design for those conditions, not for a portfolio shot.

Decisions Happen on Screens, Not Documents

Every review is held on something you can click. You are never asked to approve a module list and hope it means what you think it means.

Your Existing Software Is Not Thrown Away

For a redesign we start with the screens causing the most trouble and release in stages, so your staff are never asked to relearn everything in one weekend.

Plain-Language Reviews

We walk you through the work in business terms — what the user is trying to do and why the screen is arranged this way — without design jargon you have to decode.

You Keep Everything

Editable source files, the component library and all assets are handed over with full ownership, so any team can continue the work without coming back to us.

Commercial models

Flexible Engagement Options

Choose an engagement model that matches your operational scope, budget, and timeline.

Design-Only Engagement

Design First, Decide Later

You get journeys, screens and a prototype you can take to any development team — ours, your in-house team, or your existing vendor. A practical way to test an idea before funding a build.

Validation Prototype

One Idea, Clicked Through

For founders and product owners who need something real to show investors, pilot customers or an internal approval committee before committing budget.

Redesign of Existing Software

Screen by Screen

For software already in daily use. The highest-friction screens are redesigned and released first, so improvements arrive without disrupting operations.

Design With Development

One Team Through to Launch

Design and engineering run together under one accountability, so what you approved in the prototype is what gets built and shipped.

Common questions

Frequently Asked Questions

Straightforward answers to the questions owners ask before getting started.

Can we begin with design only, without committing to development?

Yes, and it is a sensible way to start. A design-only engagement ends with approved flows, screens and a clickable prototype that you own outright. You can take that to your in-house developers, to your existing vendor, or to us — and if the prototype convinces you the idea is not worth building, you have found that out at design cost rather than build cost.

How many screens are included?

The screen count comes out of discovery rather than being fixed in advance. We map the journeys for each role first, then list the screens those journeys actually need, and that list becomes the written scope before design begins. Screens added later are quoted separately so you always know what you are approving.

Will the prototype really be clickable?

Yes. You receive a private link that opens on a phone, tablet or laptop, and you can move through the screens the way a real user would. It is a prototype, not a working application — there is no live data and no real calculation behind it — but every important path is clickable, which is enough to test whether people understand it.

Can you redesign our existing product instead of starting over?

Yes, and for software already in daily use we usually recommend it. We review your current screens, sit with the people using them and identify where the mistakes and support calls come from. Then we redesign in stages, keeping the patterns your staff already know and changing the ones that are costing you time.

Do developers receive proper specifications, and can our own team build from them?

Yes to both. Handover includes annotated screens with spacing and type measurements, component states — default, hover, disabled, loading, error, empty — validation messages, responsive behaviour and exported assets. We run a walkthrough session with whoever is building it, stay available for questions during the build, and can review the finished screens against the approved design.

Will the design fit the technology we already use?

Yes. We ask about your existing stack during discovery and design within what it can do. If your team builds in React, React Native, Flutter, Laravel or an in-house framework, the components and layouts are specified in a way that translates into it. If your product must sit alongside existing screens, we match the patterns already there rather than forcing a break.

Is user testing included?

It is included when you choose to include it in scope, and we recommend it for anything customer-facing or used by a large number of staff. We give real users real tasks on the prototype and record where they hesitate or take a wrong turn. What we need from you is access to a few genuine users — testing with your management team instead tells you much less.

What drives the cost of a design engagement?

Cost is driven by the number of distinct user roles and screens, whether it is a new product or a redesign of something existing, how many device sizes are in scope, whether you need a full design system and component library, and whether usability testing and regional-language layouts are included. We give an itemised proposal after discovery, fixed against the agreed scope.

What decides how long the design work takes?

The biggest factor is usually how quickly decisions are made on your side — how fast reviews come back and whether one person can approve. After that: the number of roles and screens, how settled your requirements are, whether real users are available for testing, and how many revision rounds you want. We agree a review schedule at the start so the plan reflects your availability, not an assumption.

What do you need from us?

One person who can make decisions and give feedback, access to two or three people who do the work every day, sample documents such as invoices, forms or reports with sensitive details removed, a demo login or screenshots of your existing software, and your logo and brand assets if you have them. If you have no brand guidelines, we work with what exists and keep it simple.

Do we own the design files?

Yes. Editable source files, the prototype, the component library and every exported asset are handed to you with full ownership and no ongoing licence. You are not tied to us to make changes later, and another agency can continue the work from the same files.

How do you handle our confidential business information?

We sign a non-disclosure agreement before discovery begins. We ask for sample data with customer names, prices and personal details removed, work on read-only or demo accounts where possible, and share prototypes on private links rather than public URLs. Your screens, pricing logic and customer information are not shown to anyone else or used as public samples without your written permission.

Let’s Connect

Let’s Build the Right Software for Your Business

Tell us about your current operational challenge, spreadsheet bottleneck, or software requirement. An experienced engineer will review your workflow and reply within one business day.

  • No obligation consultation
  • Senior engineer reviews your brief
  • Your operational details stay 100% confidential

Discuss Your Requirement

Fill out this brief form and we’ll get back to you within one working day.

Your details are private and secure. Protected by reCAPTCHA.