Have you ever wondered how design systems are used within a government? Also, if you’d want to document a design system the best way you could, how would you do it? I spoke to Design Systems advocate, Amy Hupe, who shares her advice and lessons learned.
Show Notes
Weekly Update
Transcript
Drew McLellan: She’s a Content Specialist and Design Systems Advocate who spent the last three years working as Senior Content Designer at the Government Digital Service. In that time, she’s led content strategy for the GOV.UK design system, including a straightforward and inclusive approach to documentation. She’s previously worked for consumer advocacy company, Which? where she wrote about everything from composting to conveyancing. And a new role for 2020 sees her take up as Project Manager for Babylon Health Design System, DNA.
Drew: She’s a skilled cook, an Instagrammer, and knows how to use language to make services accessible and inclusive. But did you know she once sang backing vocals for Billy Ray Cyrus? My smashing friends, please welcome Amy Hupe. Hello Amy. How are you?
Amy Hupe: I am smashing. Thank you.
Drew: So I wanted to talk to you today about the role of design systems within government organizations generally, but specifically the GOV.UK design system, which I know you’ve done a lot of work with. I guess first of all, what does the GOV.UK design system encompass? And what was your involvement with it while you were at GDS?
Amy: So it encompasses all kinds of things. So I think the most obvious representation of it is the kind of website side, which is GOV.UK/design-system. And there you’ll find all of the kind of documentation. So all of the design guidelines, and the components and patterns, and you’ll see some of the code, lots of examples and lots of advice on how to use it. But thinking kind of more broadly than that, it also encompasses things like the prototype kit, which is a prototyping tool that is used in government to make HTML and CSS prototypes. So quite high fidelity prototypes and it also has its own kind of front end framework, which is called GOV.UK Front End. So that’s all the code that they use to build the services.
Amy: But then I like to think of design systems more holistically. So as well as all of that stuff, there’s also all the processes that sit around it. So things like how people contribute to it and how people come to know that it exists. Things like adoption and awareness and all that sort of stuff. So all of the things that enable people to design and build services in government is how I would define it.
Drew: So what was your involvement while you were at GDS with that? Where did you slot into that system?
Amy: It all kind of happened by chance, I guess. So I joined as a content designer in January 2017, and my intention when I came to GDS was actually to join the Gov UK content teams. So I thought I was going in to start writing guidance for system, and that was my dream. That was what I wanted to do. Then I arrived on day one and got plunked into this little protect team, called the Service Manual Patterns and Tools team.
Amy: At that point the design system didn’t exist, but we had our design patterns and some bits and pieces knocking about in different places. There was an ambition to try and pull those things together. So I was put into that team as a content designer. I didn’t know what a design pattern was, didn’t know anything about code, didn’t know anything really about web design at all. All I really knew was content.
Amy: So it was a pretty steep learning curve and I spent the next six months to a year, I think, helping the team to prototype it and figure out how it would be organized and laid out and how we would write our guidance, and all that sort of stuff. Then, in the midst of all of that as well as working on the content, I also started to look into the contribution side. So how people would contribute to it and how people would come to discover it and, get in touch with us, and what we would do when they did get in touch with us to try and make it better.
Drew: So what does designing content in that sort of context to be involve? What were the sort of daily tasks you were tackling?
Amy: So all kinds of things really. I mean there were weeks at a time I think where I didn’t write a single word and it was more just going out to research and meeting our users and try sort of understand what it was that they wanted from a design system. So yeah, without getting too far into it, there had been attempts to make something like the GOV.UK design system before, which is how we ended up with this kind of slightly disparate set of resources.
Amy: For one reason or another, these things ended up quite spread out, and it was never really one of them that was seen as the central place to go for this stuff. So a lot of it, it was just trying to understand what had happened before and why those things hadn’t necessarily taken off in the way that we had hoped that they would. Trying to understand which bits of our existing landscape were working for people and which bits weren’t.
Amy: So a lot of it was going out with our research [inaudible 00:05:07], and sitting in user research interviews, and taking notes and talking to people, and just understanding what it was that they needed. Then there were days where I did actually get to sit at a keyboard and write some guidance about some stuff, which was nice too. But yeah, it was very different for me. As you mentioned in the intro, my background was working at Which? So it was much more a traditional editorial role and I was used to working on long form content, and just writing really long articles, and pieces. So yeah, it was quite a big change. It was a big leap from that.
Drew: So your users in this context are people who are working in different government organizations? Is that right? Different departments within the government?
Amy: Yeah. Yeah, that’s right. So people working in, I think there’s 25 different ministerial departments in government, and then there’s lots of agencies and local government departments as well. So we were trying to spread out and talk to a really wide range of people from across the civil service. So yeah, lots of traveling in those early days.
Drew: Do you think that designing or working on a design system for a government, essentially, is any different from a design system for a small company or a big sort of enterprise company?
Amy: I think so. I mean I think from what I can kind of gather from conversations I’ve had, and conferences I’ve been to and stuff, every design system is slightly different and the context is always slightly different, and government is no different in that respect. But yeah, I suppose some of the unique challenges to working on something for government, is first of all the scale of it. So the audience is probably the biggest that you could have because government is so big, and all the different kinds of departments and the geographical spread of those organizations. So the scale of it is definitely something that’s slightly different.
Amy: I think also the fact that it’s not commercially competitive. So we weren’t trying to keep everything under wraps. Everything was done in the open as far as possible. Yeah, it’s all run as a big open source project, which was a slightly unusual concept for me. It took me a little while to get used to that.
Amy: Certainly when we first released it, we would see bits of our guidance and code popping up in other people’s design systems. It took a little while for me to feel all right about that. I think at first I was like, “What’s going on? Why are these people taking our stuff?” But actually now, I really like that. I see that as a big compliment, and I think it’s really good to reuse what you can. But yeah, that’s a strange kind of world to enter when you’ve been used to working in a more commercial setting, I guess.
Drew: I suppose the fact that it’s a essentially publicly funded system, means that is uniquely suited to the public taking it and using it, but also worldwide did you see a lot of use outside of the UK?
Amy: Yeah, yeah, there’s been some really exciting projects across the world that have picked it up. So I know that the New Zealand government have used quite a lot of it. I’m not sure what stage they’re at the moment, but certainly I saw their early data design system and they really used a lot of our guidance and our code, our layouts and things. I think the Dutch government is also using the GOV.UK design system primarily as its first proof of concept. The Australian government started with all of our contribution guidelines and have sort of adapted them based on their research. So we’ve been able to take some of that stuff back in. Yeah, so it’s gone pretty global. It’s exciting.
Drew: Would you factor in the fact that people would be using it when making decisions about the sort of next phase of things? Would it factor into your decisions that it’s actually your audience suddenly isn’t just UK government, it actually could potentially be a worldwide audience?
Amy: It’s definitely a consideration and I think at times that definitely made us as a team quite nervous about certain things that we were doing because the our audience and the scope of it suddenly got much bigger when we were thinking about all the different people that were using it. But personally I think you can’t get too caught up in that primarily we are there to serve the UK government. So it’s not practical to consider all of the potential audiences for it. I kind of think it’s up to the teams to adapt it how they need to for their own, their own users. But yeah, definitely it does make you think quite carefully about just throwing things out there before they’re kind of ready tested and stuff.
Drew: So were there any other sort of surprises in working on this design system other than the fact that it was then taken and used more broadly than you’d initially expected? Did anything else spring out and surprise you about it?
Amy: One thing that definitely stood out to me was the range of people in our audience. So not just the size of the audience, but like the variation in people’s level of knowledge, their skills, their confidence, the different kinds of jobs that they did and the kind of contexts in which they were working. I think there’s definitely a lot of variation in there. I think my perception going in was that I had this vision of this like designer front end developer in my head, somebody who has lots of technical knowledge and actually that’s just one type of user. There are lots of other people like content designers and things weren’t necessarily an expected audience for it, but have turned out to be key users.
Amy: So I think, yeah, that that was definitely a surprise to me. Then thinking about how we could cater to all those people with such a broad set of needs with the design system was definitely quite a big challenge. Yeah, I think that was probably my biggest surprise. Then I guess alongside that just how much people had seen to adopt it as their own. So I think after we launched pretty quickly, I was really pleasantly surprised at how many people I would see going out on advocating for it within their own departments and teams and people trying to contribute to it and people getting in touch with us to ask how they could kind of adapt it for their own users. It felt really community owned from day one and that was not necessarily something I expected, but something that was ready really good to see.
Drew: I guess much of the role of a design system is as a way of sort of documenting the design decisions that have been made so that those decisions can be then implemented and understood, and used by people. So I guess a design system is as much as anything, a documentation artifact isn’t it? It’s taking those decisions that have been made and explaining them in a way that people can reuse them. How did you approach as a team they design system as a sort of documentation artifact? How did you document what you were doing?
Amy: So I think it was about getting as much as we could get in a really clear picture of what people needed from that documentation. So this comes back to that point that I made about it being quite a broad reaching audience because there’s a whole range of different needs that people talk about documenting a component or a pattern like it’s a kind of single task. But actually there are loads of different ways that you can do that and there are loads of different needs that you need to take into consideration. So we have people who, for example would just, they would say, “Oh I want to see the research behind this.” For some people that means a number. They want to know that it’s being used in 20 different services so that they can tell their product manager that it’s worth investing the time and the money in implementing it within their service.
Amy: And that’s for them it’s just about getting that evidence-based backing for the decision that they’re trying to kind of push through. But then there’s other people who really care about understanding the research and whether it’s appropriate for their context and what additional research they might need to fill in to fill any gaps that have been missed or perhaps that they are dealing with in their unique situation. So I think the approach was to try and understand all of those different needs and to try and get a sense of priority amongst those and understand like how we could cater to all of the various different requirements that people had from the documentation. It’s not just one kind of one thing that fits everybody.
Amy: So figuring out how to kind of address all of those needs and to signpost the content really well in a way that meant that people could skip over the bits that weren’t relevant for them as well. Because when you are trying to serve such a broad audience, obviously you end up providing quite a lot of information. So making sure it’s really well signposted and organized I think was quite key to what we were doing.
Drew: So am I right in understanding that different departments within the government aren’t actually compelled to adopt the design system? You actually have to effectively sell it into them and persuade them to use it?
Amy: Yeah, so it’s slightly complicated. So in government there’s something called the government service standard and it’s a standard which all government services with over a certain number of users are required to meet in order to get funding and then to go into Alpha and then Beta and then live. One of the points on the service standard ,I left three weeks ago and it’s already dropped out of my head to which number it is, but one of the points of the service standard, it talks about reusing patterns and components and trying to reuse what’s there already. So sort of under that point they are compelled to use it, but it’s loose and it depends on who the assessor is. It’s not sort of heavily mandated. We would all always sort of advocate for doing what’s best in the specific context rather than just reusing patterns out of the box for the sake of it to tick a point on a service assessment. So it’s difficult to force it. So the approach was always much more collaborative and it was always about building support and building advocacy for the design system not shoving it down people’s throats.
Drew: I guess to that end, one of the ways that you’ve managed to do that is by encouraging contribution. Is that right?
Amy: Yeah, definitely. So I’m a big fan of contribution to design systems. I think it’s something that’s really interesting and yeah, certainly in the team we did a lot of work to make it possible to contribute to the GOV.UK design system. One of the real kind of benefits that we saw from that was The net advocates for the design system increasing. So when you get somebody to contribute to it and they then feel kind of more invested in it and what we received, those people would then go out to their teams and they would become our best sales people almost because they’d feel like they had a little piece of it and they had sort of something to show people and they would then encourage more people to contribute. So that effect ends up being quite exponential. Yeah. So we put a lot of effort into making that possible.
Drew: What sort of things did you do to encourage contribution?
Amy: We started really early. So way before we had a public design system, we started to engage with people who we thought would be interested contributors. I should mention here, we had a brilliant service designer on the team. She joined us in, I’m not going to get the dates correct in any way at the moment, but I think she worked with us in the whole of sort of 2018 and her name’s Ignatia and she just did a fantastic job of going around and engaging people. So one of the things that she did was to go and identify all of the different patterns in government and all of the different variations of those patterns. So going out and kind of saying, okay, there’s, there’s 10 different ways to ask for an address in government. Let’s look at them all together and decide which we think is the most appropriate approach.
Amy: How can we consolidate these into one? She ran a big workshop to try and get people looking at those and doing that kind of consolidation as a team. I think definitely her approach to building collaboration in way before we actually released anything to the public really helped with that because it meant that people already have that kind of awareness of it and many people had already contributed to it in some fashion or another before we actually took it public. So put us a few steps ahead. So I think that was really important. And just persistence, like a lot of persistence from the whole team in kind of helping people to contribute. I think there’s an idea that if you get people to contribute to a design system that’s a pretty sweet gig cause you can just get people to do all the work for you.
Amy: And you just sit there and you make your level code fixes and everybody’s actually giving you all the good stuff. But actually as anyone who’s worked on a design system will know, it’s incredibly complex. It’s very difficult to make a centralized solution that works for multiple different teams, and really, unless you’ve worked on a design system, it’s not reasonable to expect anyone to really understand what that takes. So there’s a lot of hand holding. There’s a lot of work involved in supporting contributors to contribute, I think I said this before, but it probably takes longer, I think, to help somebody to contribute to a design system then it would to just make the thing yourself in the centralized team. But I think recognizing the value that it brings and being persistent in your efforts to make people aware of contribution and help them to do it, help them to feel kind of motivated to do it. I think, yeah, that that persistence was really sort of key to our, our success in that area.
Drew: And just practically speaking with managing those contributions from the community, were there any tools or processes or anything that helped with that?
Amy: Yeah, so we had quite a strict process, I would say. Strict in so far as maybe, strict is the wrong word, comprehensive is probably a better word. So yeah, we have a set of contribution criteria which are in the design system. So everything’s as open as possible so people know what to expect. So there’s a set of criteria that we developed with the various people from the government community outside of our team, so again, like trying to involve people in the creation of these processes I think is really important. So there’s a set of criteria that all contributions to the design system have to meet and to make sure that we were being fairly unbiased, I suppose, and fair in terms of making the decisions about whether things met those criteria or not, we enlisted the support of a working group, which was a panel of representatives from across government. All from kind of different departments and different disciplines and people with different levels of seniority.
Amy: So everybody would have a slightly different perspective on the contributions and we would get together with them once a month and ask them to review any new contributions and decide whether or not they had met the criteria. So yeah, it was a sort of process designed to try and democratize the design of the design system I suppose, and to make it representative and ensure that it wasn’t just our team sitting in the middle making all the decisions without really understanding how it would affect the teams using those things.
Amy: Yeah, that was our sort of process. One more post I should mention is there’s a community backlog on GitHub, which anybody can use it. You don’t have to work in government to go and see it. It’s accessible from the design system and it’s basically a place where we try to host all of the research and all of the experimental stuff and the examples that go into their components and patterns in the design system. So again, it’s about pushing for that transparency and working in the open as much as possible so that people can have a voice and they can influence things before they’ve actually been published.
Drew: And do you think that process has worked well? If you were embarking on the same thing again, do you think you’d adopt a similar process or is there anything that didn’t work?
Amy: I think I would adopt a similar process but perhaps go into with slightly different expectations. What I would say is maybe slightly more realistic expectations and having said what I said about how we think that contributing will make things easier and faster. I was definitely in that camp. I think I thought that there would be a spike of work in the beginning to get people familiar with contributing and then over time we’d be able to be more hands off and people would just get the hang of it and it would be fine. But actually that never really materialized. There was always a lot of work involved in helping people to contribute and as I say, I think that that’s sort of to be expected. I don’t think you can really get away from that, but I still think it’s valuable.
Amy: I still think it’s worth investing that time, but perhaps not with an idea that you’re going to speed things up or that you’re going to be able to scale quicker or more from having contribution. So yeah, I think the process worked well. I do think it needs to be tailored to different organizations, so I’m starting a new role on Monday funnily enough, I’m working on another design system and I don’t expect to be able to pick up that process and just move it over there. I think everything has to be tailored to the organization and the context that you’re dealing with, but there’s definitely elements of it that I would like to try and bring over. But yeah, with slightly tempered expectations, I think.
Drew: I’ve talked a couple of episodes ago with Hayden Pickering about designing components, particularly within a design system to be accessible. That’s something you’ve got a lot of experience with too, I believe. Obviously accessibility is really, really crucial when working within a government design system, but many of us would argue that it’s really, really crucial wherever you’re working. Do you think design systems play a role in the accessibility of a design or the implementation of a design?
Amy: So there’s a brilliant talk by Tatiana Mack about building inclusive design systems that touches on this and that was sort of really influential to me and she talks about the sort of multiplication effect of design systems. So we have, with design systems, we’re telling people what good looks like and we’re giving people kind of quick ways to implement what we’re telling people best practices is. So that can work either way. It can work really well if you give people good design and good accessible design, then you have the potential to multiply that accessible design and to make things more accessible and more inclusive by default.
Amy: If you make decisions that exclude people in a design system, in that centralized space, which becomes the start point for people designing services, then you really have the potential to proliferate that exclusionary design. So I definitely think that design systems play a role in promoting and multiplying accessibility. But I think that it all starts with the intention of the teams working on and using the design system to make that happen. A design system is really it’s just the kind of vehicle I suppose and the intention needs to be there to make things accessible.
Drew: One of the things that always fascinates me, particularly with design systems that have such a large and varied audience like the the GFI UK design system, is the process of proliferating changes across the system. So if you, for example, find an accessibility improvement that you could make in a particular pattern and you make it in the design system, how do you ensure that that gets rolled out across such a broad audience? Is that something you’ve got any experience with?
Amy: Yeah. So again, I think that we kind of in the GOV.UL design system team, we put a lot of consideration into how that would work. I have to be honest, a lot of it is to do with how it’s technically implemented and I’m definitely not the right person to talk so much about the technical aspect of the team. I find there’s sort of two camps with design systems and there’s a camp which is like let’s get stuff out there as quickly as possible. Let’s just make it open soon as we can and that will stop duplication of effort and multiplication of effort and then we can iterate it as we go along. Then I think that there’s a slightly more sort of let’s move a bit more slowly camp, which I think I’m in, which favors holding off on releasing stuff until you have a certain level of confidence in it.
Amy: And I think that’s quite important because I think that in general, if you’re designing products and services, then starting with the minimal thing and then iterating as you go I think works great, but I think when you’re building something central that’s designed for lots and lots of people to sort of reuse and give to lots of different audiences, you very quickly use control of the thing and the way that it’s being used. So I think that having a certain amount of confidence in something before you release it and having a kind of assurance process in place, that means that you’ve got some confidence that it’s accessible before it goes out there is quite key and then hopefully the thing is slightly more stable and I think that’s really important for trust. I think trust is quite important when we’re talking about making changes to design systems because if we’re releasing changes all the time, then that makes the system quite unstable to use and I think that that breaks down trust and then people aren’t so likely to install updates and things.
Amy: Whereas I think if you can show that you’re being considerate about what you’re releasing and you’re releasing changes only when necessary, then you have that Goodwill and then people are more willing to make updates and stuff I think. But yeah, I mean I know that a lot of work went into making sure that the update process was fairly smooth and easy to implement in the GPV.UK design system. I’m just not the right person to talk about it, I think.
Drew: So we talked briefly about documentation. If I was looking to document a design system and if I wanted to do a really good job of it, is there anything that you would advise me to do to make sure I was documenting stuff well?
Amy: I never think it’s possible to kind of just give a blanket statement here because it really does need to cater to like the specific audience that you’re dealing with. My thing is to always aim to be just a little bit more inclusive than you maybe feel that you need to be. So if you’re thinking about, especially in a smaller organization that’s maybe scaling, I think that you have to be just as considerate as your future audience and your potential audience as your current audience. So if you have a small organization and you’ve got 10 front end developers and they all know the same sort of stuff and they’re able to talk to each other and communicate fairly freely, then your documentation may not to be as comprehensive as it within the larger organization.
Amy: But I think that in order to help a design system scale and to make sure that it’s equipped to do that, you have to think about who might join the organization in the future and who do you need to kind of leave the door open for? Who do you need to make things clear to? So I think always aim to be a little bit clearer than you feel you need to be in the moment. I think really testing documentation a lot is useful, so there’s lots of different ways to test content and documentation and I think that it’s really important to go out and make sure that it makes sense to other people. I think Caroline Darret always says that if you understand it well enough to know it’s correct, then you know too much to say that it’s clear.
Amy: Have I said that correctly? If you know it well enough to know it’s correct, then you know it too well to say that it’s clear, that’s better I think. And I really sort of agree with that. I think that to write good documentation you have to have pretty good subject matter knowledge or you need to or you end up developing that subject matter knowledge over time and through the process of writing it. By the time you’ve got that subject matter knowledge, it’s really hard to judge whether or not you’ve conveyed it in a way that’s clear to somebody who doesn’t. So going out and testing it with people who don’t know the subject matter like you do and getting them to actually try and use it in a practical task I think is really important. Yeah, that that’s my sort of number one thing. You’ll learn way more by putting it in front of people then you’ll learn by reading around and looking at what other people have done I think.
Drew: And in doing that you’re obviously going to get feedback on that documentation. Do you have any suggestions for how you would approach fixing things based on that feedback? Is there anything specific that you’d be looking for in the feedback to understand how well your documentation had worked?
Amy: Yeah, I mean there’s a few things I think to watch out for. I think it’s is really important to separate preferences and people perhaps not liking the documentation from people actually not being able to use it. So I think any task-based testing with documentation is better because it might be that actually somebody complains their way through an entire guide but they still complete the task that you’ve set them. That’s not to say that that doesn’t matter. If they wanted to do the thing but they actually hated the process, then you of course need to take that into consideration. But I think that some people and I’m probably one of them just can’t help themselves and will start, especially if it’s a content designer, I think we can’t kind of ever quite put that content design mentality aside.
Amy: So I definitely have a tendency to start live editing stuff if I’m supposed to be participating as research candidate on it. So I think yeah, separating preference from actual kind of usability and blockers is quite important. I think that making sure that your really interrogating the need to make changes and to update things. I think sometimes if somebody is particularly engaged with a design system, depending on the sort of person they are, they can be quite vocal about how they think it could be better or how they think that how they would’ve done it perhaps or how it could be clearer. I think it can be quite, especially if you’re sort of trying to build Goodwill and you’re in that early stage with the design system, it can be quite tempting to just immediately respond to that feedback and do what they say or try and make it clearer.
Amy: But then you can end up building it too far in the direction of the loud minority and I think actually really saying like how many people have got this problem? What evidence do we have that this isn’t working for people? And does that warrant a kind of update? I think yeah, trying to resist the temptation to respond to every comment and bit of criticism that you receive is quite important too, yeah.
Drew: I suppose I’m a common theme here with design systems that enable consistent design and give you a reusable resource in your design and about accepting contributions that make those designs stronger and implementing accessible design choices and documenting your design to make it easy to access and use. It really all comes back to sort of inclusion, would you say that was fair that including people as much as possible?
Amy: Definitely. Yeah. I mean I think that a good design system is a representative design system and I don’t think it’s possible to achieve representation by acting on people’s behalf. I think you really need to try and involve people in the process as much as possible. I think often for people working on design systems and certainly it was the case for us at the GOV.UK design system, you tend to be one step removed from your organizations end users. So if you think for the GOV.UK design system, the people that the design system is ultimately there to serve are members of the public and citizens and people using government services. But we in our team, we’re really working directly with those people. Most of the time our direct users are people working in the civil service. So making sure that you’ve got really strong feedback loops between your direct users and then their users to ensure that it’s representative I think is really important and I think that’s where inclusion comes in and yeah, I completely agree. I think it’s a really central thing, like I can’t imagine how you could build a successful design system without a focus on that.
Drew: Is there anything else that you’d like to share with us about your work on the GOV.UK design system?
Amy: I think my sort of main takeaway from working on it is that, I hate using the word physical when I’m talking about anything on the web, but the the visual representation of a design system I think can end up being the thing that we all get really fixated on. We look at how it’s coded and we look at how it’s organized and what it looks like and how it’s documented and what the design is. I think that obviously that stuff is really important. I think that it’s the thing that you can look at and show people and share. So it’s easy to see why we get fixated on that. But I really think that the most important factor of it is the people. I think that having inclusive processes and making sure that you’re kind of fostering safe discussion spaces and that you’re giving people an opportunity to get involved in the work and to participate and feel motivated to help you with it and to feel this sense of ownership over it.
Amy: I think all of that stuff is really important and all of that stuff really happens outside of the code and outside of the documentation. So yeah, I think my key takeaway from working on the GOV.UK design system is how much of it is really just people work and not really anything to do with guidance and code.
Drew: Here’s at Smashing we’re all about learning. So what have you been learning lately?
Amy: Lately I’ve been learning a lot about productivity and focus. I think definitely towards the end of last year I became aware that I was really plate spinning and luckily I don’t think I smashed any of those plates but I found myself kind of working quite chaotically and moving around lots of different projects and saying yes to everything. So this year is the year that I want to really improve my focus. So I’m trying to learn a little bit about mindfulness and organization and how to say no to things strategically so that I don’t get overwhelmed and too distracted. I’ve started bullet journaling so I’ve really become the full 2020 cliche at this point. So that’s what I’m learning at the moment.
Drew: If you dear listener, would like to hear more from Amy, you can follow her on Twitter where she’s @Amy_Hupe or find her on the web at amyhupe.co.uk. Thanks for joining us today. Amy, do you have any parting words for us?
Amy: Stay cool. What? Why did I say that? Just came out, it just came out.
(dm, ra, il)
