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!