It’s no secret that we’re a small team, two people to be exact. Yet, people constantly ask us how we’re able to roll out so many large features so quickly. We thought we’d share our design and development process. To do this we’ll use our brand new iOS attendee app as a case study.

1. Use customer input to drive what you build

While we have an endless list of amazing things we might want to build into the platform, we ultimately determine what those are through customer input. We’ll do this either through quantifying feedback (i.e. what are people asking for the most) or if we do have a new idea, we’ll run it by users first. From there we typically prioritize against short-term goals on what will move the needle most.

iOS attendee app: We knew attendees needed easy access to their tickets, a less confusing way to search for their events, and a way to effortlessly spread the word to friends and connections. This drove us to overhaul the iOS experience, though doing so meant adding all of this new functionality to an app that was initially designed solely for the in-event experience. The in-event experience consisted of things like schedule, venue maps, twitter feed, profiles, sponsor lists, etc. The answer was clear, we needed to redesign the app to handle the three parts of the event experience: 1) Finding an event and seeing where it is and when 2) An easy way to buy and access tickets 3) Instant access to everything going on at the event (schedule, key people, venue maps, attendee lists, etc).

1. Determine a core narrative/goal the feature needs to meet

Often times we want to build features that have all sorts of complexities to them. This results in a development cycle that is both a) longer than expected and b) has even more untested assumptions.

To counter this, we often design an experience with the bare minimum functionality that meets the narrative/goal for that feature. It’s incredibly easy to have feature bloat and it can be a challenge to avoid it.

iOS attendee app: The goal here was to integrate the three aspects of the event lifecycle with as minimal functionality as possible. This meant all of the “cool” factors we wanted to build, like even more engaging social functionality, would be deferred until after the version 1.0 was shipped.

1. Keep your mockups simple and iterate fast

Todd handles product and design. To kick things off, he’ll outline what are the key questions that the experience needs to answer and also lists the functionality to achieve them. From there, he’ll move to the whiteboard and sketch out the overall flow and keep details to a minimum. With a basic concept, he’ll move to a wireframing tool (often Omnigraffle) and will create more detailed mockups for each screen. The two of us will frequently do design checkpoints during this process and will iterate as needed. Once all wireframes are done, Todd will move to Photoshop to create pixel perfect mockups. For complex features with unique layouts and functionality, he’ll create a mockup for each screen. Otherwise, if the theme is consistent across screens, he’ll create a single pixel perfect mockup and then rely on the wireframes for the additional pages.

iOS attendee app: This was a complete redesign with most pages being vastly different. Some were completely new pages and others, like the community features, needed some simple restyling for design continuity.

Majority of the wireframes

Example of iterating from wireframe to shipped product for a specific screen

Our iOS app (storyboard above) has a lot of screens so we had to work efficiently to update all of them and create additional ones

1. Develop and test in parallel

Once the core mockups are done, Karl will start development. During this time Todd will continue the mockups for additional screens. As development progresses and new functionality is added, we’ll continuously push out new internal releases for the two of us to test. By pushing and testing frequently we can identify and fix bugs faster. As development comes closer to completion, we’ll push out less frequent milestone releases that force us to test everything across the feature. Before we sign off to ship the feature we’ll do a lot of testing on production data.

iOS attendee app: With a completely new app, a lot can go wrong. To prepare for this we pushed out test releases frequently and did an enormous amount of testing.

Other thoughts

We had two big events coming up so we had to build quickly. We handled this by setting a two week goal to ship the new app. We ultimately were able to ideate, design, build, and test the brand new attendee app in exactly two weeks. Moving this quickly does have its downsides of course. For one, the code we ship inevitably has some bugs we missed. While we’ve rarely shipped with showstoppers, there are often things we miss and have to fix soon after. For example, we had to ship an emergency build a few days before one of those events to fix some important (non-critical) functionality . Secondly, setting such tight internal deadlines means we sometimes have to defer less important functionality or clever interactions. This can be tough because we want to ensure people are experiencing what we will initially designed, but sometimes corners have to be cut, at least for a little while.

Overall, we’re happy with the rate we can pump out game changing features and get things into our customers’ hands. While a lot of what we do may be unconventional in terms of design/development/testing, we’re a small team and sometimes you have to do what you have to do to get things out the door. We hope learning about our process is helpful and we’re always looking for better ways to do things.