Going Design-First: Crafting a Weather App Citizens Love
Two years ago, our team at the Lithuanian Hydrometeorological Service set out to transform how citizens access reliable weather information. We faced a clear challenge: how to make complex weather data both accessible and engaging on mobile devices. Today, we are sharing the story of our development journey from different perspectives.
Confronting a World of Data
When our initiative was still on the level of group chat messages, we quickly realized that handling the current variety of data structures of weather data would be one of our biggest obstacles. Numeric weather data, satellite imagery, radars data and more — all streaming from multiple sensors, both local and remote data storages — needed to be processed and understood. When implementing the front-end (user-facing) software product, we had to bridge the gap between raw data sources and the understandable insights that citizens need on the go.
Our data came from various places: modern weather stations, satellite images, and even older legacy systems that had been in use for many years. Each source delivered data in different formats (either raw or pre-formatted) and at different speeds (from 5 minutes to 24 hours).
So we focused on normalizing and cleaning up the information.
Beyond mere data aggregation, our team invested significant effort into transforming raw data into something that our applications could easily use for transformtions for our front-end applications. This meant developing a microservices capable of gathering all the data from different sources at different time intervals and providing it into a multiple endpoints when requeted at any given time.
History
Though previously we had a mobile application, it was unstable and inconhesive. The old app felt like a series of independent pages: each feature had its own look and feel, and interactions varied from one view to the next.
By contrast, the new version rests on a single, unified design system — everything from shared components, consistent spacing, a harmonized color palette to a clear typographic scale. The result is an app where every tap, swipe, and scroll feels familiar, reducing the learning curve for new users and reinforcing trust in long-time.
This modular approach slashed development time (later on that) and dramatically lowered the risk of visual or functional regressions. It also meant that growing the app — adding new screens, widgets or anything else — becomes an exercise in configuration rather than one-off design.
Focusing on these visual and architectural gains is a renewed focus on clarity and performance. We documented and implemented loading states, error handling, and placeholders look so users always know what’s happening — even in poor network conditions. Animations and transitions, once inconsistent or missing, now follow a clear motion guideline to feel snappy yet unobtrusive.
In short, our design system has transformed Meteo.lt app from a collection of independent looks into an unified interface. Users encounter the same reliable, polished interactions across all screens (scenes) — whether they’re glancing at a home-screen widget, diving into a radar map, or setting up notification topics. As we continue to expand the app’s capabilities, this single source of truth ensures that every new feature enhances the overall experience, rather than adding yet another disjointed screen to the mix.
Analysing the Needs
We started by pinpointing exactly what citizens want to see on a mobile screen, then examined leading government weather mobile applciations across Europe — Estonia’s ILM+, Latvia’s Meteo.lv, Sweden’s SMHI, Spain’s AEMET, France’s Météo-France, and more.
Some lean heavily on satellite and radar imagery, others prioritize clear numerical forecasts or interactive maps. We analyzed features like onboarding flows, hourly and multi-day outlooks, push alerts, localization, customization settings.
In addition to that, we looked at different UI layout patterns — swipeable cards, expandable detail panes, home screens — and noted how each handled color segmentation, iconography, and typography for legibility. Therefore, by comparing their strengths and trade-offs, we found the right mix of visuals, data, and interactivity to meet our users’ needs without overloading them.
While we wanted to adopt proven design patterns and avoid reinventing the wheel, we also challenged ourselves to introduce genuinely fresh elements — whether that meant micro-interactions, fresh visual treatments, or innovative data visualizations — to surprise and delight our users.
User-Centric Design System
Crafting a design system that focuses on the end-user needs and wants turned out to be a game-changer for our mobile app project. We quickly learned that having the rightdata was only part of the solution — what really made a difference was presenting that data through an interface that was simple, consistent, and easy for everyone to use. Rather than following the traditional “features first, design later” approach, we did the exact opposite.
From the very beginning, we set out to create a mobile design system that served as a single source of truth for our entire team. In simple terms, a mobile design system is an evolving framework that defines how every element of your app should look and behave. For us, it meant establishing a visual style guide that tied together our brand colors, typography, icons, and imagery so that no matter which screen a user visited, the experience felt uniform and reliable. This early investment in a cohesive look not only brought clarity to our design process but also helped everyone on the team understand the requirements the same — visual — way.
Early user testing confirmed that simple, well-structured layouts were far more effective than cluttered screens. We refined our approach based on real feedback, ensuring that each design decision contributed to a smoother, more understandable user experience.
Using Figma as our collaborative platform, manager, designer and developers were in constant dialogue. This iterative process ensured that every element — from the placement of a button to the gradient effects — was scrutinized under the lens of usability and visual consistency. The result was not merely an app that looked modern and minimalistic, but one that conveyed information in a way that was both straightforward and engaging.
Our design system not only declared colors and fonts, but it also included a big set of reusable components — buttons, forms, navigational elements, and more — that could be implemented consistently across different parts of both Android and iOS mobile applications.
When every new feature was built using these pre-defined components, the final product looked polished, and the users seemed to enjoy a consistent interaction model throughout the app. By establishing clear guidelines on almost everything, we built an ecosystem that enhanced both our development efficiency and the app’s overall quality.
Perhaps most importantly, our design system resulted in smoother collaboration. With a clear set of standards and documented guidelines, the gaps between design and development were bridged effortlessly.
Everyone knew exactly what to expect and how to implement it, which minimized miscommunication and helped our team develop features more rapidly. Our design system proved its worth by making it easier to scale up in the future. New features and enhancements could be added without compromising the standartized user experience we had worked so hard to achieve.
Fragile First Impressions
Mobile app users are notoriously impatient: studies show that more than half will abandon an app if it takes longer than two seconds to load, and many will delete a misbehaving app within its very first launch.
Unlike websites — where a slow response can be forgiven with a quick refresh or a return visit — apps live full-screen on a device, competing for limited storage, battery life, and real estate. If mobile app feels sluggish, crashes, or bombards users with permissions dialogs before the request proves its value, you’ve lost them before you’ve even had a chance to engage.
This heightened sensitivity rises from the unique friction of mobile: installing an app is a bigger commitment than tapping a link. Every download consumes data, drains battery, and clutters the home screen — so users reserve that precious slot for only the most reliable, useful experiences. In that context, a single hiccup in onboarding, onboarding, or core functionality can trigger an immediate “delete,” raising the true cost of fragility far higher than a web-based UX mistake.
Recognizing how crucial first impressions are, we designed a step-by-step onboarding flow.
- First, users choose their preferred locations to tailor the weather information.
- Next, they immediately see the most important data at a glance — no distractions.
- Finally, we offer an optional exploratory phase, where users can read FAQs, interact with maps, and dive deeper if they wish.
This approach builds confidence and engagement from the very start.
After all, on mobile, every crash avoided and every millisecond saved isn’t just good engineering — it’s what keeps our retention rates high.
Technical Rework
We reengineered our data infrastructure to better manage almost real-time weather information. A key part of our project was updating our technology stack to handle large amounts of weather data reliably.
We started by moving away from direct access to a number of our legacy systems and building a modern, scalable backend server that would consist of various microservices, so it could support a busy mobile app by combining different types data into an unified structure. This allows us to more easily notice any issues with the back-end data processing or data providing itself.
One of our primary objectives was to develop an app that “never crashes”. Technical decisions were driven by our commitment to deliver a flawless, reliable experience. But what exactly defines this concept?
In the world of public service, where trust is earned through consistency and reliability, our technical innovations ensured that our app not only met but exceeded the high standards expected by the citizens. As a result, our mobile app was highly evaluated not just for its design and usability, but as a modern and simple digital companion that citizens could rely on at any time of the day.
App that Never Crashes
This project was the most creative I’ve ever worked on, which gave us the freedom to experiment — but not at the expense of stability. We didn’t chase every new framework or SDK release only to abandon it: our team’s experience let us verify each technology for long-term support.
So we built the mobile applications on different platforms with the native technologies. Cross-platform development is often seen as a way to save time and money, but the real costs surface later — especially during maintenance. When management focuses on minimizing initial investment, it usually means cutting corners on planning and requirements too. This short-sighted approach sets the stage for long-term technical debt and declining product quality — a kind of reverse Diderot effect, where starting small leads to even smaller returns over time.
For Android, we chose the native Kotlin and Jetpack Compose, while on iOS, we started with SwiftUI and Combine before migrating to Apple’s newer Concurrency framework. This stack delivered concise, type-safe code and rock-solid stability and easier maintainability on very different platforms.
And yes, we measured it — our Crashlytics data tells the story. As of last month, both Android and iOS boast crash-free user and session rates are above of around 99.5 %. In the mobile world, a fatal crash is like permanently losing a customer: users are quick to delete an app after a single hiccup, and each crash makes them less likely to come back. Even if they reopen the app that’s crashed, the uncertainty lingers until the bug is fixed, and by then you’ve lost engagement.
Below you can find our Android and iOS platforms crash-free users and crash-free sessions rates numbers for the last month as of writing this article.
Beyond outright crashes, we also keep a close eye on non-fatal errors — instances where the app surfaces an error screen but doesn’t terminate. Over the past month, fewer than 0.5 % of sessions ever displayed a non-fatal error. When they do occur, we immediately log detailed diagnostics for further investigation and offer users a clear retry path with additional options so they never feel stranded.
Under the hood, we handle a comprehensive range of error cases: remote-config fetch or activation failures, HTTP status codes (4xx client errors, 5xx server errors, too-many-requests), network failures and timeouts, local database exceptions, widget-data transfer hiccups and more.
Each category maps to a user-friendly fallback a simple error message message screen with options to retry the action, visit Meteo.lt website or check mobile app back-end server status.
All unknown errors must be handled. By catching and managing these errors before they escalate, we keep the app responsive.
Beta Testing
We chose to publish a public beta application before the official release. Now that’s the fun part which comes with its own uncertainties. How will users react? Will they install and delete the app after a minute? Or we’ll have at least some retention? What type of feedback to expect at all?
Firstly, launching our beta required us to evaluate the beta testing capabilities for each of the platforms. We had to analyse all the testing platforms (Google Play for Android, TestFlight for iOS) capabilities so we could prepare easy to follow instructions. Writing testing instructions (that would be easy to understand) for both iOS and Android platforms turned out to be quite a challenge.
While on Android the process is relatively simple — a single stage — download a public app which is declared as public beta from the Play Store (e.g. available on the store but no public rating possible), on iOS it is two stages — make people download join TestFlight, then have them download the app. And the join part not always worked 100% — we have encountered problems where transitioning from TestFlight invite link to TestFlight app would still show empty “Redeem Code” screen)…
We also had to think how to outboard users from the beta testing phase. On Android, it is (again) simple — Google Play allows users to have the same binary installed on their devices, the app would be updated automatically. On iOS, it is harder — we needed to make an intrusive informational pop-up with a direct link for App Store download which also replaces the initial beta app. Otherwise, continuing to use TestFlight app version would result in expired and unusable binary.
To find out what our users are thinking, we designed a survey via Tally. The very same survey form was split into two streams: one for general feedback and another for suggestions or reported issues. And who likes long feedback forms? No one.
The simplicity of the survey encouraged participation, resulting in over 200 responses that enriched our understanding of how users engaged with the app.
Each feedback was read and analyzed, put into sheet in the columns for selection for either must implement, possible for the future or denied for further implementation. It is essential to set a clear threshold for which feedback to consider the implementation, especially when there are hundreds of responses.
We have received an average rating of 4.6 out of 5 for design, 4.8 for stability and 4.7 for ease-of-use/intuitiveness. For us this was very unexpected. Especially, for the first beta releases. I even started questioning whether we should have released it straight into non-beta production.. 😀
Additionally, impressive ratings in potential other apps replacement for our one (mean ≈ 8.8) and recommendation likelihood (mean ≈ 9.2) confirmed that our efforts were resonating with the public.
Beta testing was both a technical challenge and an exercise in empathy and communication. Remember that behind every data point is a human experience — a narrative of trust, usability, and continued engagement.
Currently, after the application is released, we can say for sure that beta testing evaluations in numbers match the rating on the stores (Play Store and App Store). Average ratings of 4.6 to 4.8 received during beta testing via the Tally feedback form matches the current rating of the application — 4.4* on Android and 4.8* on iOS.
Building Trust in Public Service Through Digital Innovation
Our journey with the Meteo.lt mobile app displays a clear view of how digital innovation can build public trust. By focusing on user-centric design, up-to-date technical standards, and a culture of collaboration and feedback, we have redefined what a governmental software product can be.
Public trust is a valuable commodity, and this project is a perfect example for harnessing technology to serve citizens better. The success of the app is more than a technical achievement — it is a reaffirmation of our commitment to serve the public with transparency and excellence.
Scaling Up: Building on Success
As we look towards the future, we see the Lithuanian Hydrometeorological Service app as just a beginning of transforming decade-old systems into modern ones. The success of our beta testing phase has set a solid foundation for further development and expansion. Our goal now is not only to maintain what we’ve built but also to innovate continuously.
Looking ahead, we’ll keep refining usability with smoother navigation, animations and designs, while continuing with broad accessibility support. In the future, our data ecosystem will possibly include additional weather networks and entirely new — not strictly meteorological — information: Sun and Moon data, air-quality and pollen indices, alongside traditional meteorological feeds.
By sharing our story, we hope to inspire other public institutions to work in a similar manner by applying user-centered practices and create digital services that truly focus on connecting both user experience and data.
Download
The app can be downloaded from both App Store and Play Store:
Apple App Store
Android Play Store
Thank you for reading! :)
More about me and my experience here.
