Quality Bits

Generic Design for Diverse Environments with Joe Cooper

• Season 2 • Episode 5

Share episode

DHIS2 is an open-source health system used in many countries. It's known for it's generic architecture and high customisability. How do you have a generic design for diverse environments and build a product that  helps save lives?

This episode's guest Joe Cooper is a designer working there for more than 7 years. We discuss the challenges of designing what actually matters, user satisfaction and user involvement, and humbling moments of realizing that our assumptions are wrong. As Joe notes in the episode: "I'm proud of not letting a design ego override important decisions. Sometimes that results in screenshots that are not as good for the portfolio. <..> The users don't need things that look better in my portfolio."

Find Joe on:

Mentions and resources:

If you liked this episode, you may as well enjoy this past episode of Quality Bits:
UX Research with Greta Ruskiene https://www.buzzsprout.com/2037134/12766870

Follow Quality Bits host Lina Zubyte on:

Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.

If you like this podcast and would like to support its making, feel free to buy me a coffee: https://www.buymeacoffee.com/linazubyte

Thank you for listening! ✨

Lina Zubyte (00:07):
Hi everyone. Welcome to Quality Bits, a podcast about building high quality products and teams. I'm your host, Lina Zubyte. This episode is a really special one to me. I'm talking to Joe Cooper, a product UX designer at DHIS2. DHIS2 is a product I get to work with currently. It's a very challenging product because it has a generic architecture but it's built for very diverse environments. It's used in countries around the world, a lot of them in conditions that many of us cannot even imagine. It challenged my idea of quality and I do believe that it challenged Joe's idea of UX as well. In this conversation we're talking about designing something that actually matters and changes lives. Enjoy this conversation.

(01:21):
Hello Joe. Welcome to Quality Bits. I'm very excited to have you here as my guest. Could you shortly introduce yourself?

Joe Cooper (01:30):
Thanks for having me. It's very kind. I'm Joe Cooper. I work on design at DHIS2 and I'm a product designer / design strategist / working on everything. So my specialty is software and product design. I tend to pick up tasks all over the place, write code, talk about things a lot, and I'm a father of two and renovating a house, so if I'm not at work, I'm working on the house, which presents a similar set of challenges but in a slightly different arena.

Lina Zubyte (02:14):
So we did meet working on DHIS2 and it is a really interesting product which has changed my perception on many things and areas. How would you describe it? What is it?

Joe Cooper (02:27):
That's a good question. The headline is the world's largest health information system. It's a great headline, but it's not necessarily that clear if you don't know about health information systems, but DHIS2 is basically a generic information collection, analysis and action tool. It's free, it's open source, it's used in over 80 countries for their health systems and over a hundred countries for other things like climate, education, logistics. So it's not just a health tool, it's considered a global public good, a digital tool that I suppose has changed the world in where it's used and that it's kind of enabled countries that otherwise might not have the resources to deploy this kind of health information system.

Lina Zubyte (03:26):
It's such an impactful mission and product. How is it different working for DHIS2 than it was working for other companies when it comes to your role and the work you do?

Joe Cooper (03:42):
Yeah, so the biggest difference I would say is the scale. There's a lot of differences in terms of comparing it to a consumer-led product or a revenue-driven product. It's completely different to that. Almost feels like the only similarity is it happens to be within the same kind of product world working on software because we don't have KPIs of people using our apps or download counts or reviews. The KPIs are really on the forefront of the health impact or the logistical impact. Our software is successful only in the sense that it enables those outcomes to be successful and I think then the software is kind of seen as it's a middleman to the actual work in a sense, whereas other products are sometimes the actual work itself and then the scale is the other difference. It's used in so many different countries all over the world with all different kinds of languages and I think that kind of huge scale makes it a very unique product with a unique set of challenges.

Lina Zubyte (04:58):
I feel like there's so much to do with this product, there's so many different areas and we absolutely can keep ourselves busy. What are some of the challenging areas that you are thinking about right now and trying to tackle?

Joe Cooper (05:16):
Yeah, I agree with you. There's plenty to focus on. An area that I'm particularly interested in now is trying to learn more about the people who are using DHIS2. We have a very wide extensive network of implementers, of people who set up DHIS2 in countries, of people who run the Ministry of Health for example, and we learn a lot from them about configuring health programs. We also have our own implementation teams at the University of Oslo where I'm based. So we learn a lot about the middle user set I might say, but the end user set, it's quite difficult to know them and it's quite difficult to know their particular day-to-day challenges that we would very much like to solve by improving the user experience and by building easy to use products, that's hard to do. It's hard to build up a picture of who they are. As we're open source and free, we have no built-in telemetry or analytics, so we don't know who's using DHIS2 apart from if they tell us. So that challenging area for me as a product designer and a UX designer, your work is often rooted in user research and knowing your user and not knowing them or not knowing who they are or where they are is a particular challenge that I'm trying to solve now.

Lina Zubyte (06:46):
How are you trying to solve it? What's your plan?

Joe Cooper (06:52):
That's a great question and it's still pending, but together with the rest of the team, we're talking about how to best implement an open friendly privacy concern telemetry system where totally opt-in where instances of DHIS2 can send information back to us that we would find useful if they want to help us to improve the product. I think open source software has kind of a complicated relationship with telemetry, so it's something that we really want to tread lightly and make sure that we don't have any kind of unreasonable defaults or anything around there. So that's more about technically understanding our users and perhaps what technical frustrations they might have when they're actually using the apps and how they might, the user experience might suffer technically, but also we need to find out more about how our users understand the product conceptually in order to build apps and experiences for them that makes sense in their conceptual model of what they might be doing. So it's kind of a two-pronged approach, really a technical approach of open source telemetry and then a people first approach where basically just trying to get as much time with people who actually use our software as possible and that involves traveling and lots of zoom meetings and just trying to build up those relationships really. It's hard cause it doesn't scale that well though.

Lina Zubyte (08:39):
Open source in general has so many assumptions, so even thinking about what is the essential path or use case, we don't really know. For me also from the quality perspective, very often we speak, okay, what is the critical journey? What should we cover? And we're like, no idea. So there's lots of assumptions that we make. From your experience, have you had any assumptions at first you were like, oh yeah, that's definitely this, but then it turns out it was wrong so you were proven wrong working on the product and you're like, okay, no, that is not the challenge we should be solving even?

Joe Cooper (09:17):
Plenty. I think one I just touched on a bit actually was, I mean there's certainly plenty to talk about in terms of specific UI components or how a screen was laid out that wasn't quite right. As I said, we don't get that much of that type of feedback because we have limited contact with our end users. But an interesting overarching assumption I had was that the users of DHIS2 understood the platform in the same way that I did. So they understood it as a platform upon which they had some apps they could open them and do their work and so on. I assumed there's kind of a similar foundational understanding, but talking to people who actually do use it, they don't necessarily have a concept of an app or a platform and maybe they just called it my vaccine register or they called it my malaria tables and I was relying at times on this assumption that everyone would know what an app was, they might know what settings were and if something doesn't work for me here, I can go to the app settings to fix it.

(10:35):
I think understanding that that's not even an assumption you can make helps you to build more inclusive experiences because those assumptions manifest in so many different places. If you make the assumption that everyone is working on that same app driven model for example, that might manifest in how you organize your documentation. Therefore someone who doesn't really have that same app model might struggle to find help when they're browsing the documentation. So I feel that that kind of foundational assumption was good to get corrected because now we can start to think about perhaps people see it more as, for example, grouping into a collecting data, I'm analyzing data or I'm outputting data. In those three buckets. Maybe that's how they view that work rather than the 52 different apps that I tend to carry around in the back of my head.

Lina Zubyte (11:33):
Yeah, I think we may think, okay, this is how the product is used, but we can learn so many of use cases where it's not like that at all. And I remember speaking to some developers of DHIS2 and they were saying that it's a completely different setup to be there on the field and to talk to the people who basically they need to enter some data, they don't care if it's microservices, they don't care if it's like some shiny amazing architecture and the best engineering practices. And I remember how we sat in the office and there was this picture of a woman in the street surrounded by many people in the traffic with a notebook and you said sometimes you just need to write it down. So does it matter for this woman that it's a beautiful UX design? So talking about situations like this when we need a quick fix, like a dirty fix sometimes. How much UX matters in these cases? What are your thoughts?

Joe Cooper (12:39):
It's a difficult question to answer because I think I've seen the impact of poor user experience and it can turn a situation on its head and result in bad data. It can result in bad actions from bad data because someone struggled to input data in the form over a long time. It wasn't necessarily picked up for example. But I think it's important to be realistic about the impact of user experience on those critical situations and I think users of open source, they deserve good user experiences. It's not just consumer apps where we should be spending that time. I'm quite passionate about that, but I think it's important to resist the urge to lump all of the products into that critical user experience bucket. I think actual data use and health outcomes they need to overrule delight. We might say. It would be great to get to delight and it would be great if users in that clinic were enjoying using the product, but I think we need to be realistic about what we're trying to achieve here and we're therefore for me, I'm thinking that in a situation like the one you described, a good user experience, there is one that is reliable and is one that doesn't cause any more stress than already is there.

(14:12):
And I think here is a good area we can say that if we can make a good user experience the default, the path of least resistance, then hopefully we don't have to choose between shipping quickly to fix a problem and shipping a good user experience because the default that we build has a baseline of a good UX.

Lina Zubyte (14:39):
I think it definitely can help out having also good UX and, from my side, quality, not a buggy software. It really made me think this product, it challenged me quite a bit because of the things that actually matter, what actually matters here. If people want something reliable, does it matter that there's some minor bug that I'm annoyed by because I just see that visually it doesn't look perfect. Does it matter? Maybe not that much. Another aspect here is that we may be in western privileged countries and may not even imagine the things that people are dealing with and as you said, the stress of whatever is going on in your life and in some cultures there could be a lot of things going on and there's political situations as well. There's crisises that we have no idea about, so eventually learn this and to be like, okay, I'm completely not like my user, I don't know what's going on. So me saying that, okay, I think the best would be this. I have no idea what's the best. So for me that was a very big challenge.

Joe Cooper (15:58):
Yeah, I think there is perhaps an objective, positive user experience that we can agree on and an objective standard of quality, it doesn't break, it does what I expect it to do and it otherwise gets out with my way. If we have that as a minimum standard, then everything on top should hopefully be even better.

Lina Zubyte (16:22):
What about perceived quality? Because reliability sometimes could look ugly. Perceived quality could be, oh, I have this smooth app design and I may think, oh, this is definitely nice and it should be working fine. And we may be fooled by that. Working with product like this as a designer, what are you thinking about it? What fools you? Is there an example that you're like, okay, this looks like good quality, what looks like good quality to you after you see examples for maybe it's not about pixel perfect design?

Joe Cooper (17:01):
I think that kind of shiny pixel perfect good looking stuff can fool you into expecting things to work. I live in Norway where there's a tradition of good design and services here, digital services as well as physical from my experience are well designed. They have good principles and I like it a lot. I do find that at times there are, especially when it comes to banks, I'm happy to send an open call to the Norwegian bank software and services that those shiny interfaces are very much only handling the expected data as an immigrant to Norway, when I don't necessarily have the same ID number or I don't necessarily have the same setup with my data, you have to end up on the phone a lot because the interface just will spin forever. For example, my personal ID number doesn't match the pattern that's expected, therefore something doesn't load, therefore I never actually see that shiny interface.

(18:18):
So for me, I am all for shiny good, smooth, snappy interfaces, but I think that has to come after we address all of the edge. I don't want to call them edge cases. I don't feel like an edge case myself. So it has to come after we address all of the use cases and you can easily fool yourself into thinking that the data will be nice or that the data will exist or that the data won't be malformed or all of those things. And we shouldn't punish people who have missing data with a poor user experience that's unfair. We shouldn't, shouldn't punish people who perhaps don't have the same string length that we're expecting or maybe their language goes right to left instead of left to right and all of those things, in my opinion, they really need to come before we start adding any kind of fancy polish because that's the quality is at the core there and the core needs to not just be so narrowly focused on one subset of experiences.

Lina Zubyte (19:35):
That's such a good example on why diversity is important and how sometimes we may put things to boxes because it's very natural, so whomever is making the system for Norwegian bank, they may think, okay, everyone is like me. And then even the importance of having diverse team so that there would be someone saying, Hey, actually this doesn't work for me.

(19:58):
And the fact that having generic design by architecture and the generic architecture of DHIS2 makes it very customizable, which also means sometimes balancing these things... I could limit and validate this field should be certain format which this Norwegian bank system could do. But on another hand, is that the only use case? It's such a challenging situation to be in because on the one hand you're making it more secure, less error prone, but you may be closing the doors for so many people who are different than you are. For me also as an expat, I have a special accent on the end of my surname. Sometimes people get very creative, they change it to a different special accent and they cannot even find me in the system. I would be fine if they just drop it, but it happens so often that I'm also not in the system or something is not working exactly like it should be or being an expat in a country. And then most of the movies are dubbed in a different language and you cannot even purchase a movie with original language or English subtitles or dubbed in English and it's like, I would pay money, I would, but I cannot do it. It's so frustrating.

Joe Cooper (21:24):
Yeah, absolutely. To attempt to put myself in the shoes of someone who is in rural Africa working with our software and their experience, which is totally normal to them, somehow hasn't not something that we've thought of and therefore the software is just showing them kind of an immovable error with no way around it. That kind of thing keeps me awake at night.

Lina Zubyte (21:55):
Yeah, I think for me this project is really a humbling experience because I thought I am open-minded and I hope I am open-minded, but we still have certain expectations or we may bring other assumptions and there's so many different people, different use cases who are very different than you and they have to be heard. And sometimes it's the opposite of what we are hoping for. The answers we may get are not somehow aligning with our expectations and that's okay. And to understand someone's daily life in a completely different country, it's challenging because even for example, internet conditions, this is one of the things that we don't second guess in the countries we are in. And for DHIS2, it's important to support offline mode and it's important to even have SMS function because people go to the field and they may need to record data where also there may be no network. And to even imagine this sometimes it's like, wow, what? Does it happen right now? Yes, it does. So it's really challenging.

Joe Cooper (23:11):
Absolutely. We hear, see lots of examples and we hear lots about countries that are still shipping USB drives around because that's faster than any kind of network that is the network and we have to support that. We have to make sure that our export functionality supports that way of working because not everyone has a fiber line to connect to. The interesting thing here is from a user experience perspective is that I suppose this is where I think a lot about scale and that I could spend many, many years interviewing everyone who uses DHIS2. Well that's definitely not everyone. I could spend many years interviewing some of the people who use DHIS2 and I would find out very different things about their needs and what constitutes a good user experience or what constitutes a powerful software platform for them. And when we have user needs that are that diverse at that scale, I think that's really where we have to change our way of working from a more traditional collect user needs, build an app, ship the app to where I feel I'm working now as more of a attempting to build, to facilitate a good software experiences by building in, it sounds so abstract, but building in ways for people to make the software more locally relevant.

(24:51):
Because at our scale we are not able to do that and oftentimes people will end up having to adapt to us because we are the ones who set the standard, but to find that middle ground where we set a reasonable standard, but we make it infinitely flexible at the local level, I think that is really the only way to build quality products at scale.

Lina Zubyte (25:17):
So user satisfaction versus user involvement. Is it possible to make a good design with limited user involvement?

Joe Cooper (25:28):
I think it depends where the user involvement comes. I think it's possible to make a good design with limited user involvement upfront, but a lot of user involvement after the fact, by which I mean customization of your own experience and being able, whether that's the end user themselves or perhaps the person who configures the system, the ability for them to change what they see or change the patterns of the software. And I think certainly a long way to go before this becomes smart enough, but this is where technology can potentially help us because the technology could detect patterns of how people use the software and adapt to that. I suppose quite limited versions are just remembering the last 10 objects you interacted with and offering a quick way to get back to those small tweaks that mean that a completely generic system can actually feel personal without a ton of user involvement in the development process. I think all of this relies on very much a really solid foundation of quality software that adapts to the or it's built upon well-known well-tested software interfaces, things that are not trying to reinvent the wheel, for example. I think once you have that, then upon that you can build a layer of customization that makes it more useful for individuals.

Lina Zubyte (27:10):
How do you deal with the fact that the product may have been used for multiple years and people are used to certain experience and then you want to change something because it's not actually a good user experience. How can this change happen? Should it happen as well, and how can you show the users that this is actually a better way, this could help them?

Joe Cooper (27:35):
I mean that is a totally an unsolved problem for me. I find that it's hard because when a software product has become so important to countries, it's used as a national health system in many countries and it's the backbone for their health sector to make even what I might think are superficial changes to an app or to an experience can have long ranging consequences of if that button is no longer where it was before, people might be using the software who don't necessarily understand it beyond there is a button in the top right corner that I have to click when I am finished filling out this form. If I choose to move that button because by some UX principle or another, it belongs at the bottom that has consequences. So for me, I do try to weigh up the impact to existing users, but also recognizing that we have a constant influx of new users and that they are important too.

(28:45):
So the software works for existing users doesn't mean we should force everyone to learn something that we know is hard to learn or that they may have gotten used to it over the last decade. That's not a good enough reason to subject everyone to that decade of pain. So right now, that's one of the areas I'm working on, trying to find ways to make that transition easier in different ways. When we have a complete design overhaul of an app, we've tried to maintain certain patterns or maintain certain labels or signifiers like colors or iconography, maintaining where we can make those compromises of, okay, this icon is, maybe it's not the icon I would choose if I was going to start fresh, but maybe we could keep the icon. So in the example I gave though the button has moved to the top to the bottom, it still has the same icon.

(29:45):
So when I'm looking around, at least I've found it now and I think that's like a constant balance, which if you're not careful, can end up in a bit of a mess. So I like to think that each app has its own sort of mission statement and to constantly try to come back to that to make sure we're trying to, for example, make it easy to collect data in bulk, as long as the experience is still kind of focused on that mission statement, then ideally we won't stray too far from that. And even if it does end up being a big change, then at least we'll be able to say it was worth it because we've made it easier to get to this mission that we all agree is the main purpose.

Lina Zubyte (30:32):
I like that it's a gradual change that people are used to certain things and then we can somehow teach them or support them in this change that it's not just like, oh, we don't care, but no, we're thinking about you. We know how you're using this product and this is why we first start small and then maybe we change step by step. So working with DHIS2 has lots of interesting areas to work with. Looking back, what are you proud of? What are some of the challenges that you managed to solve and you're like, yeah, this was a good thing that it happened.

Joe Cooper (31:11):
I think I'm proud of working sustainably for so long, seven years now working as one of the only, if not the only designer on this project. And so I'm proud of not burning out on it. I'm proud of not letting a design ego override important decisions. Sometimes that results in screenshots that are not as good for the portfolio. I'm proud of putting the actual needs of users first and sometimes the users don't need things that look better in my portfolio. Well, they never do actually. And I think I'm proud of that. Kept that in mind and not gotten too caught up in the details of, well, this app looks a bit clunky or it looks a bit nineties in and of itself. That's not a good enough reason now for me to suggest redesigning. If it's working for people out in the field, then let's keep it.

(32:16):
I say, and then, yeah, I suppose specifically I'm proud of building with the team ways for other people to build upon our platform. So we are continually trying to find ways to facilitate external developers to build on DHIS2 with good user experiences. So to do that, we're trying to offer the component libraries that offer a good user experience out of the box tool kits that provide quick ways to get up and running with good quality software. And so I think I'm proud of turning out gaze outward to make sure we're trying to bring everyone along for the ride.

Lina Zubyte (33:04):
That's a very inspiring message. And yeah, just thinking about what matters rather than what is for my ego of my profession. It beats the consumerism capitalist world a little bit. It challenges it and it's really hard I think, to stand up against this because the society may lead us a certain way. So to wrap up this conversation and the topics we've touched on here, what is the one piece of advice you would have for building high quality products and teams?

Joe Cooper (33:41):
The one piece of advice would be the only thing that matters is what you ship. The only thing that matters is what gets into the hands of your users, whether that's delivered on a USB drive or whether they download it and install it themselves and have to go through a bunch of troubleshooting steps along the way. I think we can have the best of intentions and we can have a lot of great planning and a lot of great documents and specifications and mockups, but the only thing that matters is what is in the end user's hands at the end of the day. And I think it's important to follow the process and make sure that there's quality at every step of the way, and that it's not just that we have bug free software or it's not just that we have ticked all of our UX boxes, it's that the installation process was great too, and the follow-up process is great, and that if something does inevitably go wrong, that they know what to do at that point. So those are actually two bits of advice.

Lina Zubyte (34:55):
Wonderful. Thank you so much, Joe, for your time and inspiring thoughts.

Joe Cooper (35:00):
Thank you very much for having me.

Lina Zubyte (35:02):
That's it for today's episode. Thank you so much for listening. If you enjoyed this episode, let me know what you thought of it and provide me some feedback. I'd love to hear from you. And until the next time, do not forget to continue caring about and building those high quality products and teams. Bye.


People on this episode

Head Shot

Lina Zubyte

Host