Maqamy
Role
Founding Designer
Timeline
2025 · Abu Dhabi, UAE
FINTECH
0→1 PRODUCT
Mobile
pool money,
without losing trust.
pool money,
without losing trust.
Managing shared investments with family or friends often relies on spreadsheets, WhatsApp chats, and one person keeping track of everything. As groups grow, it becomes harder for everyone to stay informed and trust the process.
Managing shared investments with family or friends often relies on spreadsheets, WhatsApp chats, and one person keeping track of everything. As groups grow, it becomes harder for everyone to stay informed and trust the process.
Maqamy is a non-custodial platform that helps trusted groups record contributions, investments, and settlements without holding funds. I led the design of the mobile product, shaping its information architecture, interaction design, visual identity, design system, and interactive prototypes.
Maqamy is a non-custodial platform that helps trusted groups record contributions, investments, and settlements without holding funds. I led the design of the mobile product, shaping its information architecture, interaction design, visual identity, design system, and interactive prototypes.
The team
Building the product with a small founding team.
Building the product with a small founding team.
Maqamy was built by a team of three. Adil founded the company and brought the original idea to the project. He reached out with a vision for helping families and trusted groups manage investments more transparently. His background in property investment, Islamic banking, and treasury operations shaped many of the product decisions from a business perspective.
Sidharth led engineering. Before joining Maqamy, he had worked on payment and remittance infrastructure at BOTIM Wallet. He built the web-based MVP for Maqamy, which already supported separate coordinator and member accounts along with the basic investment workflow.
I joined as the founding designer leading the product design process, including research, information architecture, interaction design, visual design, prototyping, and the design system.
The FINAL design
From spreadsheets and WhatsApp to a shared platform.
From spreadsheets and WhatsApp to a shared platform.
01 · THE STORY
The pilot that changed the direction of the product.
The pilot that changed the direction of the product.
When I joined Maqamy, a bootstrapped MVP version of the product already existed as a web application built by Sidharth. The MVP wasn't feature complete, but it did what it was supposed to do. Coordinators could create and manage investment groups, members could log in and view information, and contributions could be recorded inside the system. Before investing time in a complete redesign, we wanted to understand how people would actually use it when real money was involved.
When I joined Maqamy, a bootstrapped MVP version of the product already existed as a web application built by Sidharth. The MVP wasn't feature complete, but it did what it was supposed to do. Coordinators could create and manage investment groups, members could log in and view information, and contributions could be recorded inside the system. Before investing time in a complete redesign, we wanted to understand how people would actually use it when real money was involved.
Instead of running a usability test, we decided to run a real investment. Six friends agreed to contribute money into a shared investment. Adil coordinated the group, collected contributions, and invested the funds externally in gold and Shariah-compliant stocks. At the same time, every contribution, investment, and update was recorded in the web application. Participants were encouraged to use the platform to follow the progress instead of relying on WhatsApp.
Instead of running a usability test, we decided to run a real investment. Six friends agreed to contribute money into a shared investment. Adil coordinated the group, collected contributions, and invested the funds externally in gold and Shariah-compliant stocks. At the same time, every contribution, investment, and update was recorded in the web application. Participants were encouraged to use the platform to follow the progress instead of relying on WhatsApp.
The investment itself went smoothly. Using the product did not. Everyone contributed, but almost nobody returned to the application afterward. Whenever someone wanted to know who had paid, whether the investment had been made, or what had changed since the previous update, they messaged Adil directly instead of opening the app.
The investment itself went smoothly. Using the product did not. Everyone contributed, but almost nobody returned to the application afterward. Whenever someone wanted to know who had paid, whether the investment had been made, or what had changed since the previous update, they messaged Adil directly instead of opening the app.
My first assumption was that the problem was usability. The web experience was designed primarily for desktop, while everyone naturally reached for their phones. A mobile-first experience seemed like the obvious answer.
My first assumption was that the problem was usability. The web experience was designed primarily for desktop, while everyone naturally reached for their phones. A mobile-first experience seemed like the obvious answer.
After watching how people behaved over the following weeks, I realized the issue wasn't only the platform. The information people were asking for already existed inside the application. They simply didn't expect to find it there. It was easier to ask the coordinator than to develop the habit of checking another tool. In practice, Adil had become the interface.
After watching how people behaved over the following weeks, I realized the issue wasn't only the platform. The information people were asking for already existed inside the application. They simply didn't expect to find it there. It was easier to ask the coordinator than to develop the habit of checking another tool. In practice, Adil had become the interface.
That observation changed how I thought about the product. Instead of treating the redesign as a visual exercise, we treated it as an opportunity to rethink how trust could be communicated through the interface itself. The goal was no longer to make the product look better. It was to make it easier for members to understand what was happening without having to ask someone else.
That observation changed how I thought about the product. Instead of treating the redesign as a visual exercise, we treated it as an opportunity to rethink how trust could be communicated through the interface itself. The goal was no longer to make the product look better. It was to make it easier for members to understand what was happening without having to ask someone else.
At that point, we decided to move away from the web MVP and redesign Maqamy as a mobile product. Before starting the design work, I worked with Adil to turn his strategic vision into a structured product requirements document (PRD). That document defined the scope of the MVP, clarified the licensing constraints we had to design around, and became the foundation for every design decision that followed.
At that point, we decided to move away from the web MVP and redesign Maqamy as a mobile product. Before starting the design work, I worked with Adil to turn his strategic vision into a structured product requirements document (PRD). That document defined the scope of the MVP, clarified the licensing constraints we had to design around, and became the foundation for every design decision that followed.
02 · the problem
what the pilot actually exposed.
what the pilot actually exposed.
The difficult part was helping everyone stay informed once the money had been pooled. Most participants didn't ask about returns first. They wanted to know whether everyone had contributed, whether the investment had gone through, and whether anything had changed since the last update. Those questions exposed three recurring problems.
The difficult part was helping everyone stay informed once the money had been pooled. Most participants didn't ask about returns first. They wanted to know whether everyone had contributed, whether the investment had gone through, and whether anything had changed since the last update. Those questions exposed three recurring problems.
01
There was no reliable record everyone could point to.
Most groups managed contributions in spreadsheets maintained by one person. That worked while everything went smoothly, but once numbers changed or disagreements appeared, there was no permanent record that everyone trusted. A spreadsheet could always be edited after the fact, and conversations explaining those changes were usually scattered across WhatsApp messages.
03
The coordinator carried all of the operational work.
Running an informal investment group involved more administration than we initially expected. Someone had to track contributions, remind members who hadn't paid yet, record investments, answer questions, and eventually calculate settlements. None of those tasks were particularly difficult on their own, but together they created a significant amount of manual work. The larger the group became, the more that workload concentrated around one individual. If that person became unavailable, lost records, or simply made a mistake, the rest of the group had very little visibility into what had happened.
02
Information depended on the coordinator.
Every update flowed through one person. Members didn't have a habit of checking a system because there wasn't a system they trusted yet. If someone wanted to know whether a contribution had been received or whether an investment had been made, they sent a message to the coordinator. That made the coordinator responsible for much more than managing investments. They also became the source of truth for the group, which meant every question, clarification, and reminder eventually came back to the same person.
01
There was no reliable record everyone could point to.
Most groups managed contributions in spreadsheets maintained by one person. That worked while everything went smoothly, but once numbers changed or disagreements appeared, there was no permanent record that everyone trusted. A spreadsheet could always be edited after the fact, and conversations explaining those changes were usually scattered across WhatsApp messages.
02
Information depended on the coordinator.
Every update flowed through one person. Members didn't have a habit of checking a system because there wasn't a system they trusted yet. If someone wanted to know whether a contribution had been received or whether an investment had been made, they sent a message to the coordinator. That made the coordinator responsible for much more than managing investments. They also became the source of truth for the group, which meant every question, clarification, and reminder eventually came back to the same person.
03
The coordinator carried all of the operational work.
Running an informal investment group involved more administration than we initially expected. Someone had to track contributions, remind members who hadn't paid yet, record investments, answer questions, and eventually calculate settlements. None of those tasks were particularly difficult on their own, but together they created a significant amount of manual work. The larger the group became, the more that workload concentrated around one individual. If that person became unavailable, lost records, or simply made a mistake, the rest of the group had very little visibility into what had happened.
01
There was no reliable record everyone could point to.
Most groups managed contributions in spreadsheets maintained by one person. That worked while everything went smoothly, but once numbers changed or disagreements appeared, there was no permanent record that everyone trusted. A spreadsheet could always be edited after the fact, and conversations explaining those changes were usually scattered across WhatsApp messages.
02
Information depended on the coordinator.
Every update flowed through one person. Members didn't have a habit of checking a system because there wasn't a system they trusted yet. If someone wanted to know whether a contribution had been received or whether an investment had been made, they sent a message to the coordinator. That made the coordinator responsible for much more than managing investments. They also became the source of truth for the group, which meant every question, clarification, and reminder eventually came back to the same person.
03
The coordinator carried all of the operational work.
Running an informal investment group involved more administration than we initially expected. Someone had to track contributions, remind members who hadn't paid yet, record investments, answer questions, and eventually calculate settlements. None of those tasks were particularly difficult on their own, but together they created a significant amount of manual work. The larger the group became, the more that workload concentrated around one individual. If that person became unavailable, lost records, or simply made a mistake, the rest of the group had very little visibility into what had happened.
One question kept coming up. Although the pilot focused on transparency and coordination, another topic surfaced repeatedly during conversations with potential users. People in the UAE wanted to know whether the investment process was genuinely Shariah compliant.
One question kept coming up. Although the pilot focused on transparency and coordination, another topic surfaced repeatedly during conversations with potential users. People in the UAE wanted to know whether the investment process was genuinely Shariah compliant.
That question appeared before discussions about expected returns, investment performance, or fees. It wasn't something the first MVP attempted to solve, largely because formal screening, governance, and compliance required a broader operational model than the product supported at that stage. So instead of treating it as a missing feature, we documented it as one of the highest priorities for future versions of the product.
That question appeared before discussions about expected returns, investment performance, or fees. It wasn't something the first MVP attempted to solve, largely because formal screening, governance, and compliance required a broader operational model than the product supported at that stage. So instead of treating it as a missing feature, we documented it as one of the highest priorities for future versions of the product.
03 · DISCOVERY RESEARCH
Is this problem already solved?
Is this problem already solved?
The behaviour we observed during the pilot didn't exist in isolation. Across many parts of the world, families and close communities already pool money informally. The model has different names depending on the region, Jamiya in the Gulf, Chit Funds in India, Kameti in Pakistan, Hagbad in Somalia, but the underlying idea is remarkably similar. A trusted group contributes regularly, one person coordinates the process, and the system depends heavily on relationships rather than technology. That raised an obvious question. If this practice has existed for decades, why hasn't software already solved it? I started by reviewing products already serving this space.
The behaviour we observed during the pilot didn't exist in isolation. Across many parts of the world, families and close communities already pool money informally. The model has different names depending on the region, Jamiya in the Gulf, Chit Funds in India, Kameti in Pakistan, Hagbad in Somalia, but the underlying idea is remarkably similar. A trusted group contributes regularly, one person coordinates the process, and the system depends heavily on relationships rather than technology. That raised an obvious question. If this practice has existed for decades, why hasn't software already solved it? I started by reviewing products already serving this space.
COMPETITOR ANALYSIS
The review showed that digital savings groups are no longer a new idea. Several products already help people organise recurring contributions or rotating savings, and some are designed specifically for users looking for Shariah-conscious financial products.
The review showed that digital savings groups are no longer a new idea. Several products already help people organise recurring contributions or rotating savings, and some are designed specifically for users looking for Shariah-conscious financial products.
What I struggled to find was software supporting the complete investment lifecycle. Most products focused on collecting money and distributing payouts. Maqamy's model was different. Members contributed into a shared pool, the coordinator invested those funds externally, and the platform recorded the investment until the group reached settlement.
What I struggled to find was software supporting the complete investment lifecycle. Most products focused on collecting money and distributing payouts. Maqamy's model was different. Members contributed into a shared pool, the coordinator invested those funds externally, and the platform recorded the investment until the group reached settlement.
That distinction influenced how we positioned the product. I stopped thinking of Maqamy as another digital savings circle and started thinking of it as infrastructure for coordinating shared investments.
That distinction influenced how we positioned the product. I stopped thinking of Maqamy as another digital savings circle and started thinking of it as infrastructure for coordinating shared investments.
The research also highlighted another shift. Many of the existing systems rely heavily on personal trust and long-standing relationships. That still works, but expectations have changed. Younger professionals across the GCC increasingly expect financial products to provide visibility by default. They're accustomed to checking transactions, balances, and activity histories through digital products rather than relying on conversations or manually maintained records. That doesn't replace trust. It changes how trust is maintained.
The research also highlighted another shift. Many of the existing systems rely heavily on personal trust and long-standing relationships. That still works, but expectations have changed. Younger professionals across the GCC increasingly expect financial products to provide visibility by default. They're accustomed to checking transactions, balances, and activity histories through digital products rather than relying on conversations or manually maintained records. That doesn't replace trust. It changes how trust is maintained.
One finding particularly stood out during the research. Islamic Finance Guru discussed how involving family members in an investment often introduces legal and administrative complexity long before investment decisions are made.
One finding particularly stood out during the research. Islamic Finance Guru discussed how involving family members in an investment often introduces legal and administrative complexity long before investment decisions are made.
Separately, research into Islamic financial literacy suggested that understanding financial principles has a stronger relationship with financial wellbeing than religious commitment alone.
Separately, research into Islamic financial literacy suggested that understanding financial principles has a stronger relationship with financial wellbeing than religious commitment alone.
Taken together, those findings reinforced something I had already seen during the pilot. Building confidence wasn't only about showing returns. People also needed to understand the process itself.
Taken together, those findings reinforced something I had already seen during the pilot. Building confidence wasn't only about showing returns. People also needed to understand the process itself.
I also came across a discussion on IslamQA where someone described managing investments for friends and family outside any formal platform. The structure looked surprisingly similar to the workflow we were designing.
I also came across a discussion on IslamQA where someone described managing investments for friends and family outside any formal platform. The structure looked surprisingly similar to the workflow we were designing.
The discussion wasn't evidence of market size, but it illustrated something important. People are already coordinating shared investments manually. The challenge isn't creating a new behaviour. It's giving existing behaviour a clearer structure and a transparent record.
The discussion wasn't evidence of market size, but it illustrated something important. People are already coordinating shared investments manually. The challenge isn't creating a new behaviour. It's giving existing behaviour a clearer structure and a transparent record.
Testing the assumptions through an exploratory survey.
Testing the assumptions through an exploratory survey.
Desk research helped me understand the broader landscape, but it couldn't tell me how potential users thought about investing today.
Desk research helped me understand the broader landscape, but it couldn't tell me how potential users thought about investing today.
Before defining the product, I wanted to understand how people approached investing, what influenced their decisions, and where they experienced uncertainty. Rather than asking people about Maqamy directly, I designed a survey around general investing behaviour so the responses wouldn't be shaped by reactions to a specific product.
Before defining the product, I wanted to understand how people approached investing, what influenced their decisions, and where they experienced uncertainty. Rather than asking people about Maqamy directly, I designed a survey around general investing behaviour so the responses wouldn't be shaped by reactions to a specific product.
The survey received 56 responses. Several patterns stood out. Nearly 84% (47 of 56) said being able to see exactly where their money was being used was extremely important. Visibility consistently ranked ahead of convenience or investment performance.
The survey received 56 responses. Several patterns stood out. Nearly 84% (47 of 56) said being able to see exactly where their money was being used was extremely important. Visibility consistently ranked ahead of convenience or investment performance.
Religious and ethical considerations were just as significant. 48 of 56 respondents said their investment decisions were influenced by their values, and many described frustration with unclear Shariah-compliant investment options or the lack of simple ways to identify compliant investments.
Religious and ethical considerations were just as significant. 48 of 56 respondents said their investment decisions were influenced by their values, and many described frustration with unclear Shariah-compliant investment options or the lack of simple ways to identify compliant investments.
The survey also challenged one of my assumptions about collaborative investing. 48 of 56 respondents said they would be interested in building wealth with family or friends rather than investing entirely on their own. Most weren't looking to hand over complete control, but they also didn't want to manage everything themselves. They preferred a balance between personal oversight and trusted guidance.
The survey also challenged one of my assumptions about collaborative investing. 48 of 56 respondents said they would be interested in building wealth with family or friends rather than investing entirely on their own. Most weren't looking to hand over complete control, but they also didn't want to manage everything themselves. They preferred a balance between personal oversight and trusted guidance.
One finding changed how I thought about trust. I expected financial loss to be the biggest factor affecting confidence in a shared investment. Instead, only 4 of 56 respondents said they would lose trust simply because a friend or family member made an investment that performed poorly. Most accepted that investing involves risk. What mattered far more was receiving a clear explanation of what had happened and being able to understand how decisions were made. That shifted my focus away from trying to design for certainty. Instead, I started thinking about how the product could reduce uncertainty by making the investment process more visible.
One finding changed how I thought about trust. I expected financial loss to be the biggest factor affecting confidence in a shared investment. Instead, only 4 of 56 respondents said they would lose trust simply because a friend or family member made an investment that performed poorly. Most accepted that investing involves risk. What mattered far more was receiving a clear explanation of what had happened and being able to understand how decisions were made. That shifted my focus away from trying to design for certainty. Instead, I started thinking about how the product could reduce uncertainty by making the investment process more visible.
04 · Research Synthesis
Connecting the Dots
Connecting the Dots
By this point, three different sources were pointing in the same direction. The pilot showed that people preferred asking the coordinator over checking the product themselves. Desk research suggested that informal group investing already depends heavily on trust and personal relationships rather than structured systems. The survey reinforced that visibility, transparency, and ethical confidence mattered more than additional financial features. Taken together, those findings changed how I defined the problem. Initially, I thought the challenge was making group investing easier. The research suggested something different. People were already willing to invest together. The harder problem was helping everyone understand what was happening after the investment began. That became the foundation for every design decision that followed.
By this point, three different sources were pointing in the same direction. The pilot showed that people preferred asking the coordinator over checking the product themselves. Desk research suggested that informal group investing already depends heavily on trust and personal relationships rather than structured systems. The survey reinforced that visibility, transparency, and ethical confidence mattered more than additional financial features. Taken together, those findings changed how I defined the problem. Initially, I thought the challenge was making group investing easier. The research suggested something different. People were already willing to invest together. The harder problem was helping everyone understand what was happening after the investment began. That became the foundation for every design decision that followed.
05 · Product Constraints
Designing within the limits of an MVP
Designing within the limits of an MVP
By the time I started designing the mobile product, the visual direction wasn't the biggest challenge. The harder part was understanding what the product could realistically be. As Adil and I worked through the product requirements document, one constraint influenced almost every design decision.
By the time I started designing the mobile product, the visual direction wasn't the biggest challenge. The harder part was understanding what the product could realistically be. As Adil and I worked through the product requirements document, one constraint influenced almost every design decision.
Maqamy couldn't hold customer funds. Under UAE regulations, holding or transferring member money would require a custody model and licensing that wasn't realistic for an early-stage MVP. Contributions and investments would continue to happen outside the platform. Maqamy's responsibility was to document what happened, not facilitate the movement of money itself. That distinction became the foundation of the product. Rather than trying to replicate the experience of a banking app, I designed the interface around visibility and accountability. Every screen needed to answer a simple question:
Maqamy couldn't hold customer funds. Under UAE regulations, holding or transferring member money would require a custody model and licensing that wasn't realistic for an early-stage MVP. Contributions and investments would continue to happen outside the platform. Maqamy's responsibility was to document what happened, not facilitate the movement of money itself. That distinction became the foundation of the product. Rather than trying to replicate the experience of a banking app, I designed the interface around visibility and accountability. Every screen needed to answer a simple question:
if the platform never touches the money, how can members still feel confident about what's happening?
if the platform never touches the money, how can members still feel confident about what's happening?
The answer wasn't another feature. It was making every important action visible. As the requirements became clearer, four rules remained consistent throughout the design process.
The answer wasn't another feature. It was making every important action visible. As the requirements became clearer, four rules remained consistent throughout the design process.
01
Contributions become permanent once a cycle closes.
Investment records shouldn't change after the fact. Once a coordinator closes a contribution cycle, the record becomes read-only. If another contribution needs to be added, it belongs to the next cycle rather than rewriting history. That gives every participant a shared point of reference instead of multiple versions of the same record.
03
Every important action leaves a record.
Throughout the pilot, one thing became obvious. People rarely asked for complicated financial information. They mostly wanted reassurance. Who contributed? When was the investment made? Has anything changed? To support those questions, every significant action is tied to a timestamp and the person who performed it. Rather than relying on memory or chat history, members can see when something happened and who recorded it. This same principle is why asset prices aren't pulled from a live feed, there isn't one at MVP stage, the coordinator updates an asset's price manually, and that update is itself a timestamped, attributed action rather than an invisible number changing on its own.
02
The platform records activity. It doesn't hold assets.
Because Maqamy is non-custodial, the interface deliberately avoids patterns commonly found in banking applications. There is no wallet. No available balance. No transfer controls. Those elements would imply that the platform stores or moves money, which isn't how the product works. Instead, the interface focuses on documenting contributions, investment activity, and settlement status.
04
Prevent mistakes before they happen.
Many financial products rely on confirmation dialogs after users attempt an action. For Maqamy, I tried to avoid that wherever possible. If an action isn't available yet, the interface communicates that through disabled states, progress indicators, or missing prerequisites rather than allowing the user to continue into an error. Reducing uncertainty felt more valuable than explaining mistakes after they occurred.
01
Contributions become permanent once a cycle closes.
Investment records shouldn't change after the fact. Once a coordinator closes a contribution cycle, the record becomes read-only. If another contribution needs to be added, it belongs to the next cycle rather than rewriting history. That gives every participant a shared point of reference instead of multiple versions of the same record.
02
The platform records activity. It doesn't hold assets.
Because Maqamy is non-custodial, the interface deliberately avoids patterns commonly found in banking applications. There is no wallet. No available balance. No transfer controls. Those elements would imply that the platform stores or moves money, which isn't how the product works. Instead, the interface focuses on documenting contributions, investment activity, and settlement status.
03
Every important action leaves a record.
Throughout the pilot, one thing became obvious. People rarely asked for complicated financial information. They mostly wanted reassurance. Who contributed? When was the investment made? Has anything changed? To support those questions, every significant action is tied to a timestamp and the person who performed it. Rather than relying on memory or chat history, members can see when something happened and who recorded it. This same principle is why asset prices aren't pulled from a live feed, there isn't one at MVP stage, the coordinator updates an asset's price manually, and that update is itself a timestamped, attributed action rather than an invisible number changing on its own.
04
Prevent mistakes before they happen.
Many financial products rely on confirmation dialogs after users attempt an action. For Maqamy, I tried to avoid that wherever possible. If an action isn't available yet, the interface communicates that through disabled states, progress indicators, or missing prerequisites rather than allowing the user to continue into an error. Reducing uncertainty felt more valuable than explaining mistakes after they occurred.
01
Contributions become permanent once a cycle closes.
Investment records shouldn't change after the fact. Once a coordinator closes a contribution cycle, the record becomes read-only. If another contribution needs to be added, it belongs to the next cycle rather than rewriting history. That gives every participant a shared point of reference instead of multiple versions of the same record.
02
The platform records activity. It doesn't hold assets.
Because Maqamy is non-custodial, the interface deliberately avoids patterns commonly found in banking applications. There is no wallet. No available balance. No transfer controls. Those elements would imply that the platform stores or moves money, which isn't how the product works. Instead, the interface focuses on documenting contributions, investment activity, and settlement status.
03
Every important action leaves a record.
Throughout the pilot, one thing became obvious. People rarely asked for complicated financial information. They mostly wanted reassurance. Who contributed? When was the investment made? Has anything changed? To support those questions, every significant action is tied to a timestamp and the person who performed it. Rather than relying on memory or chat history, members can see when something happened and who recorded it. This same principle is why asset prices aren't pulled from a live feed, there isn't one at MVP stage, the coordinator updates an asset's price manually, and that update is itself a timestamped, attributed action rather than an invisible number changing on its own.
04
Prevent mistakes before they happen.
Many financial products rely on confirmation dialogs after users attempt an action. For Maqamy, I tried to avoid that wherever possible. If an action isn't available yet, the interface communicates that through disabled states, progress indicators, or missing prerequisites rather than allowing the user to continue into an error. Reducing uncertainty felt more valuable than explaining mistakes after they occurred.
Just as important was deciding what not to build. One of the most useful parts of the PRD wasn't the feature list. It was the list of things intentionally left out. Features such as voting, recurring automated contributions, digital wallets, additional user roles, KYC workflows, and compliance management were all postponed. Some of those decisions were driven by engineering effort. Others were deliberate product choices.
Just as important was deciding what not to build. One of the most useful parts of the PRD wasn't the feature list. It was the list of things intentionally left out. Features such as voting, recurring automated contributions, digital wallets, additional user roles, KYC workflows, and compliance management were all postponed. Some of those decisions were driven by engineering effort. Others were deliberate product choices.
For example, several early discussions explored whether members should vote before investments were made. The more we examined that idea, the less appropriate it felt for the first version of the product. Groups already have different ways of making investment decisions outside the platform. Introducing voting would have added another layer of coordination without solving the core problem we observed during the pilot. The MVP wasn't trying to replace how groups made decisions. It was trying to make those decisions easier to document and follow afterward. Keeping that focus helped prevent the product from becoming unnecessarily complex.
For example, several early discussions explored whether members should vote before investments were made. The more we examined that idea, the less appropriate it felt for the first version of the product. Groups already have different ways of making investment decisions outside the platform. Introducing voting would have added another layer of coordination without solving the core problem we observed during the pilot. The MVP wasn't trying to replace how groups made decisions. It was trying to make those decisions easier to document and follow afterward. Keeping that focus helped prevent the product from becoming unnecessarily complex.
06 · Design Process
Turning a financial workflow into a product people could understand.
Turning a financial workflow into a product people could understand.
With the product constraints established, I started designing the experience itself. Rather than beginning with screens, I worked from the investment process outward. I wanted every screen to support a real task that coordinators or members already performed outside the product.
With the product constraints established, I started designing the experience itself. Rather than beginning with screens, I worked from the investment process outward. I wanted every screen to support a real task that coordinators or members already performed outside the product.
01
Understanding the two roles.
The web MVP already separated users into Admin and Member accounts. While reviewing the workflows, I realised the name "Admin" didn't accurately describe the person's role. They weren't managing software. They were organising people. They collected contributions, recorded investments, shared updates, and settled the group at the end of an investment cycle. Renaming the role to Coordinator sounds like a small change, but it improved the language across the product and better reflected how people described that responsibility in conversations.
The web MVP already separated users into Admin and Member accounts. While reviewing the workflows, I realised the name "Admin" didn't accurately describe the person's role. They weren't managing software. They were organising people. They collected contributions, recorded investments, shared updates, and settled the group at the end of an investment cycle. Renaming the role to Coordinator sounds like a small change, but it improved the language across the product and better reflected how people described that responsibility in conversations.
From there, I mapped both user roles separately. Although coordinators and members interacted with the same investment, they approached it with different questions. The coordinator needed tools to manage the process. The member mainly wanted confidence that the process was happening correctly. Trying to satisfy both through one interface quickly became confusing, so I designed separate experiences with role-specific navigation and information.
From there, I mapped both user roles separately. Although coordinators and members interacted with the same investment, they approached it with different questions. The coordinator needed tools to manage the process. The member mainly wanted confidence that the process was happening correctly. Trying to satisfy both through one interface quickly became confusing, so I designed separate experiences with role-specific navigation and information.
Within the Member role, two personas made it clear that "Member" wasn't one archetype either, a younger member and an elder member. Fatima, a tech-comfortable member in her late twenties, wanted a clean, mobile-first breakdown of her own contributions and profit or loss, real-time notifications when something changed, and no financial jargon standing between her and the answer. Omar, an elder member with low tech confidence, wanted largely the same information but needed it delivered differently, a simple, readable dashboard, larger text, plain language over financial terminology, and clear reassurance that everything stayed Shariah-compliant, since he was used to relying on younger family members to explain apps to him. Neither persona turned into a separate account type, the PRD had already ruled out roles beyond Coordinator and Member, but together they shaped how the Member experience got built: simple and jargon-free by default, rather than designed around the assumption that every member wants, or can parse, the same density of information a confident, younger user might.
Within the Member role, two personas made it clear that "Member" wasn't one archetype either, a younger member and an elder member. Fatima, a tech-comfortable member in her late twenties, wanted a clean, mobile-first breakdown of her own contributions and profit or loss, real-time notifications when something changed, and no financial jargon standing between her and the answer. Omar, an elder member with low tech confidence, wanted largely the same information but needed it delivered differently, a simple, readable dashboard, larger text, plain language over financial terminology, and clear reassurance that everything stayed Shariah-compliant, since he was used to relying on younger family members to explain apps to him. Neither persona turned into a separate account type, the PRD had already ruled out roles beyond Coordinator and Member, but together they shaped how the Member experience got built: simple and jargon-free by default, rather than designed around the assumption that every member wants, or can parse, the same density of information a confident, younger user might.
02
Mapping investment lifecycle.
Before designing individual screens, I documented the sequence of events that happened from the moment a group was created until an investment was settled. That exercise revealed four workflows that formed the foundation of the MVP: onboarding and group setup, pool creation and contribution, investment tracking and price updates, and settlement and payout.
Before designing individual screens, I documented the sequence of events that happened from the moment a group was created until an investment was settled. That exercise revealed four workflows that formed the foundation of the MVP: onboarding and group setup, pool creation and contribution, investment tracking and price updates, and settlement and payout.
Each workflow introduced moments where uncertainty could appear. Rather than designing around ideal scenarios, I focused on the points where people were most likely to stop and ask questions. Those moments shaped the information shown on each screen.
Each workflow introduced moments where uncertainty could appear. Rather than designing around ideal scenarios, I focused on the points where people were most likely to stop and ask questions. Those moments shaped the information shown on each screen.
INFORMATION ARCHITECTURE
INFORMATION ARCHITECTURE
FLOW 1. Onboarding & group CREATION
FLOW 1. Onboarding & group CREATION
FLOW 2. Pool creation & close pool
FLOW 2. Pool creation & close pool
FLOW 3. Investment CREATION & tracking
FLOW 4. CLOSE INVESTMENT & SETTLEMENT
FLOW 4. CLOSE INVESTMENT & SETTLEMENT
03
Building a design language.
Once the structure of the product was stable, I developed the visual system. The goal wasn't to create a distinctive visual style for its own sake. Financial products deal with sensitive information, so clarity mattered more than decoration.
Once the structure of the product was stable, I developed the visual system. The goal wasn't to create a distinctive visual style for its own sake. Financial products deal with sensitive information, so clarity mattered more than decoration.
The design system started with typography, colour, spacing, and layout rules based on Apple's Human Interface Guidelines. I chose Satoshi as the primary typeface because it remained highly legible across dense financial information while giving the product a contemporary feel.
The design system started with typography, colour, spacing, and layout rules based on Apple's Human Interface Guidelines. I chose Satoshi as the primary typeface because it remained highly legible across dense financial information while giving the product a contemporary feel.
From there, I documented reusable foundations for buttons, inputs, cards, navigation patterns, and status indicators. The component library is still evolving alongside development, but creating those foundations early made it easier to maintain consistency as new screens were added.
From there, I documented reusable foundations for buttons, inputs, cards, navigation patterns, and status indicators. The component library is still evolving alongside development, but creating those foundations early made it easier to maintain consistency as new screens were added.
04
Prototyping and iteration.
After defining the interaction patterns, I built an interactive prototype in Figma covering both coordinator and member journeys.
After defining the interaction patterns, I built an interactive prototype in Figma covering both coordinator and member journeys.
Rather than validating isolated screens, I tested complete workflows, paying particular attention to whether participants could follow an investment from contribution through settlement without additional explanation.
Rather than validating isolated screens, I tested complete workflows, paying particular attention to whether participants could follow an investment from contribution through settlement without additional explanation.
Feedback from those sessions led to several refinements in navigation, information hierarchy, and screen transitions before the designs were handed over for Flutter development.
Feedback from those sessions led to several refinements in navigation, information hierarchy, and screen transitions before the designs were handed over for Flutter development.
COORDINATOR SCREENS
COORDINATOR SCREENS
MEMBER SCREENS
MEMBER SCREENS
07 · FINAL SOLUTION
A product designed to reduce uncertainty.
A product designed to reduce uncertainty.
By the end of the project, the product looked very different from the web MVP we started with. The redesign wasn't driven by a new visual style or a larger feature set. It was driven by a simple question that came out of the pilot:
By the end of the project, the product looked very different from the web MVP we started with. The redesign wasn't driven by a new visual style or a larger feature set. It was driven by a simple question that came out of the pilot:
How can someone understand what's happening without asking the coordinator?
How can someone understand what's happening without asking the coordinator?
Every screen in the product exists to answer that question. The current MVP includes approximately twenty-two core screens across two role-based experiences, organised around five sections, Home, Pools, Holdings, Settlements, and Explorer, plus a Profile reached through the account row on Home. Together, they support the complete investment journey, from creating a group and collecting contributions to recording investments and settling the cycle. Explorer is a fifth, forward-looking section for market context and curated opportunities, it exists in the navigation but isn't built out yet, its current screen simply reads "coming soon."
Every screen in the product exists to answer that question. The current MVP includes approximately twenty-two core screens across two role-based experiences, organised around five sections, Home, Pools, Holdings, Settlements, and Explorer, plus a Profile reached through the account row on Home. Together, they support the complete investment journey, from creating a group and collecting contributions to recording investments and settling the cycle. Explorer is a fifth, forward-looking section for market context and curated opportunities, it exists in the navigation but isn't built out yet, its current screen simply reads "coming soon."
Coordinator
Running the investment without managing everything in chat.
Running the investment without managing everything in chat.
The coordinator is responsible for organising the group, so their experience focuses on managing progress rather than monitoring investments. From the dashboard, coordinators can see active groups, contribution status, ongoing investment cycles, and actions that still require attention. Instead of jumping between spreadsheets, notes, and messaging apps, the workflow is organised into one place.
The coordinator is responsible for organising the group, so their experience focuses on managing progress rather than monitoring investments. From the dashboard, coordinators can see active groups, contribution status, ongoing investment cycles, and actions that still require attention. Instead of jumping between spreadsheets, notes, and messaging apps, the workflow is organised into one place.
Creating a new investment follows the same sequence used during the pilot. The coordinator creates a group, starts a pool, opens a contribution cycle, records who has contributed, and closes the cycle once contributions are complete. After the investment is made externally, the details are recorded inside Maqamy, creating a shared timeline that members can reference throughout the investment.
Creating a new investment follows the same sequence used during the pilot. The coordinator creates a group, starts a pool, opens a contribution cycle, records who has contributed, and closes the cycle once contributions are complete. After the investment is made externally, the details are recorded inside Maqamy, creating a shared timeline that members can reference throughout the investment.
Every stage has a visible status. Rather than relying on memory, coordinators can immediately see whether a contribution cycle is still open, whether an investment has been recorded, or whether the group is ready for settlement. The interface is designed to reduce administrative overhead rather than automate investment decisions.
Every stage has a visible status. Rather than relying on memory, coordinators can immediately see whether a contribution cycle is still open, whether an investment has been recorded, or whether the group is ready for settlement. The interface is designed to reduce administrative overhead rather than automate investment decisions.
Coordinator
Recording investments.
Recording investments.
Because Maqamy is non-custodial, recording an investment is one of the product's most important moments. The platform doesn't execute trades or move funds. Instead, it documents what happened after the investment has taken place.
Because Maqamy is non-custodial, recording an investment is one of the product's most important moments. The platform doesn't execute trades or move funds. Instead, it documents what happened after the investment has taken place.
Each investment record includes the asset, investment date, amount, supporting notes, and its current status within the cycle. Since there's no live market feed at this stage, the coordinator updates an asset's price manually whenever it changes, a deliberate, visible action rather than a number that moves on its own. That information becomes part of the group's shared history, giving members a consistent record without requiring the coordinator to explain the same event multiple times.
Each investment record includes the asset, investment date, amount, supporting notes, and its current status within the cycle. Since there's no live market feed at this stage, the coordinator updates an asset's price manually whenever it changes, a deliberate, visible action rather than a number that moves on its own. That information becomes part of the group's shared history, giving members a consistent record without requiring the coordinator to explain the same event multiple times.
Coordinator
Reports and activity history.
Reports and activity history.
One of the features that became increasingly important during the design process was reporting. Throughout the pilot, participants repeatedly asked questions about past contributions and previous updates. That behaviour reinforced the need for a permanent activity history rather than temporary notifications.
One of the features that became increasingly important during the design process was reporting. Throughout the pilot, participants repeatedly asked questions about past contributions and previous updates. That behaviour reinforced the need for a permanent activity history rather than temporary notifications.
The reporting experience provides a chronological record of contributions, investments, settlements, and other significant events. Entries can be filtered and reviewed later, making it easier to understand how an investment progressed over time. For a non-custodial product, this history becomes one of its strongest trust-building mechanisms.
The reporting experience provides a chronological record of contributions, investments, settlements, and other significant events. Entries can be filtered and reviewed later, making it easier to understand how an investment progressed over time. For a non-custodial product, this history becomes one of its strongest trust-building mechanisms.
Member
Visibility instead of administration.
Visibility instead of administration.
Members interact with the same investment from a very different perspective. They don't need controls for managing the group. They need confidence that everything is progressing as expected.
Members interact with the same investment from a very different perspective. They don't need controls for managing the group. They need confidence that everything is progressing as expected.
For that reason, the member experience intentionally removes operational complexity and focuses on visibility. The dashboard highlights active investments, contribution status, recent updates, and the current stage of each investment cycle. Instead of contacting the coordinator for routine updates, members can check the platform and understand where the group stands at a glance.
For that reason, the member experience intentionally removes operational complexity and focuses on visibility. The dashboard highlights active investments, contribution status, recent updates, and the current stage of each investment cycle. Instead of contacting the coordinator for routine updates, members can check the platform and understand where the group stands at a glance.
Member
Following the investment.
Following the investment.
Throughout the design process, I tried to avoid presenting financial information as isolated numbers. Context mattered just as much. Members can see when contributions closed, when an investment was recorded, what asset the group invested in, and whether settlement has begun.
Throughout the design process, I tried to avoid presenting financial information as isolated numbers. Context mattered just as much. Members can see when contributions closed, when an investment was recorded, what asset the group invested in, and whether settlement has begun.
Showing the sequence of events helps people understand not only the current status but also how the investment reached that point. This approach came directly from the pilot, where participants often asked what had happened since the previous update rather than asking for performance data alone.
Showing the sequence of events helps people understand not only the current status but also how the investment reached that point. This approach came directly from the pilot, where participants often asked what had happened since the previous update rather than asking for performance data alone.
Member
Settlements.
Settlements.
The final stage of the journey is settlement. Once an investment cycle is complete, coordinators record the outcome and distribute funds outside the platform.
The final stage of the journey is settlement. Once an investment cycle is complete, coordinators record the outcome and distribute funds outside the platform.
Maqamy documents that process by recording the settlement details, completion status, and timestamps. Keeping settlement visible ensures that every participant can see when an investment has concluded and that the lifecycle has been fully completed.
Maqamy documents that process by recording the settlement details, completion status, and timestamps. Keeping settlement visible ensures that every participant can see when an investment has concluded and that the lifecycle has been fully completed.
Starting with gold, and building toward more.
Starting with gold, and building toward more.
Choosing the first investment option was a product decision as much as a design decision. Gold was already familiar to the target audience, relatively straightforward to explain, and generally accepted as a Shariah-compliant asset without debate, which made it the lowest-friction way to prove the pool-to-settlement flow worked before adding complexity around asset selection.
Choosing the first investment option was a product decision as much as a design decision. Gold was already familiar to the target audience, relatively straightforward to explain, and generally accepted as a Shariah-compliant asset without debate, which made it the lowest-friction way to prove the pool-to-settlement flow worked before adding complexity around asset selection.
Sukuk followed as the second asset, and it's live in the product today, not a future consideration. Both assets carry the same investment lifecycle, recording, manual price updates, performance tracking, and settlement, so adding Sukuk was a matter of extending an already-proven structure rather than designing a new one. Future versions of the platform may support additional asset classes such as real estate or equities, but starting with two well-understood, unambiguously Shariah-compliant options kept the MVP approachable while still giving groups a real choice.
Sukuk followed as the second asset, and it's live in the product today, not a future consideration. Both assets carry the same investment lifecycle, recording, manual price updates, performance tracking, and settlement, so adding Sukuk was a matter of extending an already-proven structure rather than designing a new one. Future versions of the platform may support additional asset classes such as real estate or equities, but starting with two well-understood, unambiguously Shariah-compliant options kept the MVP approachable while still giving groups a real choice.
08 · FINAL Validation
Looking for evidence beyond the pilot.
Looking for evidence beyond the pilot.
The initial pilot and exploratory survey gave us confidence that the problem was worth solving, but it wasn't enough to make product decisions on its own. I designed another survey to understand how people currently managed shared investments and what would make them feel comfortable participating in one. Unlike the earlier exploratory survey, this one focused on validating whether the product direction reflected the concerns potential users had already expressed during discovery.
The initial pilot and exploratory survey gave us confidence that the problem was worth solving, but it wasn't enough to make product decisions on its own. I designed another survey to understand how people currently managed shared investments and what would make them feel comfortable participating in one. Unlike the earlier exploratory survey, this one focused on validating whether the product direction reflected the concerns potential users had already expressed during discovery.
The survey was distributed in both English and Malayalam to reflect the audience we expected the product to serve. In total, we received 51 responses.
The survey was distributed in both English and Malayalam to reflect the audience we expected the product to serve. In total, we received 51 responses.
33 respondents were based in the UAE.
17 were based in India.
1 respondent was based in Saudi Arabia.
33 respondents were based in the UAE.
17 were based in India.
1 respondent was based in Saudi Arabia.
The survey wasn't intended to produce statistically representative market research. It was designed to identify recurring concerns and compare them with what we had already observed during the pilot.
The survey wasn't intended to produce statistically representative market research. It was designed to identify recurring concerns and compare them with what we had already observed during the pilot.
What surprised me.
Before analysing the responses, I expected investment performance to dominate the discussion. Instead, most concerns were about governance. Participants wanted to understand how money would be managed, how they could verify what had happened, and whether the overall process aligned with their values. Three themes appeared consistently.
Before analysing the responses, I expected investment performance to dominate the discussion. Instead, most concerns were about governance. Participants wanted to understand how money would be managed, how they could verify what had happened, and whether the overall process aligned with their values. Three themes appeared consistently.
01
Shariah compliance came before expected returns.
This was the strongest pattern in the responses. Participants consistently mentioned compliant investment opportunities and transparent processes before discussing profitability. Although the first MVP doesn't include compliance workflows or investment screening, the responses confirmed that these would become important considerations as the product evolves.
03
People wanted less dependence on one individual.
Several respondents expressed discomfort with systems that relied entirely on a single organiser. That reinforced one of the project's central design goals: making information available to everyone without requiring members to contact the coordinator for routine updates.
02
Transparency mattered more than performance.
Many respondents said they wanted a clear record of contributions, investment activity, and status updates before thinking about returns. That closely matched what we had observed during the pilot, where participants frequently asked for updates but rarely questioned the investments themselves.
01
Shariah compliance came before expected returns.
This was the strongest pattern in the responses. Participants consistently mentioned compliant investment opportunities and transparent processes before discussing profitability. Although the first MVP doesn't include compliance workflows or investment screening, the responses confirmed that these would become important considerations as the product evolves.
02
Transparency mattered more than performance.
Many respondents said they wanted a clear record of contributions, investment activity, and status updates before thinking about returns. That closely matched what we had observed during the pilot, where participants frequently asked for updates but rarely questioned the investments themselves.
03
People wanted less dependence on one individual.
Several respondents expressed discomfort with systems that relied entirely on a single organiser. That reinforced one of the project's central design goals: making information available to everyone without requiring members to contact the coordinator for routine updates.
01
Shariah compliance came before expected returns.
This was the strongest pattern in the responses. Participants consistently mentioned compliant investment opportunities and transparent processes before discussing profitability. Although the first MVP doesn't include compliance workflows or investment screening, the responses confirmed that these would become important considerations as the product evolves.
02
Transparency mattered more than performance.
Many respondents said they wanted a clear record of contributions, investment activity, and status updates before thinking about returns. That closely matched what we had observed during the pilot, where participants frequently asked for updates but rarely questioned the investments themselves.
03
People wanted less dependence on one individual.
Several respondents expressed discomfort with systems that relied entirely on a single organiser. That reinforced one of the project's central design goals: making information available to everyone without requiring members to contact the coordinator for routine updates.
What the survey changed.
The survey didn't introduce an entirely new direction. Instead, it strengthened decisions that had already emerged from the pilot. Rather than expanding the scope of the MVP, it gave us greater confidence to stay focused on transparency, visibility, and documentation instead of adding features that weren't addressing the core problem. In that sense, the survey acted more as validation than discovery.
The survey didn't introduce an entirely new direction. Instead, it strengthened decisions that had already emerged from the pilot. Rather than expanding the scope of the MVP, it gave us greater confidence to stay focused on transparency, visibility, and documentation instead of adding features that weren't addressing the core problem. In that sense, the survey acted more as validation than discovery.
09 · CURRENT STATUS
Where is maqamy now.
Where is maqamy now.
At the time of writing, Maqamy has not yet launched publicly. That means there are no active users, retention metrics, or revenue figures to report. I think it's important to be transparent about that. What the project does have is a validated product direction, a completed design foundation, and a working prototype that is now informing the Flutter implementation.
At the time of writing, Maqamy has not yet launched publicly. That means there are no active users, retention metrics, or revenue figures to report. I think it's important to be transparent about that. What the project does have is a validated product direction, a completed design foundation, and a working prototype that is now informing the Flutter implementation.
Looking back, the most valuable outcome wasn't the prototype itself. It was replacing assumptions with evidence. We started with a working web application, tested it with real participants, observed where it fell short, and used those findings to redefine the product before investing further in development. That process gave the team much more confidence in what we were building than simply continuing to add features.
Looking back, the most valuable outcome wasn't the prototype itself. It was replacing assumptions with evidence. We started with a working web application, tested it with real participants, observed where it fell short, and used those findings to redefine the product before investing further in development. That process gave the team much more confidence in what we were building than simply continuing to add features.
10 · REFLECTION
What I'd do differently.
What I'd do differently.
Looking back, I spent too much time thinking about the interface before questioning the behaviour behind it. When I first joined the project, I assumed the redesign would focus mainly on improving usability. The web MVP wasn't particularly enjoyable to use on a phone, so rebuilding it as a mobile product seemed like the obvious next step.
Looking back, I spent too much time thinking about the interface before questioning the behaviour behind it. When I first joined the project, I assumed the redesign would focus mainly on improving usability. The web MVP wasn't particularly enjoyable to use on a phone, so rebuilding it as a mobile product seemed like the obvious next step.
The pilot challenged that assumption. Even when the information people wanted was already available, they still asked the coordinator instead of opening the application. That made me realise the problem wasn't simply access. It was expectation. People trusted another person more than they trusted checking a system.
The pilot challenged that assumption. Even when the information people wanted was already available, they still asked the coordinator instead of opening the application. That made me realise the problem wasn't simply access. It was expectation. People trusted another person more than they trusted checking a system.
Later, the exploratory survey reinforced that idea in a way I hadn't expected. I assumed people would say that losing money was the fastest way to lose trust. Instead, only 4 of 56 respondents said poor investment performance alone would damage their confidence. Most accepted that investments involve risk. What they cared about was understanding what had happened, why decisions were made, and having a reliable record they could refer back to. That insight changed how I approached the rest of the project. Instead of trying to design away financial risk, I focused on reducing uncertainty. Features like timestamped activity, visible investment states, manually-updated but clearly attributed pricing, structured reports, and immutable contribution records all came from that shift in thinking. Design couldn't guarantee a successful investment. It could make sure no one was left wondering what had happened.
Later, the exploratory survey reinforced that idea in a way I hadn't expected. I assumed people would say that losing money was the fastest way to lose trust. Instead, only 4 of 56 respondents said poor investment performance alone would damage their confidence. Most accepted that investments involve risk. What they cared about was understanding what had happened, why decisions were made, and having a reliable record they could refer back to. That insight changed how I approached the rest of the project. Instead of trying to design away financial risk, I focused on reducing uncertainty. Features like timestamped activity, visible investment states, manually-updated but clearly attributed pricing, structured reports, and immutable contribution records all came from that shift in thinking. Design couldn't guarantee a successful investment. It could make sure no one was left wondering what had happened.
Looking ahead.
Looking ahead.
The product is currently being implemented in Flutter using the designs developed during this project. As development continues, the next priority is structured usability testing with people outside our immediate network to understand how new users interpret the workflows without guidance.
The product is currently being implemented in Flutter using the designs developed during this project. As development continues, the next priority is structured usability testing with people outside our immediate network to understand how new users interpret the workflows without guidance.
Beyond that, future versions of Maqamy may explore custody licensing, additional asset classes beyond gold and sukuk, a built-out Explorer section, and stronger compliance support. Those are significant changes, but I don't see them as the next step until the core experience has been tested in real investment groups.
Beyond that, future versions of Maqamy may explore custody licensing, additional asset classes beyond gold and sukuk, a built-out Explorer section, and stronger compliance support. Those are significant changes, but I don't see them as the next step until the core experience has been tested in real investment groups.
For now, I think the biggest lesson from the project is a simple one. Designing financial products isn't only about helping people move money. It's about helping them understand what is happening to it.
For now, I think the biggest lesson from the project is a simple one. Designing financial products isn't only about helping people move money. It's about helping them understand what is happening to it.
Next CASE STUDY · FOOD DELIVERY
order food. not anxiety
order food. not anxiety
→
→