A great app needs both developers and designers working together, but we often have different tools and care about different aspects of the product. It can sometimes be difficult to coordinate our work, but at LINE we always try new ways to work more effectively. For instance, I've trained designers on our team on how to submit pull requests and how to work with Interface Builder in Xcode, so they could directly participate in building our app UI. I'm always curious to learn what problems other teams encounter, and how they find solutions.
The Conference
The App Design and Development Conference (ADDC) is an international conference that aims to "create an opportunity for designers and developers to meet, find new ways to work together and get inspired in an open, inclusive and collaborative space". It has been held in Barcelona, Spain in early summer for the past three years. The conference offers a balanced mix of talks from developers and designers, and it seemed like a great conference to learn how other designers and developers are working together.
Design Sprints
Starting out the conference, Ana Oarga and Raz Burdu of Just Mad shared an eye-opening talk about the effectiveness of design sprints. A design sprint is a process of taking an idea and validating it in a surprisingly short four days, a concept first implemented by Jake Knapp while at Google Ventures, and later published in book form.
Ana and Raz had extensive experience creating new products, and tried many processes, some of which worked while some didn't. They noticed that often failures were due to not keeping user and business needs in mind. A design sprint solves this problem by validating an idea quickly before significant resources are committed to developing it.
How does a design sprint do this in four days? By getting all stakeholders (developers, designers, planners, managers, marketing, and business side people) together for four days with the following agenda:
Day 1: Explore the problem space, and everyone thinks up a solution
Day 2: Decide on one solution to explore, and create a product storyboard
Day 3: Create a prototype
Day 4: Test with real people
They walked us through one of their previous design sprints, and shared the following core principles:
- Getting started is more important than being right.
- Try to get to a tangible result and avoid endless discussion.
- Learn in the real world rather than be an armchair general.
- Visual design skills are not the point in a design sprint.
- Everyone works in the same room, but individually, to gather the best solutions.
Not every product feature needs a design sprint. Depending on the importance and urgency of the problem to be solved, and the number of people involved in generating a solution, a design sprint may not be the right choice. When done correctly, design sprints can help us create new features, enhance existing features, and rapidly solve big challenges in a rapid and reliable way.
The actual talk has much more detail and nuance, so I urge you to check out their online video. Conferences have been generously sharing their speaker slides and videos online in recent years, and ADDC is no exception. (https://addconf.com/2019/talks/) You will get to see Ana's awesome hat, and be inspired by their reminder that everyone in the audience is "in the business of bringing ideas to life."
Design Systems
Apart from design sprints, this year, design systems were no doubt the latest hot tool for helping designers and developers bring ideas to life. In fact, four speakers gave three talks on this topic. A design system is a set of common rules and elements for creating an app's UI. It can be a palette of common colors, text styles, shadows, or even animation curves. It often includes commonly shared UI components such as buttons and headers. These shared elements and components help keep designers and developers in sync, saving development and communication time.
Roy Marmelstein of Spotify shared how his company evolved their design system over six years, and how their culture of autonomy influenced the type of system that worked for them. Spotify's design system needed to enforce consistency while also allowing for a high level of autonomy. Having apps running on wildly different platforms (even refrigerators!) also complicated matters. The UI needed to be different, yet consistent with each other so that users would be comfortable.
Spotify's solution was a tiered system composed of atoms (colors, fonts), molecules (buttons, etc), and organisms (UI components such as headers). It evolved to become a layered system with a foundation layer of common elements, a platform-specific layer, and an app-specific layer. All three layers are serviced by different teams.
It's a challenge to find the right granularity and consistency. Each component has a default configuration, with the ability to switch to configurations created by each team according to their own needs. Semantic naming was also used where possible. When an element is named according to what it represents and not what it looks like, it's easier to reason about its correct usage.
Another idea that was emphasized was the equal importance of design, documentation, and code. An unambiguous source of truth that documents the design and can be translated easily to code saves a lot of time. Spotify uses JSON files to generate design system code for iOS/Android/Sketch (mostly color and typography).
Automated snapshot tests of components (not whole screens) can be used to test and to generate documentation. Playgrounds are also a good way for people to experiment.
Maria Neumayer of Deliveroo, a restaurant meal delivery service, talked about her company's design system which supports three different apps for their consumer, restaurant, and rider users. As an Android developer, she shared many practical tips about design system implementation.
Deliveroo also developed their design system out of a real need to reduce duplicated work. Previously, designers had to build four versions of every screen. By building a design system in Figma and generating a design module for apps to include, developers and designers work together to increase product delivery speed.
Maria stressed the importance of communication as key to working together smoothly. Designers need to communicate design changes and ask developers about levels of difficulty for an implementation. Developers need to talk to designers and avoid building features that aren't needed.
Building a component browser app helps keep everyone on the same page as to what components are already available, and app developers implement components themselves, instead of a dedicated component team. Deliveroo apps also have a debug panel that includes the component browser.
Clemens Morris and Omkar Pimple of N26 also mentioned how their company uses a "system glossary" app to easily allow anyone to browse available design components.
They found that after their engineer/designer headcount expanded from 15 to 80, with multiple offices in different countries and time zones, they needed a design system to help them build new features consistently. It was interesting how many of their points were also shared by the other speakers:
- A design system is also very much a product, which means communicating and solving user (designer/developer/manager) pain points is super important.
- It must be easier and faster to use a design system component compared to building something from scratch by a feature team.
- Often, knowing what components are available is the biggest problem.
- Documentation that is easy for designers, developers, and any interested stakeholders to understand is crucial.
- Finally, a contribution process where developers and designers can evolve the system ensures that all involved will continue using it.
A/B Testing
Aside from design systems, I really enjoyed Jason van der Merwe's talk about scaling A/B testing at Strava.
A/B testing is widely accepted as a great way to test product and user assumptions, but the infrastructure required to conduct such tests can be daunting. So I was keen to see how they scaled their team's processes and infrastructure to support large scale A/B tests.
In A/B testing, users are divided into cohorts and served different app features depending on their cohort. Analytics are needed to track resulting differences in user behavior, and a good reporting framework allows you to see the impact of your test.
Strava evolved through different tools for each of the above roles, but eventually settled on in-house cohorting for flexibility and ease of onboarding for new hires. Their analytics framework evolved from Google protocol buffers (too inflexible) to segment.io key value stores (too flexible), to Snowplow events (flexible for clients, but provided validation for server side, or "just right").
Notably, their reporting framework gave them insights on how all metrics were impacted during an A/B test. It's a really impressive system!
With this system, Strava managed to increase their testing from 5 experiments in 2015, 25 in 2016, to over 300 in 2019. But it's not all about tooling. They also needed to adapt to different coding standards. Strava realized that code written for experiments do not need to be robust as stable, long-running code. But experimental code needs to be pruned when not needed anymore.
If this can be accomplished, a safety net emerges that promotes a culture of experimentation, of risk taking and prioritizing learning. People have more reasons to try new things, fewer reasons to say no. It increases collaboration and creativity, promotes leadership and initiative.
Jason also shared a great story about Strava's Experiments Day, a day set aside for building experiments to improve target metrics. Experiments would be tested on 10% of users, and small enough to implement in an afternoon. The result of the story was surprising, and great motivation for implementing more A/B tests.
In the end, "I think" is not the way to make good product decisions. A/B testing is at its core a scientific method to reduce bias and learn what users actually want. This was a really compelling talk and I urge everyone to check it out and see how it can be done.
SwiftUI and iOS
Finally, as an iOS developer, I greatly enjoyed Daniel Steinberg's talk "Bringing SwiftUI to your App". Daniel gave a practical walkthrough of Apple's brand new SwiftUI framework that was thorough yet easy to understand. If you ever want to know how to talk about code in a clear, simple manner, this is a world-class example.
QA Sessions
One feature that made ADDC really stand out was a live, onstage Q&A session at the end of each speaker's talk. A website was provided where attendees could submit questions that came to mind during each talk. Questions could be asked anonymously, and everyone could see each other's questions. Questions could also be upvoted. At the end of each talk, the MC would join the speaker on stage and choose from the question list for a quick interview. This not only gave us a chance to ask questions without missing other speakers' talks, it also allowed us to benefit from questions asked by other attendees.
Meeting people
As great as the talks were, an even more important aspect of the conference was meeting and learning from our fellow conference attendees. People come to conferences from many different parts of the world, from companies with varying scale and cultures. They may have encountered similar problems to ours, or run into wildly different challenges, and devised different solutions for their products. Meeting these people and swapping stories was truly entertaining and eye-opening at the same time.
With two coffee breaks per day and a longer lunch break in between, we also had opportunities to meet the speakers in a more casual setting. This gave everyone a chance to go deeper and discuss in more detail some of the issues on our minds.
The organizers did a great job helping everyone mix together with a clever icebreaker mini-game. Early on the first day, they announced that every conference badge had an emoji sticker, and we should find other attendees with the same type of emoji as our own during the break, and take a fun photo together. With this simple goal in mind, everyone started to actively meet and talk to other people, and the conference really came alive.
Imagine my surprise when our team won the first prize, which were boxes of sangria and wine.
An events/workshop day and evening party was held in the middle of the conference schedule. It was a nice change of pace. We got a chance to relax and connect with our peers. Turns out sangria is a good catalyst for interesting shop talk!
Conclusion
Attending ADDC and meeting designers and developers from around the world was an incredible experience. I gained new knowledge about design sprints, design systems, A/B testing and other UI/UX insights, and returned with many ideas on how to build beautiful products more effectively, with reduced pain for both designers and developers.
I feel very fortunate to be working at LINE, which sponsored me to attend this conference. Developers at LINE are encouraged to contribute, interact with, and learn from the global developer community, and attending conferences is one of the many activities that is encouraged. I can only imagine what new ideas will be shared in the future, and envy already next year's attendees who get to enjoy Barcelona's warm sunshine. Thanks ADDC!