How Developers and Designers Can Collaborate Using Flutter
We found a way to make the designer-developer handoff less painful and more productive.
Julia Park, Interaction Designer | Slava Olenin, Principal Software Engineer
The Pain Point of the Designer-Developer Handoff
A common pain point in the work between designers and developers is the back-and-forth to refine a digital product. A developer takes a first pass at designing a product based on a designer’s vision. The designer wants to tweak some things after testing early versions of the product. But conveying exactly what opacity she or he had in mind or how a drag and drop should behave isn’t exactly easy. Often, designers create another prototype just to explain what changes they want. This takes a lot of effort, time, and communication — especially for applications rich in animations and transitions.
At Favorite Medium, we asked ourselves how two teams from disparate background in education and in work experience — can collaborate more efficiently. How can we creatively address the handoff between designers and developers? What kind of workflow can reduce unnecessary steps, save time, and help us create better products?
A New Tool: Flutter
When Google announced Flutter in Google I/O 2018, we were excited about this new framework that enables deployment of native apps on both Android and iOS from a single codebase. To us, it looked more impressive than other cross-platform frameworks. Offering more flexible and beautiful UI possibilities, it also seemed to streamline the workflow between designers and developers through close collaboration within the tool. We decided to try it out ourselves.
One of Flutter’s biggest promises is a high-performance universal animation framework that allows developers to build custom transitions and animations with native performance. We can add animations to nearly every widget in our application, starting with simple click animations for buttons all the way to complex transitions between screens. In combination with hot reloading, playing with those animations is easier than ever before.
However, compared to simple values like button color or font size, animations have more values to tweak like animation speed, timing, easing, and keyframes. They’re also harder to adjust and debug, leading to increased back-and-forth between developers and designers when it comes to making changes.
Fortunately, Flutter is a very flexible framework, giving us freedom in how we can approach these problems. Here, we share an example of how we improved designer-developer interactions in a Flutter-based project, with comments by our designer Julia Park and developer Slava Olenin.
What We Did
For our project, we created a reward app that allows users to explore deals from local businesses.
1. Design the app and rough animation with Principle.
We started the design from scratch without any UI framework and also put less time and effort on a prototype than usual, expecting to edit within the Flutter framework afterwards.
2. Hand over visual assets through Figma.
We used Figma for our handover. It’s a web-based, real-time collaborating design tool that allows designers and developers to easily work together on design, interaction, and transition. “One thing that designers always have in mind is that a design should be perfect before handover,” Julia, our designer, says. “But with Figma they don’t need to worry about it because the design could change during the process. When that happens, designers can update the design and leave comments on the live file.”
3. Build the design with Flutter.
With the visual assets, the developer works on the build in Flutter. Our goal was to give the designer a way to tweak any visual aspects of the application. To achieve this, we created a theme.dart file that contained all properties that a designer might want to edit, such as button color, fonts, animation speed, and easing. That way, the designer only needs to deal with one file and doesn’t need to understand the application implementation details. This theme file can be accessed in any widget with proper hot reloading, so the designer can tweak and test theme properties without recompiling the application.
4. Set up a system for the designer to edit code.
Next, the engineer helped the designer set up six programs on a machine. These programs allow the designer to modify the theme and animations without deep understanding of the platform used for the application. “We don’t want to force them to learn Xcode or Android Studio,” says Slava, our developer.
The programs are:
Gitlab
Sourcetree
Flutter SDK
Visual Studio Code
Xcode
Android Studio
Configuring the development environment can take a significant amount of time because it involves many tools that depend on one another. Typically, the whole process takes 3 to 5 hours, depending on your bandwidth and computer performance. Fortunately, this process needs to be done only once for all Flutter projects.
5. Load the application source code.
Once the development environment is up and running, we need the application sources that we’re modifying. This step requires some effort from both the developer and designer. The designer needs an understanding of git basics. By basics, we mean just an understanding of how to get the latest changes and how to push changes to the repository. Developers need to use pull requests to validate changes made by designers and merge potential sources conflicts.
6. Developer guides designer on what can be edited and how.
Now that we have both the development environment and the latest application source code, the designer can tweak the theme and animations — and be able to see the results of those modifications instantly.
Using Flutter is key to this type of designer-developer collaboration. Since Flutter does not have any platform-specific theme files, the designer doesn’t need to understand Android or iOS-specific ways of tweaking those themes or animations. “At this point it is mainly the developer’s responsibility to create a well-configurable and maintainable theme file and the designer’s role is just tweaking values on that file,” Slava, our developer, says.
The hot reloading support in Flutter also allows the designer to preview changes instantly, without compiling the application over and over again. This saves a tremendous amount of time, especially when it comes to tweaking animations.
Julia, our designer, was worried that she would need to know how to code, but she was able to make edits without prior knowledge of coding. “It was zero stress to edit and easy to see what I could change,” she says.
She could change the colors of cards, animation speed, font, padding, and margins by simply updating the code. “Those are things that we would feel frustrated about before during QA,” she says. “This process has really helped to reduce the back-and-forth.”
Conclusion
We found that this approach using Flutter helped our designer and developer collaborate more smoothly.
Takeaways
- This process saved time for QA and the overall process.
- Both the developer and designer felt more ownership over the outcomes. Instead of thinking, “a design belongs to the designer” and “a build belongs to the developer,” we created and refined the application together.
- We learned from each other. The designer better understood development constraints and the developer better understood the intention of the design.
Pitfalls
- Designers need a basic understanding of git, which can be challenging for designers.
- Designers might introduce errors while editing the theme.dart file. “We still need to understand how to properly handle this without turning designers to programmers,” Slava says.
However, most of these pitfalls were one-time challenges and shouldn’t take additional time during the next project. Overall, we think this approach is worth trying as it saves time, increases productivity, fosters closer collaboration, and improves the end product. In the typical designer-developer dynamic, it feels like each person is speaking his or her own language — either in design speak or developer speak — to communicate intended directions and clarify details. “But now it’s like we’re using the same language to work on the product directly,” Julia says.
