
This is a record of some thoughts I wrote out for a designer I was mentoring who was considering her next career move. I wrote it in mid 2020, and only made a few minor edits since. It's probably a mix of things I read online one time or another. 

### On Joining a Startup

You might like it if you have a healthy risk appetite. The higher the risk, higher the reward. The earlier you join, the more risk you take on. If you get in early and help grow the company, then you have equity that you've grown over time, as the company grows. If you have 1% of a $2m company, and that company ends up being worth $200m after 4-5 years, that's a huge financial incentive to join! The caveat being that you have to believe in the team, the product, the market. You'll want to ensure you're investing your time and energy wisely. 

Join an early stage startup so you can get the the *magic in the air feeling *of working with founders. You get the energy of being on a team of "dreamers". Everyone is bought in, there's often few politics and no red tape. Everyone's excited to build things and send the rocket ship to the moon.

Have big impact. Design and build something well, see customers love it, and see that it generates more revenue for the company!

Work with quick deadlines, while being able to embrace ambiguity. You might work on an entirely new feature and build it in 2 or 3 days. Need to build out reporting? Get something working fast that checks the box. 

You'll work on 3x as many projects in the same amount of time. You'll learn by shipping a lot of things. You'll design onboarding, integrations, settings pages, core feature experiences, design systems, and more from the ground up. This isn't done for you, you have to figure it out and put it out there. Afterwards, you'll have experienced shipping many types of projects. You learn a lot quickly.

Learn all aspects of the business. You'll learn how to run a business, and be on top of metrics like how much ARR (annual recurring revenue) you have, and how big your customer contracts are.

Growth is everything. Your entire job will be to grow the company. Every project is about growth in one way or another, whether it's about acquiring new customers, or retention of existing.

Wear all the hats. Be the researcher, marketing designer, product designer, and PM if you want. Learn to code. Learn to sell. Do customer support for a day. There are lots of areas to explore and practice. 

Join to get a bigger title. Want to get a higher title? Join a startup and have lots of responsibility, then go somewhere after with all of the learning and experience gained.

Want to start your own company someday? Learn from the people that just started one. You get to work directly with the founders.

Form deep relationships with your colleagues. It can be a bit of an emotional and mental rollercoaster, and you'll lean on your co-workers throughout the peaks and valleys. 

These are some of the reasons I joined a startup, but it's not for everyone.

### Bigger Companies

Working at a bigger company is a different type of experience and trajectory. At big companies, people are focused on promotions, since that's the way to make more money and grow in their career. That is entirely okay, but you're more focused on choosing the right projects, teams, and getting good optics internally.

At big companies, there's likely to be a good design culture, since you'll spend a lot of time with other designers on your team. At a startup in the early days, the only time you work with other designers is with your customers, or with contractors. It sucks sometimes, but you sort of optimize for other types of learning.

Big companies often have big stock packages and big salaries. You could get a 20-30% higher salary, and big stock package (100-200k over 4 years) at most big tech. Some startups pay well, especially if they've raised lots of capital. You can get a good salary, and stock options that have higher potential to grow.

Big companies have more room for you to focus on your craft, and lean into specific skills slowly. You can certainly spend time going deeper.

---

In the end, it's your decision! There are certainly benefits to both, and it depends on your priorities, goals, and interests. There are many other great reasons to join a company, and this is just a handful of thoughts that have percolated for me.

Things to think about when getting in early

Joining an Early Stage Startup


One habit I've formed when shipping products is to write **UI Feedback docs**. I love them because they're simply the best way I've found to share issues and get them worked on fast. They generally have high clarity and are fast to put together. I've stumbled upon this practice and have taught it to a few designers.

I'll usually write them after I've handed off a design to a developer, the design has been built, and some parts of the implementation is off, or part of the design itself could be improved. I'll demo what's been built in a test environment, take screenshots (the command + shift + control + 4 shortcut is your friend here), and fill out the doc as I test.

Common problems include:

- Padding, margins, layout issues
- Incorrect color usage
- Typography styles are off
- UX copy needs iteration
- Hover and active states need work
- Design elements need an iteration now that we get a feel for them in the browser

At this point I'll crack open a Google doc, create a **two column table**, and go to town. The format is quite simple.

---

<Image src="/img/uploaded/39a3c534-c2b8-4762-969c-4ef29433a95d.png" alt="ui feedback docs google docs screenshot" width="768" height="316" caption="UI feedback docs used during our registration launch project" />

These docs sometimes get attached to a JIRA ticket called **Fit & Finish** and are added to the current sprint before being shipped, or get worked on in the following sprint after we ship. It depends on timelines and team negotiation. We all aim to ship quality product, but there's always room for sacrifices to be made!

Get design details implemented in the final stages

UI Feedback Docs for your Developers


I made a modest contribution to the All Contributors open source project. A friend Jake asked for some help to create a logo and landing page to promote the All Contributors Bot he had worked on for the project. 

I designed the logo in illustrator, wrote the copy, and hand coded the page using plain HTML / CSS, all in one day on a Saturday with Jake.

View the Site

View the GitHub Repo

<Image src="/img/uploaded/faa801d6-d6d7-47c4-82af-356e8498c782.png" alt="all contributors mockups screenshot" width="768" height="547" caption="All Contributors Landing Page" />

Brand Design, Copywriting, Front End

All Contributors


<Image src="/img/uploaded/d8593020-acfa-449c-9bcc-745544641124.png" alt="canada holidays website screenshot" width="768" height="384" caption="Sneak peek of some designs from the project" />

My friend Paul Craig and I have worked on a couple of projects together in the past, and like to keep in touch even though he lives far away in Ottawa. In November of 2019, he mentioned he was working on a small project that showed all of the statutory holidays in Canada. 

#### Paul's Project

Paul told me he wanted to make this project for a few reasons:

- Help people to figure out which days they get to have off of work, and when. Sometimes holidays fall on a Saturday, and people aren't always sure which day to take off. Friday or Monday?
- Learn about SEO and try to rank on search engines
- Play with tech and make a neat design, making something moderately useful
- You can read Paul's writeup

Paul had started building his project out when I joined the project. 

<Image src="/img/uploaded/dd53e52c-7716-4ff6-9cb2-11b21b8cac77.png" alt="first draft of pauls site" width="768" height="375" caption="Paul's MVP version of the site while he was still working with building out the data" />

#### My Contribution

I took a look at his site, and spent a couple hours iterating on his initial design based on the data Paul was using. I provided a few different versions to improve the typography's visual rhythm, improve colours, add visual interest, help with the affordances for the drop downs, and organize the holiday data into a more usable table.

<Image src="/img/uploaded/85fd09a2-962b-4aa7-ab66-e9fa3bd81e19.png" alt="3 web versions 2 mobile versions" width="768" height="424" caption="UI mocks that I provided to Paul based on what we discussed on a brief call together" />

I met with Paul on a call to go over the designs, and let him pick and choose what he wanted to use. He picked up a few ideas, and has iterated on some stuff since. I've been pretty hands off since then, but enjoyed spending a few hours to help a friend.

<Image src="/img/uploaded/0761ca89-7e0d-4056-9005-a4794ffc53f6.png" alt="mockup of canada holidays" width="768" height="1087" caption="Design iteration we landed on together" />

#### Project Outcomes

- Canadian citizens can figure out which holidays they get off for work.
- Paul owes me a favour someday.
- You can view the site here

UI Design

Canada Holidays


<Image src="/img/uploaded/ff7c1983-ae51-4490-9923-43e618cca410.png" alt="website mocks for joelbott.com" width="768" height="547" caption="Website for joelbott.com" />

The Website

The GitHub Repo

A friend of mine had just graduated from school and was started to build out his digital presence to begin applying to jobs. He had bought the domain for joelbott.com but hadn't done much with it yet.

I offered to design and build a single page site to link to his PDF, LinkedIn, and resume. I put together the design, got his stamp of approval, and put together a quick site using some simple HTML/CSS.

I deployed the site using GitHub Pages, and linked it to his domain. It was a fun 1 day self contained project.

Design, Front End, GitHub Pages

Joel Bott Portfolio Page


Like many designers, I've worked on a number of iterations of my portfolio over the years. It's a great opportunity to try out new front end tools, while also telling your story. Here are the ghosts of portfolios past.

#### 2012 — School Project

I built this site using PHP, HTML, CSS, and some jQuery to make things feel a bit magical.

<Image src="/img/uploaded/f4bf2d59-44a2-4f75-83b3-e3955989790d.jpg" alt="portfolio site from 2012" width="768" height="496" caption="2012 site built with HTML/CSS PHP 👼" />

<Image src="/img/uploaded/32d2103e-0fc9-4c21-985e-8a2c1e38c76e.jpg" alt="portfolio site from 2012" width="768" height="496" caption="Old projects I'd worked on — oh the memories 🥺" />

---

#### 2015 — First Job

I built this site during grad school using Wordpress. I took an existing theme and modified it to fit the styles I wanted to use. It was mostly filled with student projects, web projects, graphic design, and some early UX work.

<Image src="/img/uploaded/a4197157-c5b4-4a86-b27a-a46de22ea0d3.jpg" alt="portfolio from 2015" width="768" height="496" caption="2015 Custom Theme WordPress Site 💅" />

<Image src="/img/uploaded/473674ae-828d-4f50-a7ee-cd2679266098.jpg" alt="portfolio site from 2015" width="768" height="496" caption="2015 project highlights ✨" />

#### 2018/2019 — Gatsby Site

In 2018, I became interested in learning Javascript and React. I'd started learning from Wes Bos' online courses and also took an in-person Javascript course at Juno College. I built my portfolio site using Gatsby to practice using React. While building it, I landed a job at Together, so I shipped what I had built up to that point. 

View 2018 Portfolio

<Image src="/img/uploaded/795c167e-d6c5-44c1-8ddb-471c40612a3f.jpg" alt="portfolio site from 2018" width="768" height="384" caption="2018 site built with Gatsby 💪" />

---

#### 2021 — You're looking at it

I built this website using Keystone and Next.js. It was a good excuse to learn some new tech and comb through new docs and tutorials. 

I've become a lot more familiar with: 

- Next.js 
- Keystone.js
- Tailwind CSS
- Framer Motion
- Typescript — very rudimentary knowledge of how to declare types, and see what benefits you get in your IDE from using typescript 
- Working with GraphQL and building out backend schemas with Keystone for projects and posts
- Deploying on Vercel

Some more technical and front-endy designers that inspired me to build a new portfolio:

- Brian Lovin
- Gavin Nelson
- Rauno Freiberg
- Paul Stamatiou
- Ryan Lucas
- Taamannae Taabassum

Design, Front End Development, Gatsby, React, Next.js, Keystone.js

Portfolio Over the Years


<Image src="/img/uploaded/d4e7a4d1-9001-4d4a-8090-22e443daef0e.png" alt="mockup showing introduction step" width="768" height="509" caption="Preview of the registration wizard we shipped" />

Together sells a white-label product that helps Learning & Development teams at large companies run internal mentoring programs. We help with everything from marketing the program to measuring the quality of mentorship connections made. Our customers include AirBnb, Heineken, 7/11, the UN, Disney, and 80+ other organizations. 

Customers often buy us after they've tried to run their own mentoring program using Google forms, then realize how difficult it is to pair everyone up, provide guidance, and measure the success of their program. Most of our major customers are enterprise, which means they need a lot of flexibility and customizability.

To date, I've designed and iterated ~90% of the administrator and end user applications — with some help from some awesome student interns! 

---

## The Project

In Q4 of 2020, we worked on a large project (broken into a number of smaller projects) with the goal to improve how administrators launch mentorship programs. At this point the product was almost two years old, and we had about 30 customers. We set out to help our **administrator user** to create their program, launch registration, and get users paired together faster, easier, with more confidence, and less critical errors. 

Nathan, the co-founder and head of product, leads the kickoff of our projects with a **Hypothesis Brief **that we work on together. This product document signified the beginning of the **Discovery phase** of our project.

We kick this Google doc back and forth with each other to iron out details, gather additional data, clarify problems, and gain confidence. Once we're happy, we bring it to our engineering team to start collaborating on solutions.

<Image src="/img/uploaded/c527f99c-b975-48ec-8978-7ee891459551.png" alt="screenshot of a google doc showing a hypothesis brief" width="768" height="358" caption="A hypothesis brief that we used to kick off the project" />

## Why did we work on this

### We were suffering from experience rot

Experience rot happens when new features get added in ad-hoc, outside of the vision of the initial design. As a two year old startup we’d quickly shipped features as customer needs arose and glued them in. It was confusing for admins to find the features they needed to launch a program. It was leading to embarrassing mistakes.

### Reduce & avoid customer churn

Improving the “first time user experience” helps with retention. Administrators were having a bad experiences launching programs, we worried about churn. We had unhappy customers that we wanted to turn into happy customers who would shout our praises from the top of a mountain.

### Manual onboarding was no longer scalable — costing time & money

Manual onboarding was costly for us since it took a lot of our founder and CS teams' time over multiple onboarding calls — this was especially bad for smaller customers because sometimes the time we spent cost more than their contract value. We were winning RFPs and acquiring customers faster than we had before. We knew we had >10 launches coming in the next few months, and wanted to get better onboarding in place so our CS team could focus on value-add for customers, not product training.

### Improve revenue by launching more programs faster

We get paid based on** # of active pairings**. If admins can launch more programs more easily, then we can expand internally throughout existing customers, and also launch new customers faster. Faster timelines means we get paid earlier.

---

## Constraints

### Timelines & Delivery Goals

We wanted to focus on the entire program launch experience, but as an early stage startup, we also wanted to ship incrementally, so that our users could use new features as we built them. We had **3 months** to finish as much as we could, with a handful of engineers. 

We had **existing features **we could leverage that were functional, but needed iteration and improvements in how they were organized and pieced together.

### Team 

At the time, our team was comprised of 1 designer, 1 co-founder PM, 2 engineers, and 7 full-time employees total. We were small, scrappy, and needed to balance all of our customers HRIS integrations, customer requests, and product bugs while building new features.

### Research Inputs 

Most of our initial research came from working with customers directly, and analyzing their experience in product training sessions. We had low volume of admin users, so qualitative data was more helpful.

---

## Problems 

### Problem #1 — Lack of guidance in the user experience

- Features were there and worked, but there was little guidance 
- Users navigated to 5-6 different places to accomplish core tasks
- No clear indicator of progress — users complete launches over the course of several weeks, so this is especially needed

<Image src="/img/uploaded/a6ced2f7-2b00-49a6-a73f-c76285c05718.png" alt="arrows pointing to problem areas of the existing app" width="2274" height="1068" caption="Steps an admin would have to take to launch a program" />

### Problem #2 — Admins take months to launch

- Unsure of best practices of questions to ask and algorithm rules to use to suggest pairing recommendations
- Overwhelming amount of work compounded by unclear steps in process
- Procrastination / lack of motivation — it's a lot of work to run a program!

### Problem #3 — Some existing features needed an iteration

Features we had launched quickly to get user value had usability issues — big and small. While customers got the value out of the feature and it worked, sometimes it lead to minor problems, and sometimes it lead to critical errors. For example:

- Working with the questionnaire was cumbersome and admins had trouble using some question types
- It was difficult to reorder questions, meaning admins would delete and recreate questions
- Email issuesAdmins would forget to edit email templates and send emails without having proofread the copyIt was unclear which emails would send and when, leading to** **accidental email blastsNo confirmation of emails sent, so admins never knew if emails were delivered, or if users had received them
- Issues setting program permissions accurately, some users were accidentally blocked from joining programs when they shouldn't be
- Unclear which pairing process to use — admin led? or mentee led? 

### Problem #4 — Some features were missing in the user journey

Some parts of the user journey we hadn't quite solved for yet, which would require net new features. For example: 

- Hard to know what questions to ask users during registration, no clear set of default suggestions
- Some question features weren't functioning properly — like making a response to a question required
- Algorithm rules were read-only and needed to be changed manually by our engineering team in the backend
- Admins didn't know when they had the right amount of mentors and mentees registered. Sometimes there would be too few mentors for the number of mentees. They needed analysis and reassurance of when they would be ready.

---

## How did we know we had these problems?

We had a high degree of confidence in the problems in our product. Nathan our head of product and I looked at evidence from a few areas:

- **Customer support requests channel and FullStory** **sessions **— This was a great place to mine information! Lots of admins would message us on Intercom as they were launching their programs. We'd sometimes reference issues with FullStory session data, to uncover user issues. Since we were a small team, we all talked to customers through Intercom, until we hired our CS team.
- **Onboarding Sessions** — We had experience from onboarding our existing 20 or so customersNathan, head of product had been onboarding customers and launching programs since the start of the companyI had also onboarded a some smaller customers onsite during YC in CaliforniaI sat in on current customer onboarding sessions with our new CS hire
- **Scrappy user testing** — I'd tested program creation flows internally with new hires, people from our co-working space, as well as some HR leaders sourced from userinterviews.com. We watched people struggle and not complete tasks.

---

## Solutions

### Design Process

Projects are different and require different parts of the process, but I generally work through each of these steps:

1. Read, critique, contribute to product kickoff docGather more data if needed
2. Generate artifacts for team to understand the problem better
3. Design kickoff workshop to generate ideas (if necessary)
4. Generate solution flows & designs
5. Critique > Iterate
6. Start building when team feels confident and ready
7. Test & give design feedback on production work 🔥 Pull branch & ship fixes directly to branch — if I have the time
8. Ship to prod
9. Monitor on Amplitude, FullStory, Sentry, Support Channels

### User Journey Maps

Before carving out solutions, I took a 10k foot view of our administrator’s user journey, task flow, and experience based on everything I'd learned. This became a useful tool for us to align the team and prioritize projects against.

<Image src="/img/uploaded/5e89152b-6e81-495d-8cc4-516a2c5e6a57.png" alt="an experience map of admins emotions while launching programs" width="3713" height="2140" caption="An experience map showing pain points, opportunities, and experiences" />

I mapped out the emotional experience that admins were having during the process, based on on anecdotes of real experiences I’d learned about. This helped us understand the tasks admins needed to complete and empathize with their emotional experience. The empathy built helped weigh in on how we prioritized fixes.

<Image src="/img/uploaded/b1ecdb1d-ce4a-4542-9919-375a7a1260fc.png" alt="flow chart of tasks admins do while completing registration" width="3519" height="997" caption="User journey map showing tasks admins complete while running a program" />

I also mapped out all of the tasks that admins needed to complete in the process. It helped our team to start thinking of a program launch as a series of steps in a funnel that we needed to optimize.

We established 3 desired states across the launch experience:

1. Program is created 
2. Users are registered 
3. Pairings are created

### Flows, Systems, & UI Designs

I spent some time working through lo fidelity designs with my PM, Nathan. Through discussions, sketching, and quick iterations, we settled on a 4 part system that would provide the foundation on which the designs would live.

<Image src="/img/uploaded/0027c2b2-d636-4c7e-a73c-bc48cbbb3a07.png" alt="4 boxes with wizards for home, registration, pairing " width="1168" height="523" caption="Our 4 part system to build the UI around" />

<Image src="/img/uploaded/8fded974-ddcd-4fcc-a9d7-311f50f88f80.png" alt="flows showing 3 states" width="1966" height="1099" caption="3 primary flows for launching a program" />

### Pt 1/ Homepage Dashboard & Setup Helper

<Image src="/img/uploaded/3e7cab68-1ae2-4b34-ae9a-43267234058d.png" alt="homepage screenshot" width="768" height="466" caption="Homepage dashboard with setup helper" />

<Image src="/img/uploaded/298b0b40-b3d2-48b1-aa84-d58b754fa30e.png" alt="dashboards showing call to actions for register and pairing " width="764" height="741" caption="State change within the setup helper" />

- The data ticker shows progress towards an admin's goals (registration, pairings, sessions)
- The setup helper shows progress of what admins have completed
- The CTA shows the next expected step to complete
- Wizards are easily accessed from this screen, and admins can edit past steps completed too

### Pt 2/ Program Creation Wizard

<Image src="/img/uploaded/3eae4eb5-dbfc-451b-b971-8a97db0a7deb.png" alt="screenshot of choosing a program template" width="960" height="343" caption="This 2 step wizard lets admins leverage templates of content while creating programs" />

- Admins can explore templates based on common use cases
- Admins can view questions, algorithm rules, and suggested content
- Admins can choose a template to get started, or build their own from scratch

<Image src="/img/uploaded/31b33c59-3db2-4273-b459-c62f51da322b.png" alt="alternate patterns for creating content" width="1360" height="724" caption="Design explorations: Alternate patterns to choose program content after creation" />

We explored and tested different patterns in user tests. We tried out explorations where admins would select specific bodies of questions based on what they wanted to ask participants. We found that admins didn't really know what they wanted, so would choose all the questions they saw. This would have lead to a poorer user experience, with long questionnaires, so we chose to have default "out-of-the-box" program templates.

### 3/ Registration Wizard

<Image src="/img/uploaded/fc1bfc0d-f52f-4b5f-a607-495541b9048b.png" alt="Registration wizard screenshot" width="2842 " height="1138" caption="Registration wizard" />

- Admins can view all necessary steps to launch program registration in a linear view, but can also navigate to different steps ad-hoc
- Admins can see their progress, and understand which steps they've completed, and which steps need to be completed
- Admins can save their progress, and complete their registration in a follow up session, starting back where they left off 

<Image src="/img/uploaded/d3972fb6-ca2b-4869-ab8a-f4dba2cc8ed4.png" alt="alternate wizard patterns" width="2838 " height="1474" caption="Alternate patterns included horizontal tabs and a setup checklist page" />

We considered looking at flexible horizontal tab patterns, and setup stepper patterns. We tried a few different mixes, but felt the linear flow pattern worked best. 

<Image src="/img/uploaded/97c6fb04-86d6-466d-b634-a137a5fe1277.png" alt="inspiration for the wizard pattern" width="1224" height="790" caption="Inspiration for wizard pattern from Stripe, AirBnb, & Gusto" />

We liked the wizard pattern with a sidebar to show progress for a few reasons:

- We'd seen something similar from Stripe, Gusto, AirBnb for inspiration
- It is a good way to show progress for a large task, often over multiple sessions
- Keeps users focused without distracting navigation in new context
- Allows for chunking of information / progressive disclosure
- Re-usable across our app!

#### 4/ Pairing Wizard 

We reused the registration wizard pattern for the pairing process as well. It helps users since they're familiar with how it works, and also good for our small development team to reuse this pattern.

<Image src="/img/uploaded/aba70d55-f7e2-4f7b-8d95-565f8f8d2133.png" alt="pairing overview screen" width="1440" height="699" caption="Overview page for the pairing wizard" />

These 4 parts made up the foundation for the project that we would work on. We didn't have all of the designs done, but had a good overview for how this entire project would work together. We felt confident enough to rescope, put together a **Product Requirements Doc** and continue designing more key elements of the design.

We scoped out initial projects as follows:

<Image src="/img/uploaded/e9376c38-b4b9-49f4-8eab-16f2102aa5e4.png" alt="timeline of projects in a chart" width="1148" height="467" caption="Our initial scope and timeline of projects" />

---

## Delivery

While the high level system was worked out, we needed to prioritize what to build and when. This is where the discussion began around making tradeoffs and prioritization. 

First thing we did was push the **pairing process** projects to the following quarter. We focused on the pieces that would help admins to launch registration to their program, therefore helping admins to commit to the program launch and avoid procrastination. Once they launched registration, they'd have to launch the rest of the program.

<Image src="/img/uploaded/07ea8efa-af58-4c14-b281-c040a2842046.png" alt="gantt chart showing timelines changed" width="2640" height="974" caption="Revised timeline based on what we'd sussed out in discovery" />

### User Testing

The change in timelines also allowed us to spend a bit more time **usability testing** our designs with fresh administrators, while the engineers worked on building the designs. We booked 5 calls with new and existing admins, and tested our designs. 

Key changes included: 

- Improved UX copywriting to make tasks clearer
- Rearranging the order of the flow based on users' mental models

### UI Feedback Docs

I've made a habit to write up feedback docs with screenshots of what needs to be fixed while engineers write code. I'll often write pseudo code or help the developers by referencing props that need to be changed on components, or sending links to components from our front end library — we use the MUI library for our frontend, and I'm quite comfortable with the tooling and documentation! I'll usually do this before anything is shipped. I probably wrote 5-10 of these docs over the course of the project.

<Image src="/img/uploaded/39a3c534-c2b8-4762-969c-4ef29433a95d.png" alt="ui feedback docs google docs screenshot" width="1436" height="632" caption="UI feedback docs used to communicate fit & finish with my engineering team" />

### Collaborating in Code

When time allows, I like to help speed up delivery timelines by writing front end myself, or doing the fit & finish directly in the code myself. I probably submitted 5-10 PRs during this project to help out at various points. 

<Image src="/img/uploaded/9963407a-c0ab-43de-b5e5-a1e67f38c1a3.png" alt="screenshot of my github activity" width="2646" height="1196" caption="Preview of my contributions over time at Together *humblebrag*" />

---

## After We Shipped

We shipped our projects incrementally, had admins use our new features, and got feedback as we went. We tweaked and modified things that were confusing, or edge cases we'd missed. Overall, we learned a lot about the impact we were able to make months after the projects. The project was successful in many regards.

## Impact

After we'd wrapped Q4, we spent Q1 working on **Pairing Projects.** We continued to do more discovery research, and increased scope on new problems we learned about in the discovery process. I could tell you more about this, but that's a whole other tale!

Product Design, User Research, Front End

Improving the Program Launch Experience


<Image src="/img/uploaded/59fc4b2c-48e2-408e-b695-f28243a13f92.jpg" alt="mobile app preview" width="1800" height="1100" caption="Preview of Top Hat Classroom Response product" />

## The Classroom Product’s History

View the iOS App

Classroom is Top Hat’s cornerstone product that helped catapult them towards product-market fit, high growth, and venture capital. Top Hat has displaced existing hardware clickers, in favour of using smartphones and web apps. To date, millions of students have used Top Hat in higher education institutions across the United States, Canada, and the UK. From the sound of it, everything in the product must be peachy, right?

When I joined in 2017, Classroom had already been built. The issue was that crucial parts of the user experience had been neglected in a mad scramble for growth. This lead to **retention problems** because the feature set had become complex, bloated, and basic expectations of usability weren’t being met. The same sad story has befell many products. We needed to get back to basics and focus on improving the core experience.

Top Hat Classroom is relatively simple. A professor asks students a question during their lecture, and students are prompted to answer it on their phone or laptop. Then the results are displayed live in class. Professors use this interaction to engage and assess students’ comprehension in real-time, so they can pivot their teaching on-the-fly, and generate in-class discussions.

*Success for both users depends on a student’s ability to answer questions and receive grades for participating and getting correct answers.*

As long as students are able to meet these basic expectations, both users are relatively happy, right? Well, if the hot water’s barely running in your hotel, and you’re not sure how to work the faucet, there’s still a problem. For us, our Classroom apps worked, but it was missing the mark on some basic expectations.

## My Role

<Image src="/img/uploaded/17dd1fd0-fe26-49be-b148-0ede87291448.png" alt="diagram showing designer pm and 11 engineers" width="1520" height="656" caption="How my project teams were organized at the time" />

At the time, I worked on Top Hat Classroom leading design on iOS, Android, and two web teams at a ratio of 1 designer : 2 product managers : 14 developers. I lead product design from ideation to implementation.

For this specific project, I was focused primarily on iOS.Over 50% of student users submit their answers on iOS devices, so we wanted to drive the biggest impact by starting on iOS. Many of the iterative changes were adopted in the web app after being rolled out on iOS.

We were able to get laser sharp focus on the problem space thanks to our super secret weapon Jeremy, our user researcher. He helped connect us with professors for direct observation in classrooms, so we weren’t making decisions based on assumptions. My product manager Blanca was hyper focused on finding problems, and steered our ship in the right direction.

## The Classroom Experience

We started to attend classrooms and perform observational research. We’re lucky that for our use case, it’s relatively easy to sit in a classroom and observe our product in action. What’s more, is that there was a professor at University of Toronto who was using Top Hat only 10 minutes away from our office! There’s no better way to build empathy than to be a part of the experience.

### Checkpoints & Quizzes

One of the most common use cases is for professors to present slides, and ask questions throughout their lecture. They do this to check comprehension and pivot what they need to teach to students in real time. Internally, we called these comprehension checks **checkpoints**.

<Image src="/img/uploaded/a549fa1f-2733-4edb-bd26-f79d8698a8c0.png" alt="diagram showing slides and questions flow" width="1460" height="369" caption="Flow for how professors check comprehension throughout a lecture" />

Another common use case is for professors to present a 4-5 questions quiz at the beginning of class, to check if students did their homework, and understand their level of comprehension. This activity helps them choose which topics they need to go over again in class.

To enable these types of tasks, students need to be able to answer questions on their device without issues. If there are any problems while asking questions, it disrupts the learning flow, and interrupts a professor’s classroom goals.

### Asking Questions in the Classroom

<Image src="/img/uploaded/7148e909-33d6-4c33-912c-2c987128cf75.png" alt="flow showing questions being asked by students" width="3016" height="1174" caption="Flow showing how professor and student flows work " />

In the “happy path” scenario, professors open a question to gather responses from students. Students then open the question on their device, choose a response, and submit their answer. It’s important that their submission is received and grades are recorded.

While this flow might seem simple, what types of issues cause an “unhappy path?” How might we handle cases when there is low network connectivity? What happens when multiple questions are asked at once? How can we encourage students to respond to questions faster, so that we don’t waste valuable class time? How can we make things work the way students expect them to?

## Problems

Someone, somewhere, probably in a Medium article, said “Good designers fall in love with the problem, not their solutions.” Our team’s firm grounding in research made it easy to discover problems. From the observational research, event tracking data, and design heuristics we were able to have productive discussions to prioritize which problems we would tackle together.

<Image src="/img/uploaded/dfff9acb-4f84-4307-839b-20c30de78754.png" alt="flow showing problems of asking questions" width="1117" height="769" caption="Highlighting problems in the flow helped align our team around what to focus on" />

For students in the classroom we discovered the following needs:

1. **Open and answer questions faster**This keeps the teaching flow moving along inside of the classroom.We noticed some students missed the submit button completely!Some students lagged behind and missed questions
2. **General usability improvements**Students didn’t understand when a question was “closed” or “paused” by a professor. The UI didn’t reinforce what was happening.iOS navigation patterns didn’t feel natural, and caused usability issues. Users would view slides and expect to swipe from slide to slide. There was a lot of unnecessary context switching between views, and confusion while navigating.The UI for questions was inconsistent, did not comply with Accessibility guidelines.The language used to communicate states were different in the professor UI, student web UI, and student mobile UIStyle guidelines, and interaction patterns were not well defined or documented.
3. **Technical problems caused reliability/perceived reliability issues**Reliability issues caused a lot of noise and confusion in classrooms. Students were flustered and confused when their answers didn’t submit properly.We noticed sometimes students were frustrated and perceived that their answer hadn’t been submitted, when really our UI didn’t clearly communicate what was happening.We save student responses when there is poor network connectivity, but we weren’t doing a great job of letting users know that we had done so.
4. **Better assurance of answer submission**While submitting, students were unclear if their answer had been submitted. The UI didn’t instill high user confidence.Answer resubmission was unclear. If users changed their answer, they had no idea which answer had been recorded. We noticed students mashing the submit button multiple times to ensure their answer went through.Unsure if they got grades for their answer. We saw that students would immediately check the gradebook after a question was closed, sometimes to their detriment, as they would miss a follow up question as they were busy checking the gradebook.

## Solutions

### 1. The Product Dictionary

The first step was to start to align around language. Adam, another designer on my team, had lead a project on improving the professor experience in Classroom. We came up with a **Product Dictionary **the would help to define what language conventions we’d use in our designs.

<Image src="/img/uploaded/40bef36d-6b6b-403b-bfdd-dfc19b74c034.png" alt="google docs preview of questions we ask" width="2132" height="1644" caption="The beginning of our Product Dictionary" />

We gathered common terms that we would use to describe actions inside of our product. For example, do you “send” a student’s answer, or do you “submit” a students answer? Aligning our language conventions kept our products in sync, and made the experience less confusing for users.

### 2. Improved Questions & 3. Improved Slides on iOS

I worked on 3-4 different prototypes to help solve some of these issues. To generate ideas, I planned a sketching session with the mobile development team, and a separate session with the design team. I presented some of the problems we identified, we looked at how slides and questions work inside of the app currently. After sketching, I gathered these ideas to put together initial prototypes using Invision to create video clips I could start to send to colleagues on Slack to help start prioritization discussions.

<Image src="/img/uploaded/5ff9e52d-8822-4616-97a6-465170047fa3.png" alt="sample ui of questions and slides" width="2808" height="2376" caption="Ideation for solutions I explored" />

Sometimes you need to dream big and look at the ideal situation, even if it won’t be fully implemented. This can help expand the realm of possibility, and help get better compromises that put greater focus on the user. If you think small, ideas can sometimes get squeezed and scoped down into nonexistence, and in the end the user suffers.

## What We Built

After discussing, prioritizing, and thinking pragmatically about what we could build, we settled upon a design that was still user focused. We prioritized improving the **questions experience**, since it’s the primary task students need to accomplish. The ideas we looked at around optimizing the slides experience were great, but viewing slides is a secondary task, and is used less on mobile due to the screen size.



<Image src="/img/uploaded/968d6c2d-74c7-4d02-a41a-b8ec7a371c5f.png" alt="question states screenshot" width="1700" height="1541" caption="All states mapped out for real time questions" />

View Video Walkthrough

<Image src="/img/uploaded/325717b1-2cc3-4970-b0f6-6e46694fb4da.png" alt="flow showing designs we shipped" width="3138" height="1814" caption="Flow of what we shipped for questions and slides" />

A piece was still missing. We couldn’t just forget about slides. After all, **50% of the professors** that use Classroom present slides in Top Hat. Though, we didn’t have the resources to rebuild how slides worked, so we found a simple compromise to reuse the existing slide carousel functionality. I believe that this compromise actually made the design simpler and clearer to understand for users, and still keeps questions at the forefront.

<Image src="/img/uploaded/4379055e-29c6-4bc4-8d20-ac9da94981e2.png" alt="mockup of a slide and question being asked" width="1080" height="787" caption="Our slides solution which reused part of the existing slides carousel" />

## User Testing & Roll Out

Another advantage to having access to classrooms, was that we could mitigate product risk by testing new features in classrooms. After building, we loaded a Test Flight build onto our QA test devices and brought them to a classroom to observe users. We took videos of students using our app live in a real classroom. This helped us to scoop up some bugs and interaction design issues, allowing us to be more confident to roll it out. From a qualitative standpoint, the design was a success.

Afterwards, it was released to 100% of users. Our Classroom product retention improved overall, but this was just one piece of the puzzle. Users reported less issues, and professors heard less noise in their classrooms, which led to higher renewal. We also focused our CS teams on improving retention. Our whole company was on this initiative so it’s hard to attribute the success  to only one action!

I'm a product designer with front-end superpowers

(But sometimes I jump into these roles too)

Writing

Joining an Early Stage Startup

UI Feedback Docs for your Developers

Work Projects

Improving the Program Launch Experience

Classroom Response on iOS