About Climate FieldView
Climate FieldView uses big data to help farmers sustainably increase their productivity using digital tools. I am a product designer who believes our UI should match our industry-leading scientific insights. I came to San Francisco to build meaningful products like this.
I inherited a disjointed web app and a designer’s 1-sheet component artboard. I taught the design team new design tools which improved synchronization. I designed a bridge system that codified existing patterns. I convinced engineers to build my system in code. After shipping the bridge system, I laid the foundation for a full visual refresh. A visual designer and I built this system using Figma.
After multiple product pivots, Climate FieldView’s inconsistent UI styles inhibited product development and customer success.
Identify the underlying user and company needs for a design system. Then go build that system.
- KPI: With engineers, build a design system that reduces bugs, reduces time to market, and brings consistency at scale.
- KPI: Farmers have greater understanding, clarity, and accessibility using Climate FieldView’s web app.
I audited Climate FieldView’s web app. I built a 72-page slide deck of inconsistencies, including typography, buttons, icons, tables, and more. I surprised the design team with my findings. One designer said:
“I had no idea how bad it was until I saw these slides”
Design System Readiness
Climate FieldView was at a crossroads 2017. Our science-powered product was moving forward. Our designers were busy researching. But our core experience suffered from inconsistency and accessibility problems. We weren’t ready for a full redesign. I needed to solidify our design intentions and build strategies for short (6 months) and long term solutions (24 months).
Product Owner: I owned the style guide for our web app. I worked on design, education, governance, and evangelism.
Engineering: two lead engineers advised on system architecture. Two web engineers worked on the implementation.
Visual Design: a visual designer devised a new look for the next generation of Climate Fieldview in 2019.
The Climate Corporation is led by teams in Science and Engineering. Design is up and coming. Our vertically-integrated teams shipped the org structure. The app’s inconsistent styles foreshadowed the disconnected services beneath the veneer. I became the horizontal glue to bring us together.
The project started in the skunkworks. Nothing official. I knew if engineering would build this design system, it must do one thing for Climate Engineers:
The Climate design system must be faster than grabbing random components off Github.
I found one advocate in engineering. He saw the value. This influential person was the key to get Engineering’s support.
I would build a component library for official styles in Sketch. Engineers would build React-based components into a shared online library.
I was now ready for the classical part of the design process. I defined a north star. When things get weird, aim for the north star.
Design System North Star
- Clear and Accessible. Meets WCAG 2.0 standards.
- On-brand: speak to our customer. Our app is consistent.
- Goal-oriented: Help farmers make decisions.
I conducting and participating in usability studies to improve the design system. Individual studies were task-oriented. Participants were asked to complete a goal related to other product features. I noted when UI issues inhibited their success.
I focused on accessibility as a core customer need. I made sure color and text combinations were WCAG 2.0 compliant. Small gray text and minimalist controls went away.
I added contrast values to color swatches so accessibility stayed top-of-mind.
Climate FieldView lets farmers monitor their farm’s field conditions using satellite map visualizations. Map layers include crop type, rainfall, disease risk, and more.
This field map shows Crop Yield after harvest. Green means more yield, red means less yield (left example). These map colors have two problems.
Problem 1. Yield is an ordinal measurement. I believe it would be more intuitively represented with a scale of light (less) to dark (more).
Problem 2. I’m red-green color blind. Color blindness impacts 8% of men. I have a minor case, yet struggle reading the left example.
The Viridis color system is a linear system that’s highly readable. I love solved problems and proposed the switch. Another designer fought the new map colors. He wasn’t color blind. He said our customers were used to the old colors. Why help 5% of users if it hurts the other 95%?
The OXO design team has an answer. They originally designed kitchen utensils for folks with arthritis. Yet OXO’s design solutions work better for everyone. A beautiful answer.
When your voice isn’t heard by a senior designer, find an outside voice to speak for you.
Atomic design describes a taxonomy of smaller parts that make up a collective whole. Atomic colors, shapes, and spacing improved system clarity. My system enabled another designer to quickly create a login screen using atoms I built.
I wrote guidelines for common interface elements such as modal views. I based the spacing of elements on an 8-point grid.
Design Tool Upgrade
Climate designers previously built interfaces with Adobe Illustrator. After joining I helped the team transition to Sketch + Zeplin. My prior team Sketch training sessions were about to pay off. I built my library using Sketch’s Library system. Now our design team of six could synchronize UI components across the team. I exported the guidelines to Zeplin for engineers and product managers.
Our project’s big break came after several months. The Engineering team started a separate project to refactor the web app for our international launch. They needed new fluid content blocks to support language translation. I jumped on this chance to implement my design system across the site.
Engineers implemented changes in a QA version of the web app. I worked alongside our QA team to test the site and open tickets for new issues.
Our new React-based component library used simple code snippets to accelerate frontend web development. And now components shared a common source.
How would we update our system? Design would stack “breaking” changes in a 6-month release cycle. This gave engineers time to consider the system-wide impact. Engineers could deploy new components at any time with a simple JIRA ticket as their guide.
- Breaking changes: Updates to the system including CSS box model changes (width, height, border, etc). Design and Engineering must meet to describe needs.
- Non-breaking changes: New or simple component updates. Continuous deployment. Design opens a JIRA ticket with the request.
This bridge system launch was a full year in the making. My skunkworks project made it to production. With our technical foundation in place, we were ready to start on Version 2.0’s visual styles.
Design System 2.0
A visual designer and I started work on the next version in early 2019.
Our visual designer experimented with several different UI concepts for a new product experience. I refined his ideas and built them into a Figma Style library. When ready, engineers could add them to our React Component Library. Our tooling and craft came a long way.
System 2.0 Icons
I organized, labeled, and QA’ed accessibility and consistency. I built the system into a component-based Figma library.
Bring it to Life
Our visual designer made static UI mockups like this loading indicator (left). I brought the loader to life with CSS animation (right).
System 2.0 Additional Examples
We launched the bridge system in 2018. This included a Sketch Library and a React Component Library.
We saved time. Designers often skipped wireframes and prototyped in high fidelity. Engineers built consistent experiences faster with readymade React components.
Most importantly, the project strengthened Climate’s design & engineering coordination. Sadly, I left the company before our 2.0 styles were complete. I only share this second version because the team moved in a new direction.
I found one engineer who wanted to move closer to design. One engineer led to two. I got this project off the ground with their help. Why do we avoid collaboration with teams from unfamiliar disciplines? Ego. We want to feel smart. Our silos hide knowledge gaps. Tech companies solving “non-tech” problems can’t survive in isolation. This project made me a strong collaborator.
Document Document Document
An agreeable conversation between design and engineering won’t get a product on the roadmap. That’s an agreement without commitment. Write a proposal. Add diagrams. Show both the how and the why. Add this information to JIRA. Then watch your hallway conversations move to planning.
Living Design System
Your system needs help. Encourage your team to contribute. This is a living product. New patterns and ideas come from everywhere. Other designers can explore unique solutions without constraints. Their ideas often only need a few tweaks to fit with the family. Design governance is part of the job.
We should improve app production quality with visual regression testing. This includes automated snapshots of the app to find style inconsistencies.
We should track the use of every UI library component in the production app. I’d love to see every use of a primary button to assure continuity. Seeing all instances of a component in context would improve the entire system.
Tools & Resources
- WebAim: Accessibility checker for color contrast + text size
- Stark Accessibility Compliance: Accessibility Plugin for Figma & Sketch
- Color Brewer: Accessible colors for maps
- Pseudolocalize Sketch Plugin: Simulate long text strings with dummy text
- Smartling: Internationalization (i18n) service
- React Spring: Library for physics-based animations not possible with CSS
- React Styleguidist: Component dev environment with living style guide