ClickIPO Mobile and Web Apps (Shipped)

Enable retail investors to easily access and purchase IPOs.


  • The product is behind schedule.
  • Retail investors are unable to get access to initial public offerings (IPOs) and secondary offerings.
  • Broker dealers are unable to offer IPOs and secondary offerings to retail investors.
  • The offering data in the current app is unreliable and prone to errors. Developers spend a lot of time fixing bad data for offerings.


  • Identify the core problems and address those first. Keep track of stakeholder ideas and wants but don’t divert attention to them all. Iterate on the management process to add layers of communication and accountability and a bi-weekly deployment schedule. Create better documentation and a design system with reusable components.
  • Iterate on the current (react native) mobile apps (iOS and Android) to reach a state where users can at the minimum, place real orders, and remove features that don’t support this.
  • Provide brokers with receipts that keep them in compliance.
  • Create a (react js) web app to enable ClickIPO admins to access and manage offerings.



  • 1 designer
  • 1 marketer
  • 2 backend engineers
  • 1 frontend engineer

Time frame

  • 3 months

My role

  • UX research and design
  • UI design and motion design
  • Process and system design
  • User Testing and analysis
  • QA
  • Product planning and management (roadmap, sprints, standups)
  • System documentation

Tools used

  • Sketchbook
  • Figma
  • After effects
  • Jira and slack
  • Google docs / sheets / forms / drive
  • Firebase / bigquery
  • Github
  • Devices

Process Summary


  • Current / desired state audits
  • Competitive analysis
  • User testing / observing / interviewing
  • Task analysis
  • Surveys


  • Sketches / wireframes / prototypes
  • Design system documentation
  • Hi-fidelity UI with Figma / Sketch
  • Video editing and motion design with After Effects

Technical project management

  • Build and maintain product roadmap
  • Agile sprint planning and management
  • Provide accountability, direction, and support for developers
  • Prepare KPI reports and construct review presentations

Process Details

Get back on schedule

When I began the product was several behind schedule. I did a current vs desired state audit to find out what was already in place and what needed to be in place.

The biggest problems I identified were:

  • Stakeholders would interrupt developers multiple times a day to ask about the progress of certain features, and to bounce ideas about future features off of. I logged the reasons and amount of times one of the front-end devs was interrupted on one of my first days to show stakeholders how much time they were wasting. It was over half of the day!
Developers were being interrupted almost constantly.
  • Stakeholders felt developers weren’t listening to their feedback and weren’t working fast enough.
  • Developers felt stakeholders were interrupting too much and changing project scope constantly
  • No one knew what they should be working on or what others were working on.
  • Code was being recreated by different developers.
  • Developers were fixing daily problems caused by a poorly designed system.

I managed stakeholder expectations and put systems in place to track their desires and test their validity. I implemented a project management system (Jira), updated the product roadmap, instituted standups, sprints, an official QA process, and a bi-weekly deployment schedule.

I also created an internal design system where team members could access all documents and components, that simplified the existing interfaces (from 3 separate outsourced design firms), and standardized the components across web and mobile.

Styleguide base

Documents were organized within a shared google drive folder. This enabled everyone to quickly understand the research and requirements involved in the product. For example, ClickIPO is legally required to notify users about during certain states of their order. Here is the folder containing the design docs associated with notifications:

Notification documentation

These changes increased the developers velocity and focused them on the important things first. One of the big milestones that we were require to hit by the end of the year was to enable users to really purchase IPOs. ClickIPO had important funding that depended on it.

Enable users to buy IPOs

Current vs desired visual audit

To solve the problem of retail investors not being able to buy IPOs, I needed to do a current vs desired state audit to see where the product already was and where it needed to be. There was an app already in production when I started that was being billed as a ‘lite experience’ that stakeholders were using to raise capital and as a way to allow potential users to see a list of upcoming IPOs.

The current version of the app had the beginnings of a purchasing experience, but it wasn’t complete. The user could choose to order an offering but after submitting their order they would just see a big screen of text explaining that they were on a waitlist and that the product was essentially a demo. There was no where for a user to see orders they had placed, which meant they couldn’t modify orders. And there was no notification system in place to provide receipts outside the app.

Users could pretend like they were placing an order in the current state.

In order to create the full purchasing experience I began by auditing a few competitors (robinhood, merriledge, coinbase, and motif). After that I drew a flowchart in my notebook and mocked up a quick prototype in figma that we were able to test with users and stakeholders. Once we felt confident with the refined prototype I mocked up some high-fidelity solutions within the new design system that had a full order flow, an error state, and a modify / cancel order flow.

Complete purchase flow with error and cancel states

It was exciting running users through this basic experience, they were all so excited when they got to see that ‘congratulations’ screen even though they knew it was a prototype. Users were getting close to finally buying IPOs, something they have been wanting to do for a long time. To fuel that excitement I created a simple animation that elicited a few ‘wows’ from the later testers.

lottie json

I created a consistent card pattern that could exist in multiple states so the user knew if they were following an offering, if they had ordered it, and if they had received shares from their order.

An offering’s multiple card states

There also needed to exist multiple states of the offering details view, as this was the main view a user would use to research and make purchasing decisions. The current version of the app only had one state for this view, and it confused and upset users who thought they could place real orders only to find out they were on a wait list and could do nothing.

I simplified the design by using the same card pattern as the list view for the top of the page, moved the important actions we wanted users to take up above the fold, organized the content better to reduce the amount of vertical space, and placed information relative to the users actions in the view (order timestamps, allocation information).

An offering’s multiple detailed states

Enable broker dealers to offer IPOs to their users

ClickIPO doesn’t hold users’ accounts, instead the product connects to existing brokerage accounts and allows users to purchase IPOs with those existing accounts. When I started there was a big list of requirements that had been put together for this part of the project. Here is an example of the prototype I put together based on those requirements before my first interviews with users

Example of one of our prototype interaction maps

16 screens to allow broker dealers to see, sort, and search through a list of offerings, learn everything about that offering, see who participated in the offering, manage the users investments, and view the users order activity and communication history.

I interviewed a group of users from the first brokerage we were integrating with to find out what they needed. The users on the call gave me a list of things that would be nice to see, and how they envisioned things would work, and when I let them play with the prototype they were overall very satisfied. I learned however that there was only one thing that was needed at this early stage, and that was the ability to show an auditor that ClickIPO had done everything that they were legally required to do.

A simple receipt that solves the big problem of accountability.

Admin access

Developers were spending large amounts of time fixing bad data. The data was bad at its source, and its source was costing the company thousands of dollars a month.

I researched and found a core and valid source of data (from the SEC instead of a private company) and designed a system with the internal securities team that enabled them to add, edit, publish, and allocate offerings. It also acted as the core source of truth for the rest of the platform and worked well to build out everything else on top of.

This admin system needed to use simple reusable components because as we began taking real orders there were more requirements we were discovering to make it through the different clearing processes and securities checks.

Mockup of an offering management system for internal use.


By researching and understanding the different types of users and their needs, and creating clearer lines of communication and project tracking, I was able to simplify the systems requirements and focus the team on what mattered. This enabled the company to hit their first few major milestones in time, allowed beta users to buy real IPOs before the end of 2017, gave broker dealers the confidence to allow ClickIPO access to their users and systems, and freed the development team from fixing bad offering data on a daily basis.


Back to Ryan’s Portfolio

View Ryan’s Linkedin

Contact Ryan

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.