I'm Eden Kurr!

Kicksite work

• Prospect List
• Landing Pages Uplift
• Memberships Uplift
• Finances Uplift

More examples available on request!

Landing Pages Refactor

Landing Pages are mini websites that Kicksite customers can create. They are primarily used to attract new leads, who can sign up for trial memberships and purchase inventory on the Page.Landing Pages were never on Classic, but they were developed before a dedicated UX designer worked at Kicksite. After completing the Memberships uplift and Family Profiles, the next step was online Family sign up. In order for that to work, Landing Pages needed to be significantly refactored on the back end. While we were at it, I was able to redesign the entire process of Landing Pages, from school owners creating them to the public form experience.This project required extensive prototyping to run by users. I brushed up on my Figma prototyping skills and created mobile and desktop versions, tailored to whoever was testing them.

Below is what the Landing Page list and editor looked like before the refactor. A major complaint was having to click the Apply button, then the Save button, to actually make changes – it looked like it would auto update, but did not.Additionally, the cramped space on the left side made it difficult to see, let alone edit, all of the modules. This example only has several options for each, but many real schools have half a dozen or more Programs and Memberships.There was also NO control over which classes could be chosen on the sign up – anything available on the Program was up for grabs. This was not what people wanted.

Before

After

In this example, I collapse and show a lot of different things to demonstrate the difference from the original. Note also how Advanced Settings are no longer quite as squirreled away.

Just one page of the Figma document. This is the Lead Capture Form list, as well as actions that can be taken from the list. All mocks were created with Auto Layout and the design system component library.

Some of the mobile prototypes:

Finances Uplift

This project was before the development of the design system – at first, some of the mocks were still being made by my colleague, who is now the UX Researcher.Once we moved into high fidelity mocks, I unofficially took over all design efforts, and was promoted to sole designer after the completion of the Finances Uplift.I also created a majority of the customer-facing documentation for the uplift, which can be found on Kicksite's Knowledge Base.

Background

I could write a LOT more about the Finances uplift but want to keep it brief. For further explanation, ask me and I'm happy to talk about it!There were MANY issues with Kicksite's legacy ("Classic") Finances, primarily the huge division between "Finances" and "Billing" – two separate sections with nearly identical names, each of which could only accommodate half of the tasks.For schools paying for a billing integration, they could run transactions directly in Kicksite with "Billing". This functionality didn't exist when Kicksite was first coded in the mid 2000s, so was tacked on haphazardly later on.Those schools with billing still had the Finances section – some daily tasks were completed there, like creating Invoices, while others could only be completed back in the Billing section. This was a pain to use and training was a nightmare.Schools without a billing integration only received the Finances section and missed out on a lot of features.We knew there was a better way to go about this. Ultimately, the sections were combined as simply "Finances." Terminology was standardized and streamlined, comprehensive documentation was made by me, and bugs were drastically reduced.There were only four full time devs at the time, two senior and two junior, and the fifth was moving into more of a leadership role.In addition to the experience within Kicksite (used by school owners or admins), we also updated the student's view in Member Portal. This made it easier for our customers' clients to add new payment methods, pay invoices from their phone, opt in to Autopay, and more.

Gallery

Some of the Recurring Billing workflows as mockups in Figma. This was pre Auto-Layout and pre setting up components, so I was doing way more tedious work than necessary!

All the various transaction notification emails

Memberships Uplift

I designed the desktop, tablet, and mobile views for Kicksite's Memberships section, from wireframe to release. Work was done in Figma, using my newly created design system and with Auto Layout for fully responsive mocks.I also created the customer-facing documentation for the uplift, which can be found on Kicksite's Knowledge Base.

Background

Kicksite is a martial arts CRM, used by school owners in Taekwondo, Karate, Brazilian Jiu-Jitsu, and many other martial arts (and some non-martial arts businesses, too!)The core functionality of our CRM is tracking – tracking classes, progression through the belt ranks, and most importantly, tracking if someone is paying.There are three main parts of this in Kicksite. The two most important are Membership and Billing. In a lot of software, these are one and the same. The membership tier informs the pricing, and they are considered a single entity. But Kicksite originally didn't have payment processing built in, so an invoicing system was created for school owners to bill people and collect cash outside of the system.There were a whole host of issues with the Finances section of Classic, one of which being that it was very separated from Memberships.Users had to go to a Student profile, add a new membership, manually calculate the dates based on the desired duration, and then go back to the profile and add a new Recurring Billing (or Recurring Invoice, if the school wasn't paying for a billing integration – these used two different parts of the system, Billing and Finances....). There was no synchronization between the two, no way to know if their duration was different, and auto renewal simply didn't exist.Creating billings and memberships separately is still technically supported, but our newer crop of schools – primarily Brazilian Jiu-Jitsu schools, run by younger and tech-savvier owners – were confused by this approach.We moved Membership creation to a template system. Now, price, duration, and billing could all be set up at the same time, while still allowing last minute changes by users with admin level permissions.To fully combine the Membership and Billing with the other main part, Programs, I introduced the Student Sign-Up flow for admins to easily get their students registered. This allows the selection of one or more memberships, then choosing a program and rank for each membership, and finally setting up each billing.

Gallery

Prospect List Refactor

Kicksite has several profile types – Student, Contact, Family, Employee, and Prospect. Prospects are people who will (hopefully!) become full time Students, but aren't sure yet. They're usually on Trial Memberships.By mid-2025, the Prospect List hadn't been updated since its initial uplift. It was okay, but the rest of the Lists for the other profile types were already completed or underway. It was time to improve, and we had years of feedback to pull from.The main improvement we sought with this uplift was greater interactivity, as well as better visualization of WHERE Prospects were. Many other software (not just CRMs) use a pipeline-type view, so we adapted that to our needs. We moved from just a list view to having two separate views: a Kanban board where Prospects could be moved around as cards, and a Table view for an experience closer to what the List was before.As always, work was done in Figma, using my design system and Auto Layout for fully responsive mocks. I also created the customer-facing documentation for the uplift, which can be found here.

Gallery

When a Prospect is created in, or moved to, the Trial status, a Trial Membership is created for them automatically

The Dashboard received two new modules to accompany the improved Prospect List. Clicking on a Priority icon filters you to only the Prospects in that Stage of that Priority, for example

Creating a new Stage and dragging it to where I want it to be

Changing the Priority on a Prospect and leaving a comment explaining why

Thanks to my usage of Components, it was very easy to create longer workflows in my mocks that didn't require much finagling when updates were needed

Creating a project-specific Components section on this Figma file was extremely helpful and prevented back-and-forth with the Design System document.

The Pitch

At the end of 2024, Kicksite shifted from Agile/Scrum to the Shape Up methodology, used by 37signals. This was a huge process change, but has greatly increased the amount of projects we are able to complete.A key part of the Shape Up process is the Pitch – a document written by the Product Owner (or anyone, really - in this case, the Pitch was written by a dev) that clearly outlines what will and will NOT be included in the project. An appetite (time frame) is determined, and multiple projects are selected at the Betting Table that occurs once every 8 week cycle.The Prospect List needed to happen, so it became a full 6 week project for one dev and myself. I took the initial wireframes from the pitch (see below for examples) and turned them into full, high fidelity mockups. Prototypes were unnecessary for this project, as we wanted to have the feature on Staging as soon as possible, and I worked directly with the developer to make sure we were on the same page.