You might not think about the US FDA often, but their work touches nearly every part of your life. In this episode, J talks to Michael Jovel about how they’re using design thinking to make their digital products easier to use for everyone.
Michael Jovel is a Designer and Front-end Developer at the U.S. Food and Drug Administration and the lead on the Labcoat Design System. He also organizes the Defense Media Innovation Lab and the Bmoresponsive web conference.
J Cornelius: You might not think about the US Food and Drug Administration very often, but their work touches nearly every part of your life. Today, I'm talking to Michael about how they're using design thinking to make their digital products easier to use for everyone.
Voiceover: This is Design Driven, the podcast about using design thinking build great products and lasting companies. Whether you're running a startup or trying something new inside a Fortune 1000, the tools, methods and insights we talk about will help you create things people love. And now, your host, J.
J: Hey everyone. We're here today with Michael. He is a designer and front end developer at the US Food and Drug Administration. They have this lab coat design system, so we're gonna hear a little bit about that today. Michael, welcome to the show. How are you today?
Michael Jovel: I'm doing great. How about yourself?
J: Fantastic. It's sunny here in Atlanta, so I can't complain. We've had some off-hand weather over the past couple of days. It gets cold, then it gets hot, then it gets cold, then it gets hot. You never know what to do, but today is pretty nice.
J: So when I first heard about the FDA using a design system, I kind of scratched my head and I was thinking, "So, how are they using a design system, and what are they using it for?" Can you shed some light on what the FDA is doing, and what you are doing there to help it happen?
Michael: Sure, yeah. The idea behind a design system within the FDA started even before I joined FDA. I've been there about three years now. And basically, it was ... I'm trying to think, it was probably about five years ago when they were issuing a redesign to address mobile on the site. They were trying to iterate that in a very quick fashion. So they, like many developers and designers at the time, stumbled upon Bootstrap, and kind of figured that framework as a way to quickly create a new site look for FDA.
Michael: And with FDA and the way their content management system works, it proved a little bit of a challenge, like in many other organizations. Their site composes, obviously being a federal agency and being, quite frankly, a very large federal agency, having to manage look and feel across several sites and several pages, and across several completely not even co-located teams, became a pretty big challenge.
So where I came in, they had been using Bootstrap for a while. They had a couple written guidelines, and were kind of relying on this combination of some printed documentation on how to produce content using that amalgamation between Bootstrap and what they had created. And I, as a new user of their system, was kind of trying to adapt myself to it as well. So I kind of started to convert a lot of that documentation into more of an interactive style guide, if not ...
Michael: And working along that process, I built the first iteration of it, which was still, and probably much to it's detriment, heavily had my hand in it. So, I was pretty much the sole person who maintained that, so it quickly went by the wayside, because there were no other contributors or maintainers. Basically, if you needed a component, there was myself and actually one other person who would submit to it.
J: So it sounds like you started with Bootstrap, and Bootstrap is kind of the gateway drug for a lot of design systems, right? So you started with Bootstrap, and then you adapted it, and then ... So now, is it still based on Bootstrap, or have you rewritten it from the ground up? What's the current status?
Michael: So, I think I accidentally jumped over this, but one of the challenges that we have in our current system was that a lot of our content still isn't very structured. So even issuing things like redesigns, there's still a lot of presentational code inside of the WYSIWYG. So what was discovered is, obviously that made moving off of Bootstrap a challenge, because we had all of this nested class names and things like that, and custom functionality that even content contributors had added into the actual content itself.
Michael: So it made moving too much around quite a challenge. So right now, we're at a phase, and we're actually in the process of moving from a proprietary system that we have for our content management on main FDA.gov to another solution. And as part of that, we've been evaluating how to effectively start to maybe move our way off of Bootstrap, while creating like a migration path, and thus bridging that gap between things that aren't necessarily within the design system to those that are.
Because what we've found is that as people created content and were creating, essentially, their own custom UI inside of the WYSIWYG, it was quickly breaking down the system from within. And this is still an ongoing process. We run several inventories with the different contributing groups, and have tried to capture all of that information as to how they've customized UI across the board to try to create this cohesive UI or solutions via the system.
J: Yeah, it sounds like you've got what we see in a lot of large organizations. You've got a bunch of people trying to do the best they can with what they've been given, and you end up having a bunch of different solutions to the same problem. So now, it sounds like you're trying to standardize those solutions so that as you go forward, you're gonna have one solution to that problem or maybe a handful of things that are widely agreed upon. So it standardizes things across the entire site or family of sites. Is that accurate?
Michael: That is completely accurate, yes.
J: Great. So how far are you through that process? What have you seen so far in terms of efficiency gains, or what are people saying internally? It might also be helpful to understand, how big is your team?
Michael: So currently, our team ... And as per government, it's very disjointed. So, the team that I sit on currently is composed of two members, but then we also have the IT side of the house, which also has their own contracting mechanisms that they bring on, additional team members directly associated with the core team.
J: Sure. Are any of those people part of the digital service, or are you getting any help from 18F or any of those organizations?
Michael: We are not. We did participate in the creation of the US Web Design Standard, and that is definitely one of the avenues that we are currently trying to figure out how to best bridge that gap. Because the intent of the US Web Standards, it's something that we definitely agree with, and I think it's just, for us and where we are right now, we're just trying to figure out, like I said, trying to figure out how we move from that Legacy Bootstrap code, and how we move over, gracefully, into the web design standard as best we can.
J: Yeah, key word 'gracefully,' right?
Michael: Yeah. And in addition to that, obviously ... And my hats are completely off to them, I know what a challenge it is, because even within our agency, we recently had a rebrand. And even that was kind of a side-step that we've had to kind of take a pause to try to figure out how our newer visual identify impacts all of the components that we've built up over the last few years.
J: Yeah, I can imagine it's probably a lot with an organization of that size. You mentioned that you have multiple sites. Can you talk a little bit about the stakeholders, or who's the end user for each of those sites, and how much do you listen to them, or how do you listen to them, and how do you decide what you're going to build? And then, how do you measure if what you've built is actually an improvement?
Michael: Okay. So wow, that was a lot of depth.
J: Yeah, there was a lot in there. We could-
Michael: So, I'll start off with, yes, from stakeholders, obviously as I mentioned before, FDA does cover a lot of ground with regard to being a regulatory agency, in that we regulate anything from food products, to tobacco, to drugs and radiological emitting devices ... So, there is quite a large number, and different types of users. And for each of those, they can range from the users of industry who want to know how do they get their drug approved, how likely is it, what drugs that are similar to theirs that have been submitted for approval and may not have received approval, or to try and hedge their bets to figure out whether the drug will be approved or not before investing too much money in it ... Or, the simple person who wants to know if the peanut butter that they have in their cupboard is not gonna kill them.
J: Yeah, that's a pretty broad band of constituents.
Michael: Yeah, it can vary a lot by center, and our team isn't necessarily directly nested within any one of those groups. So we, on a project to project basis, kind of tend to connect with them to try and figure out how their user needs are best met.
J: Yeah, so what kind of research or what kind of tools are you doing to talk to them, to get that insight?
Michael: So, obviously being government, one, to some level they all have the budgeting and power to do the research themselves at times, but we also duplicate that effort at times. But, obviously like most organizations nowadays, we collect a wide gamut of metrics, whether it be just visitor traffic data, heat map ... We do usability testing from time to time, but usability testing tends to be a little bit more difficult in government for privacy reasons.
J: Oh, yeah, right.
Michael: We have the Paperwork Reduction Act, so a lot of those activities have to get approved. That can make it a little bit more challenging, to directly interface with the customer. So we don't do that as often as I would like.
J: Yeah, I bet. So I hadn't thought about all of the additional regulations and restrictions that you have to deal with being a government agency around how you collect research, and who you can talk to, and what kind of questions you can ask. I imagine that's a bit of a handicap, but you still have to prioritize things somehow. So, what's the thought process there? When you're thinking through what you're going to do, what kind of conversations are happening with you and the stakeholders internally, and with the rest of your team?
Michael: So, yeah. A lot of times what we'll do is, depending on what the project is, either the stakeholders may come to us and directly report the problem, or we, as I mentioned, we collect a variety of analytical data and surveys. And we tend to analyze those and go through and see if there are any continuous items that we see that several people are reporting within any of the product areas. And we'll then, generally, try to take a deeper dive into that specifically. So I think ultimately, the answer is, "It kind of depends."
J: Yeah, sure. That's the best answer for any UX question, right? It always depends on the context, and who the user is, and what problems they're trying to solve. So, when we think about how you measure whether or not what you're doing is actually having an impact, what kind of results are you looking for, and how are you measuring if you're achieving them?
Michael: All right. So, a lot of times if it is something that I would say is outward facing, we tend to... Just to simplify it, if we notice beforehand that we're receiving a number of complaints about whether a form for submission isn't working ... And we basically will look at that and measure how that data has changed over time, and compare at that point and see, ultimately, if the number is reduced in problems within that specific field.
J: Yeah, sure. So very direct, quantitative measurements?
J: Yeah. So, are you also measuring anything that's more qualitative, like customer satisfaction or anything along those lines?
Michael: When we have done it, we've done it via the surveys that have been highly targeted. And if we've rolled out a feature that lends itself a little bit more towards that qualitative, we've modified the surveys or targeted those specific users who use that functionality to see if we can get a little bit of a deeper feel for that.
J: Yeah, sure. So I'm wondering, how do you rate the overall satisfaction of the experience of dealing with the FDA? I'm sure that varies for stakeholder to stakeholder, but is that something that you're tracking? And if it is, how have you seen the use of these design systems have an effect on that?
Michael: So, I think that over time we have tracked it, and I feel like with the design systems, I think one of the things that they have improved is that consistency. And we find that in general, not only obviously on the development side where it's been saving time in rolling out solutions, but also just from the user's perspective of coming in and being able to, a little bit more "intuitively" figure out what the next step is.
Because today's person who may be submitting an application for, like I said, for drug approval, may be the same person who's coming back a week later to find out if the food they're eating is safe.
J: Yeah, right.
Michael: So having that consistency is incredibly valuable.
J: Yeah, because they don't have to relearn how to use one part of the site, because they learned it when they used the other part of the site, right?
J: Yeah. What about the developers themselves? Have they had any feedback on how using these repeatable design systems has impacted their work?
Michael: They definitely have. It's made development a lot quicker. And some of this is hearsay, but it's clearly understandable that even before when they rolled out Bootstrap, just having that documentation and that understanding of how to produce things that will behave across devices, and consistently not have to worry about the specifics of what the look and feel or behaviors of UI will be on every single page or section or site within our group definitely makes things a lot easier.
J: Yeah, of course. So, what's the roadmap? What are you doing next, and how do you see the design systems or the tools that you're building through those, how do you see those expanding, and what kind of impact do you expect that to have?
Michael: I think right now what the roadmap is, as I mentioned, our main overarching, our flagship FDA.gov is moving to a new system. And it's exciting, because I think we're looking at it, and this one of the first opportunities in a very long time that the agency has had to really deeply evaluate a lot of these things. So we're uncovering a lot of things, and really excited to move them forward and start to ... Even though we've had a consistent framework up to now, I think because it hasn't necessarily been as baked in as it will be in the future, I think that continuing in that direction is definitely exciting.
J: Yeah, I bet it is. I'm curious about, once you get to that point where you've released a bunch of new things and you're starting to see positive feedback roll in, where do you take it next?
Michael: I think one of the things that we're really excited about is just growing, maintaining it as a product in itself. As I mentioned before, having this large organization trying to make sure that it maintains its relevancy by having contributors from all of the different entities within FDA and making sure that it truly is meeting the needs, and evolving to meet all of the needs of all of the unique users across the organization. And more importantly, the users of all of our sites and applications across the organization.
J: Yeah, right? It's interesting, because most of the people we talk to are in the private sector, and they're running businesses, and the metrics that they're looking at are things like customer retention and satisfaction, and if they're more profitable, or if they're running more efficiently and saving costs. And some of those overlap with government I bet, but most of the business metrics you typically think of, like are you capturing more customers, or are you making more money, don't really apply. So what are the important things for the FDA?
Michael: I think, ultimately the most important things to us are making sure that the information that we have is out there, and is accessible in the best way possible, that people are arriving within FDA and are achieving their goal. And I know that's kind of vague, but as I mentioned before, depending on the scenario by why they're visiting, they could have completely different goals.
J: Right. Yeah, and I imagine that those goals can be really all over the place.
Michael: Yes. And that's the other thing that you get in one of these organizations is that, yeah, the goals from my time in the private sector, while we've had a few very targeted goals because of the different user bases for every single grouping within FDA, it's kind of hard to narrow it down to one thing.
J: Yeah, I bet. So, do you foresee the systems that you're working on growing larger than the FDA? Is that gonna contribute back to some of the digital service stuff, or is it gonna go to other organizations or departments?
Michael: Yeah. In this case, I'm more so speaking for myself. But what I would like to see happen is for us to be able to dovetail a lot more nicely into the US Web Design Standard, and become a contributor to that system. Because I think ultimately, yeah, I agree with their general goal of having that consistent UI so that whether someone is arriving to find out whether their visa application was approved or find out, like I said, if their food was safe, they have a consistent experience, and they have that consistent trust that they're on a federal site as opposed to someone who may have skimmed their site, to look like some kind of government entity.
J: Yeah, government sites, for decades, have notoriously been clunky and difficult to figure out. It's good to see that there's some attention being paid to that. You mentioned something earlier about accessibility. I know that's a huge thing for all government agencies, that they have to be accessible and comply with the standards. So, how have you seen the use of the design system make that compliance, or thinking about accessibility easier?
Michael: I think where it has helped ... Obviously as a government agency, it's something we take very seriously, and it's something that has, at least as long as I have been there, has been heavily audited to make sure that we are meeting those requirements. But, I think the larger portion of that is that the design systems are making ... Because they have them baked in, it has made it a lot easier for developers to consistently create different things that basically adhere to the standards without having to-
J: Without having to rethink it every time.
J: Yeah. It seems like the focus for designers and developers then is on solving the problem at hand instead of trying to re-engineer everything every single time that they're trying to fix something or create something new.
J: So when you think about working internally, what kind of improvements in communication or efficiency of development have you seen a design system make with the team there?
Michael: There has been, I've seen a lot of increase in efficiency. I think the main area ... And some of it is even just the communication that sometimes doesn't even need to happen, because you find that because the documentation is out there, a lot of the functionality can be rolled out a lot more ... Certainly, because like you mentioned, they've basically, by focusing on the problem, they're just essentially ... These individual design decisions have already been made for them.
Michael: And so many times, when communication does occur, it tends to be around maybe the problem itself not being solved. And then, you can address it from a problem perspective then, as opposed to specific code or UI, or something along those lines.
J: Right. So instead of having a meeting to figure out how you're going to design something, you're figuring out how you're actually going to solve the problem.
J: It sounds like it's been eliminating some meetings.
Michael: Yes, indeed.
J: Which I think everyone can agree is a good idea.
J: So, we're getting close on time. I don't want to take up too much of your time today, I appreciate you coming on the show. What would you ... Do you have any parting wisdom, or any other thoughts that you'd like to leave with the listeners?
Michael: Yeah. I think, ultimately ... And this one may not necessarily be completely relevant to the design system itself, but I would definitely recommend, if you're interested in looking into 18F or working for a government facility ... Or for a government organization, not facility, I would definitely recommend that. It's something that I have enjoyed, and I would say having that ability to truly make a difference within how services are delivered across the country has been something that has been extremely rewarding.
And to add another, I would just say for design systems. I would just recommend getting started with one within an organization. I think a lot times we see these great design systems that were built, and we kind of get intimidated. And I think just starting from where you are ... It's that first step and that second step to get you there, and before you know, you have a fully-fledged design system.
J: Right. Yeah, you've got to start somewhere.
J: Yep, that's good advice. So Michael, if somebody wanted to get in touch with you and hear more about what you're doing at the FDA or ask you some questions, what's the best way to reach out?
Michael: Sure. I am @mjovel on Twitter. That's probably the best way.
J: All right, cool, and we'll link that up in the show notes as well. So thanks for coming on today, I really appreciate you taking the time. I'd love to get you back on the show at some point and get an update on how things are working there at FDA, and maybe get some more insights into how using the design systems have improved things. And I don't know, maybe you've got some use cases we could talk about at some point.
Michael: Excellent, that sounds great.
J: Yeah, cool. So we'll connect on that, and thanks again for being on the show.
Michael: All right, thank you very much. Have a good one.
Outro: That's it for today. Thanks for listening to Design Driven. We're glad you enjoyed the show. Have comments, questions or an idea that you'd like us to cover? Point your browser to designdriven.biz and click 'Contact Us' on the top of your screen. We'd love to hear from you. Tell your friends and colleagues about the Design Driven pod. Post on Facebook, Twitter, LinkedIn, or send them an email, and tell them to go to designdriven.biz or wherever they find the podcast. Until next time, remember what Thomas Watson, founder of IBM said: "Good design is good business."
How can we help your company use great design to achieve its business goals?
Whatever you’re building, our workshops and project engagements can help you do it better. Reach out to discuss your project or request a quote.