01 JUN 2024 6 min READ Case study

Let's get lean and iterative

Start-ups aren’t for everyone. They are fast-paced and require many compromises. I ran out of wardrobe space for all the hats I was wearing. This is a story of how I adapted to start-up culture.

COMPANY

"SkoolBag" is a communication platform connecting schools and parents.

PRODUCT

School administrator console for publishing school updates.

DESIGN TASK

Design a new administrator console for schools.

ROLE

Lead Product Designer / Product Owner

PLATFORM

Web application

KEY RESULTS

  • Designed and supported the development of the new admin console
  • Successfully migrated 1,000 schools to the new platform within a year without any loss of functionality

After three years in consulting, where I worked with clients such as government, banks, and universities, I was pretty skilled in "business-pleasing". The team would gather requirements, deliver them according to the business’ preferences, and move on to the next project.

Business and the consulting teams were quite disconnected. All decisions were made by the business. We had no ownership of the product. None at all.

All that was about to change when I joined a start-up.

This new role was exciting

When I found the opportunity in SkoolBag, I was so excited. I had always admired start-ups for their camaraderie and passion for the product, full of energy and ideas. I saw it as my big break. I was so ambitious: I wanted to win awards, expand the product internationally, and become the best designer possible.

I joined SkoolBag when its main goals were to develop a new console for school admins and migrate all schools to this new console. The admin console was one of SkoolBag’s multiple products, serving as a content publishing platform for schools.

SkoolBag range of products
SkoolBag products

It was a big and intimidating project. The new console was expected to be modern and responsive while remaining easy to learn for our non-tech-savvy user demographic.

… yet this role was challenging

SkoolBag was different in an unexpected way. The team worked in the iterative approach. The goal was to migrate schools as soon as possible, so they worked fast and compromised a lot on design quality, which went against everything I believed at the time.

The approach to the development was to divide schools into groups and once the features for the group were ready - migrate the group.

Migration approach
Migration approach

Will my “big break” break me?

The first months were stressful. That was my big break, and I needed to prove myself, which meant my designs had to be nothing short of perfect, even if I had to pay the price with carpal tunnel syndrome. In addition to that, I felt like a complete imposter and it was a matter of time before they uncovered me.

This approach wasn’t sustainable. The current mindset wasn't effective. I couldn’t keep isolating myself, trying to design everything alone and then simply handing it over to the team. I needed to embrace the iterative approach.

Adapting to change

Adapting to the iterative approach to design was not easy. Instinctually I wanted to deliver the final version and move on to the next feature. The testing was done not to learn from the user, but to validate my ideas. Negative feedback from users was painful and personal.

It was hard to constantly compromise on quality for the sake of fast delivery. That resulted in a long design debt, which I would try to “select for development” any opportunity I’d have.

It was also challenging to balance the rapidly changing requirements and make sure the developers' efforts weren't wasted.

Taking ownership

I realized that my stress and anxiety were coming from chasing a sense of control. Why chase it, if I could just ask for it? So, I asked for more ownership. That allowed me to stay focused on present issues and tasks of today.

In addition to my role, I stepped in as a Product Owner, managing requirement writing and joining feature prioritization discussions. I would kick off work with the dev team through feature reviews and provide them with ongoing support during feature development.

I was given the autonomy to own the product, which allowed me to do some cool stuff.

Ensuring quality, I conducted pull request reviews and tested the dev work, often having fun at those late-night debugging sessions with the team.

Collaborating closely with the dev team helped me to design features faster and more efficiently. I also learned about dev tools and processes, occasionally submitting my own pull requests with CSS tweaks.

To understand our customers better, I would interact with them on Intercom to resolve issues.

To inform the entire company about our progress, I made weekly Product update videos.

These were some of the designs I created during my time at SkoolBag:

Admin console
School profile Figma link
Admin console
Create a post Figma link
Admin console
Create an event Figma link
Admin console
Dashboard Figma link

Shifting mindset

Two years in SkoolBag completely changed my perspective on the software development process. With the help of my manager, I adopted a growth mindset. I learned not to be afraid to make mistakes. Understanding that everything I design will evolve and grow over time, striving for perfection is futile.

A growth mindset is the opposite of perfectionism.

Releasing features that aren’t perfect can be tough. There is a fear of negative feedback, damage to reputation, and customer churn.

While some customers churned, and others complained, the majority were surprisingly supportive. I learned to remind myself that as a designer, I’m wired to seek out imperfections to fix, while my users just want to send that message to parents and move on with their day.