Designing for non-tech users in an early-stage product

Designing for non-tech users in an early-stage product

1-minute summary

This project was done in partnership with a co-designer for one of AVATARé’s products. 

AVATARé helps organisations build workflows for embedded finances, business optimisation and venture hub.

A specific case handled here is about the web and mobile organisation management app we built for early-stage testing with schools as one category of orgs scoped for this stage.

  • Collaborated with a senior UX designer

  • Shaped Figma first design system 

  • Designed both mobile and web app flows

This project started out with constraints like a
non-tech-savvy audience and stakeholders. This shaped most design decisions.

1-minute summary

This project was done in partnership with a co-designer for one of AVATARé’s products. 

AVATARé helps organisations build workflows for embedded finances, business optimisation and venture hub.

A specific case handled here is about the web and mobile organisation management app we built for early-stage testing with schools as one category of orgs scoped for this stage.

  • Collaborated with a senior UX designer

  • Shaped Figma first design system 

  • Designed both mobile and web app flows

We were dealing with a system where organisations control what their members can do, acting as a central layer for permissions and access. The target audience in this testing phase being school authorities and members brought in challenges around slower flows and the need for guided interactions.

The goal of this phase was to validate how users interact with structured flows and organisation-controlled systems in a real-time setting.

This meant we had to make a few important decisions early on.

#1 Designing for non-tech-savvy users

The primary test audience being school systems, we prioritised familiar patterns over novel ones. The same app was to be used by students and teachers having different usage behaviours, which had to be accounted for.

We introduced slower and guided flows to reduce friction and improve clarity.

For example, in the digital wallet flow, when users proceeded to add and verify their cards, interactions were designed to guide them through the process:

  1. A quick guide option to help users understand how to tap and pay.

  2. Easy navigation for actions like setting up a default card.

Flows were designed to guide users without needing too much effort from their end.

With user behaviour in mind, the next challenge was to figure out the working of the system itself.

#2 Structuring around org-controlled data

The system was built around organisation-controlled access where access and actions depend on what the organisation enables.

  1. The organisation defines the system and permissions

  2. Users interact within that defined capacity

  3. Features are dependent on the organisation layer and remain scalable

This ensured that the app could adapt across different organisations while maintaining control at the top level.

Once the system was defined, the question was what to actually design for this phase.

#3 Scoping flows for testing

Flows were scoped to validate key interactions during early-stage testing.

We didn’t design everything. We focused on a few flows that would help us understand user behaviour and system interactions:

  1. Organisation members could onboard without friction and start interacting with the app

  2. Parent organisations controlled major functionalities while users interacted within those boundaries

  3. Features like digital wallet, loyalty, and calendar were selected to test how these systems fit into day-to-day usage

This allowed us to focus on validating critical parts of the experience instead of building out the entire system.

Among these, one flow stood out in terms of complexity.

#4 Breaking down the wallet flow

The wallet flow became the most important flow to test, as it involved multiple steps and more complex interactions. With Apple and Google wallets as base, we wanted to ease it out even further. 

The goal was to break down a complex process into smaller steps while maintaining clarity and control.

  1. Passive guidance was introduced at each step

  2. Personalised and secure information handling was prioritised

  3. The wallet flow was embedded within the app without requiring external connections

This helped test how users navigate multi-step processes within a controlled system.

Bringing these together, the product started taking shape.

Next Steps

The parallel phases involved looking at competitors while simultaneously testing with potential users. These insights are being considered for further iterations and future designs.

The Impact

Impact was measured through testing sprints and iterations,

  1. Broke down complex flows into smaller steps to improve usability

  2. Designed for clarity under chaotic constraints

  3. Used early-stage testing to validate interaction patterns

Create a free website with Framer, the website builder loved by startups, designers and agencies.