Android Feature Development at Babylon Health — Part 1: Thinking About the Problem

Photo by James Sutton on Unsplash

In the Android community, there are a lot of great technical articles out there which provide a detailed walkthrough of how to accomplish some task on the platform. They are invaluable to the community — I am very thankful for them and really enjoy reading them! One type of article which I feel does not get written enough is the type which not only shares how to implement something, but also shares the developers thought process along the way.

In my opinion, there is something fascinating about reading how developers think when trying to implement a solution. Sometimes we implement solutions that just work right away, while other times we implement solutions that do not. We have to iterate on the latter until we get them right.

“It is about the journey, not the destination.”

In programming, the above quote is not strictly true — the destination (the solution) and its correctness absolutely matter. However, I appreciate the sentiment of the quote because I am often more interested in hearing about the journey that the engineer went through in terms of their thought process while working on their solution. I enjoy knowing how they planned an implementation of a solution, what the first iteration of the solution they came up with was, how it evolved over time, what the final solution was and the decisions they had to make in-between. Not only is this process just fascinating to read, it also helps me to think about my own development process. It influences how I gather my thoughts and how I translate those thoughts into a usable, testable implementation.

In this series, I am going to walk through a feature I have been working on at Babylon Health, while describing some of the shared processes/systems we have at the company, how I planned and implemented a solution and some of the technical decisions I made along the way. Sometimes, feature development can take twists and turns throughout the process and this article intends to show the evolution of a feature from start to finish.

Starting to Think About the Problem

At Babylon Health, every piece of work that we do on the Android app, whether it is a feature or a bug fix, is accounted for on Jira. Generally, each squad (a small, autonomous cross-functional team) has its own Jira board. There is also a shared Android board for tech debt and various other tasks that are unrelated to our squad work. A list of our current squads can be found here.

So when starting a new piece of squad work, the squad Jira board is the first place I look. It is the shared source of truth for the team and the place that is most likely to contain any information I need from relevant colleagues such as designers and testers. Now, because the task I am going to talk about included UI elements, Jira is the place where I would find links to any designs and diagrams of any screens or flows I needed to reference in order to carry out the upcoming task.

At Babylon Health, we keep all of our designs for the app on Zeplin and use Miro for whiteboarding our UX design and screen-to-screen flows (though at the time of writing, we are currently moving towards using Figma). The great thing about Zeplin is that Android is a first-class citizen on the platform — it allows you to specify dimensions in DP, define assets, colours, text styles and even has support for Android XML layout code.

Upon picking up a new task/story on Jira, I make sure to look clearly at the issue name, description (checking for a clearly-defined set of acceptance criteria) and check that all necessary attachments are present on the issue (such as designs). I also look at the issue reporter (creator) and think of any other relevant stakeholders who may be able to provide more input should I need it.

Question Time

Once I have checked that most of the usual information is available, I try to quickly generate as many questions as I can for myself to answer before starting the piece of work. In my experience, this helps to minimise the chance of missing or changing requirements later down the line while also forcing me to think about any possible scenarios we may have missed in the design phase. UX or behavioural questions can drastically effect the way in which I would implement certain features. It is especially important to find answers to these early (e.g. so that I know which Android components I should use to create certain behaviours).

Some examples of the design or behavioural related questions I try to ask myself are:

• What are the different states our UI can be in (such as loading, content, error)? Do we have designs for each of these? How do we transition from one state to another?
• If the issue contains multiple screens, do I know exactly how to navigate from one screen to the next? What happens when we interact with the controls (such as buttons) on screen?
• Does this have any overlap with or is it similar to any past work? Are there any reusable components we can utilise?

Before I describe the next phase of my thought process, I would like to point out that at Babylon, we implement each of our screens as a RecyclerView with a Groupie adapter on Android project. We use our own design system which consists of a number of useful UI elements such as buttons, cards and other views. You can read more about this design system here or by watching this talk by my colleague Maxime Mazzone.

What Are We Developing?

Now that we have discussed some of the general design questions I ask myself in order to plan and implement a ticket, we will discuss some issues which were specific to the feature I was implementing. You can find a sample of the designs I was given for this ticket in Figure 1 below:

Figure 1: Original phone widget design (designed by Daniel Spagnolo)

To give you some context, the designs in Figure 1 above are for an upcoming reusable, multi-screen feature called the ‘phone widget’. This was designed so that users can enter a phone number and choose from a list of country calling code prefixes (e.g. ‘+44’ for the United Kingdom), with the flag icon also representing the specified country code.

Some of the behaviour/intended UX that I knew of was:

• When the user taps on the country code area, this opens the country code picker screen, which has two sections. The first section displays the user’s current country code (see ‘current location’ in the above design). The second section allows them to select a new country code from a list.
• The first instance of each letter of the alphabet in the country code picker list should contain a header (e.g. ‘U’ for ‘United Kingdom).
• The user can click the search icon to search by country name for their chosen country.
• Once the user has selected a country code, the country code picker screen is closed and the phone widget is updated with the new country flag and prefix text.

Asking the Right Questions

So the above design looks like it would be effective — it looks like it is easy to use and communicates its intent and expectations clearly (and now that it has been implemented, I can say that it did work well — a great job by our designer Daniel Spagnolo!). However, upon seeing the initial designs (and quickly working through the general questions from earlier in the article), I still had many questions floating around in my head and some aspects I needed clarification on. Questions are a positive thing — it ensures that everybody on the team is on the same page in terms of intended design and behaviour. Asking the right questions allows both the developer and the designer to not only meet in the middle in terms of expected functionality, but may also uncover any behaviours that either party has forgotten about early on. Here are some examples of the feature-specific questions I asked our design team:

Question 1 — “On Android, we don’t seem to have the concept of a divider between every item in a list as seen in the designs. Should I implement it without the dividers?”

Figure 2: Original dividers

As you can see in Figure 2 above, the original designs for the country code picker screen had a grey divider between every row. We then consulted our existing Android design components and reviewing the Material Design guidelines on dividers which state “Don’t use dividers to separate individual items”. As a result, we updated the original design to remove the dividers and moved on — an easy fix and now we’re all on the same page about our design language going forward.

Question 2 — “Should the country code picker screen be a bottom sheet? As this follows convention with some other parts of the project.”

The reason I asked this question was because the original design of the country code picker screen (see Figure 1) looks as though it is a full-screen activity. I had noticed that other, similar picker screens had been implemented as bottom sheets in the project. This caused some dissonance in my mind and I decided to ask the question because consistency in our app is important. Luckily I did, because the picker was in fact intended to be implemented as a bottom sheet (Fragment). Asking questions like these not only affect the design, but also the implementation (e.g. we are now designing our code around a BottomSheetFragment rather than an Activity) which saves even more time later on!

Question 3 — “When the user hits the search icon, should the ‘current location’ section be hidden or kept in the list?”

Figure 3: country code picker in search state

The third question was related to the behaviour of the country code picker screen when the user is searching for a country. After viewing the original design (as seen in Figure 3 above), I noticed that the ‘current location’ section was missing. Now, this could easily have been a mistake or something omitted from the design. However, after speaking with the design team, I learned that the ‘current location’ section should disappear when the user clicks the ‘search’ icon (which makes a lot of sense — we want our search results to be front and centre as they are the most important thing in that moment). These are the types of UX or behavioural aspects of design that can often be missed when viewing static design images. As Google say when referencing Material Design, “motion provides meaning”. This sentiment can be applied to static design images because we often miss the subtleties and interactions with components (for example, how they should react and change due to some user action). In this case, it is always better to ask!

Question 4 — “ Is the ‘current location’ section on the country code picker intended to be ‘sticky’? So if we scroll through the countries in the list, the ‘current location’ section stays visible?”

To me, it wasn’t immediately clear from the designs (see Figure 1) which of the following was correct:

• The scrollable list of countries was supposed to be part of the same list as the ‘current location’ section (meaning that all content scrolls at once).
• The scrollable list of countries was separate (and the current location should be ‘stuck’ to the top of the screen while the countries scrolled independently).

While this wouldn’t influence the implementation time too much, it is still good to iron out these details before starting to code. It turned out that the ‘current location’ section would not be sticky and that everything would be in the same list. This made the implementation even quicker as each section is just another Groupie section in the adapter.

Question 5 — “Do we have any existing components for this pattern of showing a capital letter header for the first instance of each letter in the alphabet? I’m not sure if this pattern is already used somewhere in the app.”

In Figure 1, you can see how we use a header for the first instance of each letter of the alphabet (the ‘U’ next to the ‘United Kingdom’). I had a feeling I’d seen this pattern once before in the app but couldn’t picture where I’d seen it. After some discussion with the team on Slack, I found that it was used once on one of the registration screens, albeit in a slightly different form (the previous version used sticky headers, whereas my version would not be sticky and scroll off screen with the rest of the row). Due to this difference in functionality, I would need to plan how to implement this as part of our existing design system using Groupie Item rows.

In this case, while it was good to find out where the pattern was used previously, asking this question didn’t really help us with our implementation due to the difference in behaviour. That is just the nature of asking these questions — some of them will turn out to be incredibly useful while others may lead to a dead end. Yet they will all still result in some intangible benefits such as increased knowledge of the codebase and shared knowledge across the team. One lesson we can take away from this question is that if you’re in doubt, just ask your team — there is bound to be somebody with a more historical view of the codebase than yourself and somebody who can likely point you in the right direction.

Conclusion

In this article, we have discussed some of the ways in which asking questions can help your thought process when approaching the development of a feature while learning about some of the tools we use here at Babylon Health to help us with that journey.

While we have described a number of considerations we need to process, don’t feel overwhelmed as you can imagine how most of the decisions and questions stated in the article happen almost instantaneously in your mind once you gain an understanding of the feature you are implementing. There is also such a thing as asking too many questions — analysis paralysis is a real issue and can massively stall your progress if you’re not careful, so it is important to be thorough but efficient when working through this part of your process. Plan without overthinking everything.

Another thing to remember is that every piece of work is different. While the ideas in this article provide an effective framework for thinking about starting your work, there is no need to stick to it rigidly. Adapt and use parts of it accordingly depending on what you are implementing — just remember: always ask questions if you are unsure of anything.

In the next article, we will continue planning our implementation by taking the ideas and questions from above and start to translate them into a technical solution, so stay tuned!

At Babylon we believe it’s possible to put an accessible and affordable health service in the hands of every person on earth. The technology we use is at the heart and soul of that mission. Babylon is a Healthcare Platform, currently providing online consultations via in-app video and phone calls, AI-assisted Triage and Predictive Health Assistance.

If you are interested in helping us build the future of healthcare, please find our open roles here.

Follow Babylon Engineering on Twitter @Babylon_Eng and the author of this article @DarrenAtherton.