Mobile Engineer POV :UI or DATA?
This is the First Article of the article series “Mobile Engineer POV” and Im planning on publishing an article on Every week about my past experience, so someone can learn something new💙 or not👹, who knows lets try.
As a mobile engineer, I often find myself asking “Would you open your editor and start developing the UI and screens right away?”
Let’s be real! the internet is packed with tutorials and videos making app development look like a walk in the park. They show you these eye catching, effortless UI designs that make you think, “I can totally do this!” And for side projects or learning? Absolutely go for it. There’s something magical about watching your first screens come together, watching your idea transform from a concept to a interactive interface(You know that feeling right?).
For personal projects, I genuinely encourage starting with the UI. It’s a lot of fun and provides immediate visual pleasure. When seeing your ideas come to life on the screen is exciting.
However, in a larger, real-world app, the rules are a bit different.
The Issue of Starting with UI
(From now on I am telling about working with a team, mostly in large scale and not specially applicable for personal/small projects and specially solo devs which are freelancing that are developing both UI and backend 😉)
When we start a project by developing straight into the UI, we risk overlooking multiple critical angles. We might “just start building” without considering all the necessary components. This approach can lead us down a path where we eventually push ourselves into a corner. Hidden features and requirements tend to surface too late — like constructing walls and then realizing the homeowner wants more windows.
Without proper planning, we might end up slapping on code later in a quick and dirty manner, accidentally adding technical debt in the early stages of development. This debt can compound over time, making future maintenance and scalability a nightmare.
Another drawback is getting entangled in debates over technologies. Starting with UI can pull us into discussions with teammates about whether SwiftUI is better than UIKit, or if we should use Jetpack Compose vs XML layouts in Android development. These debates, while important, can distract from the core objectives of the project.
Just because we receive UI designs doesn’t mean we have to start there.
Stepping Back to See the Bigger Picture
Let’s take a step back. We’ve known that there are many unknowns at the project’s outset. If we focus solely on the UI, we’re thinking too locally. What I want to point up the importance of seeing beyond the UI and considering the bigger picture. We need to find all the systems working together behind the scenes to make the app function interchangeably .Like an iceberg, the visible interface represents just a small fraction of the complex engineering work happening beneath the waterline.
In my experience, starting with a data-focused approach can be more effective.
How about Data-Focused Approach?
Perhaps instead of jumping into programming the UI, you begin by focusing on the data. You start thinking about all the information required like what needs to be stored, how data is passed around, and how different components interact.
Thinking about data encourages you to ask valuable questions like,
- Which fields are optional?
- Which data points determine whether certain UI components are hidden or displayed?
- What variations of screens do we need based on different data states?
By paying attetion on data, you naturally consider the foundational elements required to build a feature. This includes persistence mechanisms, networking layers, caching strategies, and data validation. These considerations are crucial, not just in building applications but also in preparing for discussions in job interviews or team planning sessions.
The Benefits of Data-First Thinking
- Starting with data helps in designing a scalable and maintainable architecture. It ensures that the data flow is well-understood and that components are decoupled where necessary and in simple terms a Better Architecture.
2. When the data model is clear, it’s easier for team members to collaborate and it will improve Collaboration.Also Backend and frontend developers can work in parallel once the data contracts are defined.
3. A data-focused approach makes it simpler to write unit tests and integration tests. You can validate data transformations and business logic without the overhead of UI components which improves the Testing quality.
4. With a solid data foundation, the UI can be built or modified without affecting the underlying logic(Flexibility in UI Implementation). This separation allows for easier updates and iterations on the UI/UX.(This can also be done in reverse and in my POV changes are less if start from logic).
Avoiding Over-Engineering
However,There is a concern to be aware of which is Don’t get carried away with over-engineering the perfect data models and abstractions.
It’s easy to dive deep into creating the perfect application with thorough named classes, types, and structures, complete with extensive test coverage. While cleanliness and testability are important, spending too much time here can delay delivering value to users.
Let the data guide you to understand what needs to be stored, passed, and presented. Use that as a starting point, but remain pragmatic.
Balancing UI and Data
In practice, a balanced approach often works best. Here are some steps I’m following and if you follow different approach or think Im missing any steps, please comment and share it with other readers.
- Define the Core User Journeys
Understand what the user is trying to achieve. This helps in identifying the essential screens and interactions.
2. Outline the Data Requirements
For each user journey, list out the data needed. Determine where this data comes from and how it’s stored.
3. Create Wireframes or Sketches
High-level designs can help visualize the flow without getting bogged down in UI specifics.
4. Set Up the Data Layer
Implement the models, services, and repositories needed to handle data operations.
5. Build the UI Components
With the data layer in place, you can build UI components that are connected to real data, making them more meaningful and easier to test.
6. Iterate and Refine
Use feedback from testing to refine both the UI and data handling.
Learning from Other Developers
Many seasoned developers support for this balanced approach(at least I know of 😌). For instance, in the Flutter community, there’s an emphasis on separating the UI from the business logic using patterns like BLoC (Business Logic Component) or Provider(Of course MVC,MVVM too). This separation allows developers to focus on data and state management before delving into UI details.
Similarly, in Android development, Clean Architecture principles encourage developers to separate concerns by dividing the app into layers as presentation, domain, and data. This structure promotes thinking about data flows and dependencies early in the development process(Pros and cons of this approach and when to use is for another article🤓).
My Opinion
Starting with the UI is exiciting, especially when we’re eager to see tangible results. However, in professional app development, it’s crucial to think holistically.First time someone said this approach to me, I just said its some BS and I know what im doing 😁 until I accepted a medium scale mobile app (They gave endpoints),I had to make changes almost 1 month because its hard to connect logic according to the UI rather otherwise which is reliable way.
So, next time you start a new project, consider taking a step back. Look beyond the UI, understand the data, and let that insight guide your development process. You’ll find that this approach not only leads to better software but also makes you a more thoughtful and effective engineer.If First Try and See the difference(if you ever think UI is needed first, Talk to your Backend Dev😆).
Happy coding!
