Design

Systems Thinking

A Case Study

At the beginning of my career in technology, I learned agile development process as a project lead and front-end developer at Carbon Five. Those early build principles have served me well as I've moved into design and become increasingly adept at combining my ability to look at the big picture, identify key connections, and break solutions into smaller, buildable parts.

This case study looks at work on a handful of related projects that, when taken together, became vital to day-to-day operations at Steve & Kate's Camp.

 

A snapshot of the Summer metrics a couple years after our first Curbside release

 
Systems design thinking considers interconnectedness, relationships, complexity, & causality.
Systems for building, whether digital or physical, necessarily break things down into the smallest components and look to simplify, abstract, and find repeatable processes. I work to chart the course between the two approaches.
 

 WHAT

OUTCOMES (SPOILER ALERT)

Express Check In

Part of SK iOS app

Express Check In allowed returning parents who had already purchased passes to pre-order lunch and skip the full-service morning check in line. After launching ECI, 21% of all families used it, making the morning check in lines faster and improving each site’s ability to plan for lunch preparation. Learn more about the making of ECI in the case study that follows.


 

Lunch Line

Part of SK iOS app

The Lunch Line app helped eliminate lunch lines by allowing staff acting as food hawkers to quickly scan camper badge’s for any food allergies before delivering their order of choice. After providing over 45,000 hot dogs in one summer, staff reported managing food allergies had become quicker and safer. Learn more about the making of the Lunch Line in the case study that follows.


 

Curbside Checkout

A web-based app

Using Curbside Checkout, staff broadcast which kids’ parents/guardians had arrived, recorded ID checks, shared messages for families, and tracked how long each family had been waiting before finalizing check-out. We saw checkout wait times reduce by up to 30% after the release of this product. Learn more about the making of Curbside Checkout in the case study that follows.


 

Screens Around Camp

A web-based app

Screens Around Camp displayed a slideshow of videos and images to staff and campers as well as displaying campers who were ready-for-checkout. After its release, it helped unify HQ messaging and weekly themes across the country.


 

WHY

Context

Steve & Kate’s Camp ran roughly 45 nationwide Summer Camps and 15 Spring Break & Holiday Camps with about 30,000 registered campers each year I was there. I came on as part of a new, albeit small, technology team in the Spring of 2016. Steve & Kate’s had decided to invest in in-house technology and we had the unique opportunity to design new products for an already profitable (primarily non-technical) business.

We served three primary user groups whose needs could be potentially impacted by our team:

  1. Kids, or as they were known all summer, Campers

  2. Parents & guardians

  3. Camp Staff

Steve & Kate’s business wasn’t technology, it was caring for people. Our team was tasked with meeting organizational goals to support unobstructed learning in our Summer Studios (Film, Animation, Music, Fashion, Coding & Robotics) as well as operational goals for parent registration and daily Camp operations. Anything we built had to immediately impact these groups’ needs if it was to serve the business. It also had to be feasible with a small team. The seasonal nature of the business made Spring Break camps a very important prototyping and testing phase before Summer launches.

 
At its heart, Steve & Kate’s business was caring for people. Our team was tasked with meeting organizational goals to support unobstructed learning in our Summer Studios as well as operational goals for parent registration and daily Camp operations.
 

HOW

RESEARCH

In my case study on human-centered process, I described methods used to observe, document and share observations, define a problem-space, and scope small projects to test hypotheses focusing on projects designed to support unobstructed learning in Summer Studios. While I used many of the same methods in these projects, the purely operational goals meant the problems were more concrete. Our staff were describing specific, measurable challenges well-suited to optimization with technology. Through workshops and observation, we knew that we wanted to:

  • Make sure staff had the best tools to keep kids safe, meeting and exceeding their basic needs

  • Reduce wait times during check in

  • Reduce wait times at checkout

  • Obtain better preliminary data for lunch order quantities, while allowing kids to change their minds

  • Eliminate lines at lunch

 

I ran workshops with leaders to identify areas of priority

We held regular iteration meetings and reflections

A closer look at the user journey

From a technology planing workshop

When evaluating software to support an existing business process, the first question is build or buy?
 

For standard processes, an out-of-the-box solution often makes more financial sense than a custom design. Steve & Kate’s had such an unusual day pass model—they allowed a day pass to be used at any site anywhere in the nation on any day all Summer, then provided full refunds for unused passes—that they had long ago determined they had to have a custom registration system. As a result, despite research to identify software-as-a-service solutions for check-in and check-out, integrating with our platform required custom solutions.

 
The next question relates to scale. Is this process happening often enough on a large enough scale that savings in efficiency and improvements in quality and consistency will outweigh the cost of building and maintaining custom software?
 

To answer these questions, we evaluated internal quantitative metrics as well as qualitative staff feedback. The Director of Customer Experience who handled our family support was an invaluable resource because she had data related to families’ most pressing concerns, questions, and complaints. I was able to use her data to identify top areas of positive and negative feedback to help determine our top priorities. Evidence pointed to there being great value in software that could not only streamline processes, but make for a more consistent check-in, check-out, and lunch time experience between sites. Moreover, we considered each of these operational areas essential to the care and basic needs of our families and campers. Because these were critical, daily operations, the impact of better supporting software had the potential to be quite beneficial to the business.

Prioritization has to acknowledge that every problem cannot be solved at once. The results are far more effective when there is a clear focus and a real feedback loop. In this way, delivery and testing cycles lead to real solutions in an efficient manner.

PLANNING, SCOPING, AND DEFINITION

Knowing that we would be tackling one area at a time, we began to solidify a development and design process that would be effective in the constraints of our seasonal business. Based on collective software experience, we immediately recognized that estimates for completion grow less accurate with larger projects. We also know that change is inevitable over time, so the process needs to accommodate change.

While it took a couple seasons to refine, working with our head of engineering, I helped establish a cycle that allowed us to scope eight week project deliverables. We did our best to define and estimate about six weeks of feature work, designing for continuous integration. By that I mean that I made sure our six week goals could be released as MVP feature additions without dependencies on subsequent development cycles. During the final two weeks of the eight, our engineers focused on any outstanding design polish and prioritized work to pay down accrued technical debt. This two week period generally allowed me to begin design and definition for the next cycle and gave us time to collect feedback during product demonstrations for those not involved in regular weekly iterations.

 

Various versions of high-level “quarry planning“.

Whiteboard planning

Summer planning

Feature specifics were entered in Asana before beginning an eight week cycle.

 

PRODUCT AND DEVELOPMENT CYCLE

Lean agile process looks to identify the smallest viable product solution and organize it in prioritized user-facing features. When designing for agile teams, I find I like to work on a big picture design before engaging engineers. This gives me the opportunity to explore possible connections, relationships, and develop a visual language to guide work. Ideally, I’ll be able to share some early big-picture thinking with product and engineering to get feedback on viability and difficulty of different ideas before focusing in on feature development or flow. As my focus narrows, I like to begin a styleguide to help me collect the re-usable kit of parts and components with which I build different views and features. I also like to work from the smallest display devices up to the biggest as I plan for responsive designs that will display on many different devices. Whether I am writing the CSS/react native styles or I’m handing off, I’m very conscious of the grids that will be used to layout my designs while building, the visual assets needed, and the need to be consistent with the building blocks I use, not only for development, but also to maintain a clear and consistently legible user experience.

 

The beginnings of a kit-of-parts

 

Curbside Beginnings

At Steve & Kate’s, our first operational project effort focused on leveraging the existing checkout flow to develop a mobile friendly flow staff could use on iPads at Curbside. To keep it lean, we built on what we had, but re-skinned it and optimized it for smaller devices.

With that in place, we began work on adding a feature to indicate that a camper was ready-for-check-out which displayed in the same mobile-friendly context. We added navigation to and from our updated check-out flow to create the first, MVP version of Curbside Checkout. Staff could then use the Checkout view on iPads at Curbside, but also all around Camp as they used their walkie-talkies to send kids to meet their families up front. They could sort by first name, last name, or current wait time to prioritize finding campers.

Finally, in a third cycle, we worked on displaying our ready for check-out campers on our Screens Around Camp view. This allowed staff and campers in rooms with Screens to see who should head out to meet their family.

I looked to create a visually consistent, easily legible code for camper status that became familiar to both staff and kids.

In this way, we broke the Curbside effort into smaller, stand-alone and non-breaking project releases. Had any one of them become more complicated than expected, there were design options in place to allow for graceful degradation of features. This mitigated risk, allowed us to test discrete goals, and efficiently brought us closer to our big picture goals.
 

Curbside Checkout demo, with added features released after feedback rounds

Re-using visual components for ready-for-checkout display on mobile devices and TVs

 

Native Toolset

Our next build efforts focused on Express Check In. Express Check In had both parent/guardian facing and staff facing components. I designed both up front, so that one developer could begin work on extending our existing accounts platform while another pair could begin work on the first version of a React Native app that would house staff tooling. While we knew the staff app would continue to grow over time, we’d begin with only the Express Check In support and navigation item. I could design with a more robust future in mind, but we could release and cleanly test the app with a single function.

React Native gave me new options as a designer and was a great fit for Camp. It allowed us to develop quickly for the iOS devices we purchased yearly, allocated, and managed with MDM software for each of our sites. It sped up development and was a great way to establish design patterns to which staff quickly become accustomed. It supported the ability to use sound for badge scans (successful and unsuccessful) and play with audible user feedback that was very effective in the fast-paced Camp environment.

 
Even in its early versions, the staff app was well-received and much-used. As a result, it quickly became the obvious place to house staff toolsets for systems beyond Express Check In. We added the Lunch Line and a staff version of Springboard that allowed staff to share activity photos to camper accounts.

LAUNCH & LEArning

These suite of products, like any other, was never really done. We continued to respond to new business requirements and feature requests and evolve the system as a whole. I am proud of having built a system and a kit of parts that could continue to easily evolve to meet ever-changing needs.

 
I designed and launched each of the projects to support Camp operations separately, but together, they formed a cohesive staff toolset with recognizable user interactions and patterns throughout.
 

Solving different problems with consistent user experience

 
 

Families and staff saw consistent messaging

 

Our React Native app was very successful and the cost of maintenance was generally lower, so my next step may have been to migrate the staff-facing Curbside tools built at the beginning of my tenure into the SK app. Moving forward I think it could have been a very clean solution.

As we introduced camper tools, like The Pool, we also found that Screens Around Camp was less critical since so much staff and camper content was available elsewhere. As in any ecosystem, I think it’s always important to be re-assessing and determining what remains valuable enough to maintain.

 

As needs evolved, so did the products

 
These suite of products, like any other, was never really done. We continued to respond to new business requirements and feature requests and evolve the system as a whole. I am proud of having built a system and a kit of parts that could continue to easily evolve to meet ever-changing needs.