Getting everyone in the product development process on the same page requires radical transparency, empathy, and collaboration. In the Same Page event series, we’re getting practitioners and leaders together for open conversations on exploring what it takes to build those cross-functional team relationships and how to find alignment.
In this Same Page event, Digital Service Expert at United States Digital Service Ellen Butters joined Abstract Senior Product Manager Alyshia Olsen to chat about how designers and product managers can better partner and collaborate with context. When you’re working on an early stage product, who drives Design or Product Management? How can these two functions find alignment on where a product should go at early stages?
Alyshia Olsen: Hi.
Ellen Butters: Hi.
Alyshia Olsen: Welcome to Same Page, where we're going to explore design first approach to product. I am Alyshia Olsen and I'm a senior product manager at Abstract. In the past, I have worked as both a product manager and designer, so I've had experience about 50/50 during my career. I am joined today by Ellen Butters, who is a digital service expert at the United States Digital Service, which is a super cool job that I'm really excited about. Can you say a little bit more about yourself and your role?
Ellen Butters: Sure. Yeah, I'm a design generalist. And you may not have heard of the US Digital Service. It is a small federal government level agency that technically sits in the White House, but the way it works is it sends little task forces of digital service experts, and those comprise engineers, product managers, designers, et cetera. And we go out in this little task forces of three to eight people to any of a number of executive branch agencies. So that could be Homeland Security, where I am at right now. It could be Health and Human Services, the veterans, administration, and et cetera.
Ellen Butters: So I've been there for about three and a half years, and I'm coming up on my four year term. So it's a tour of service model, which is kind of like the Peace Corps. And yeah, it's a non-partisan job, and we just serve the American people, and it's a great way to serve your country in a way that isn't permanent, or doesn't necessarily define your career.
Alyshia Olsen: I'm like so excited to talk to you more about your job today. So today we're going to be-
Ellen Butters: I'm excited too, about going from design product Management and learn about that.
Alyshia Olsen: Awesome. Yeah. So today we're going to be discussing collaborating with context. So it's more about like, what comes first, design and product management tend to have different ideas about where the product should go at early stages. And we're going to have an exploratory conversation about the beginning stages of the product development story, and all the characters that you need to assemble to see it clearly. I'd also like to ask people to post where you're joining from, and what organization you're with in the chat, just so we can see who's hanging out with us today. But we'll get started while people write that all down.
Alyshia Olsen: So yeah, like I said, design and PM tend to have ideas about where the product should go in the beginning stages, but it's kind of like it's explicitly PMs role to figure everything out. And sometimes that means, in my experience, design can get left out of the loop towards the end. So like, once we know where we're going, let's bring a designer in and ask what you think about it, and how we should get there. So I think when this happens, companies can lose a lot of value that their designers want to provide up front. So I've been trying to figure out ways to get designers more involved in the early stages.
Ellen Butters: That's awesome. I mean, I feel like design is so crucial to just what it is that you're building, they almost need to do the work before the you define what it is. So it's like, even before the kickoff.
Alyshia Olsen: Right. Like it ends up being like kind of a chicken and an egg problem.
Ellen Butters: Yeah.
Alyshia Olsen: Like, sometimes the ideas come from design, because designers have been using a product and noticing that there are issues with it. And sometimes that can like be in conflict with where product thinks something should go based on what they're hearing from the sales team or from customers who are using it.
Ellen Butters: Yeah. I mean, do you have an example of that from when you were a designer? And ...
Alyshia Olsen: I do. Yeah. So in my previous roles I worked at Tableau as both a designer and a product manager, at Microsoft as well, that was product management primarily. But one of the projects I worked at, at Tableau as a designer, we had had a lot of customers asking us for a particular feature that would help, it was called dynamic parameters, but that is beside the point. It was a very specific technical feature and customers have been asking it for a couple years and the PM team eventually, just kind of from the top down, prioritized, like, yeah, we should just go build this.
Alyshia Olsen: And it kind of came down the chain to us as designers. Like hey, can you go design this new feature? And myself and one other designer were working on it. And as we started looking into it, we noticed there were a lot of technical limitations, a lot of reasons why we hadn't done this in the past. And we started to explore like, what are some other solutions? What are our customers actually trying to do here? Why are they asking for this? And we realized that there were a couple of different features that customers actually needed, and there were three different scenarios, which were why customers were asking for this one feature. And the three different scenarios could be solved in really different ways.
Alyshia Olsen: So long story short, we ended up getting those three different features prioritized on the roadmap, and all in all ended up taking a couple years to get there, but we got a lot of really positive feedback from our customers. And it was really great that the product team took that feedback from design and changed the roadmap because of it.
Ellen Butters: So would you say that there was a little bit more upfront discovery that was needed before defining what the ABP would be for this?
Alyshia Olsen: Yeah. And I think from the product teams perspective, at the time, it felt frustrating because they thought that there was a feature that they were just going to go build, that was going to be easy. And then when it got to the design team, it was like, okay, maybe it's not quite what we thought it was. Have you run into anything like that?
Ellen Butters: Yeah. I mean, I think that, well, at US Digital Service it's not as much of a problem because everyone has bought into the principles of human centered design. So design is at the very beginning stages of everything and all the disciplines are at the beginning stages. So like, there's any one discipline that's sort of left out and it's really wonderful, but I have in the past, where design is really thought of as more of like a surface level skill, as opposed to sort of integral ... like more of the research and the generative research side of things.
Ellen Butters: And actually, at National Geographic, there was a cultural, a lack of approach in that way when I first got there, and then it sort of evolved while I was there, which was great. But yeah, I mean, I think a lot of organizations are so quantitative data driven, and so ... I mean, I think Amazon might be one example, maybe 10 years ago where literally every business decision was made for quantitative data. Like the color of a button had nothing to do with brand, it just was like, based on whether users clicked it more.
Alyshia Olsen: That's an insane amount of data driven-ness to me.
Ellen Butters: I mean, I think we all want to be data driven, but there's different kinds of data. There's the qualitative data and the quantitative. And so, I think that companies tend to short trip the qualitative and partially it's on designers to make the case better for the qualitative data having a lot of value for the organization. And so, I actually had sent you an example of that, that I was hoping you could help because designers like myself are very focused on talking to users, and at times we're not as strong as presenting a really strong business case. And I was hoping maybe you could give us some tips on how to frame a business case based on qualitative research.
Alyshia Olsen: Yeah, do you want to go through the example for everyone?
Ellen Butters: Yeah, absolutely. So I'm just, I picked this example because it's pretty accessible, easy to understand. At US Digital Service I was doing a bunch of user research for a redesign of the website, the US Digital Service website, usds.gov. And the main purpose of this website is to recruit, is to motivate people to apply for service. And, excuse me. And so people, in doing the research, so sorry, I need to cough.
Ellen Butters: Sorry. So in doing the research, I think I'm having an allergic reaction to something. It's very strange. In the user research, users consistently asked for us to provide more content, more video content explaining what it was like to work there. Because it's kind of a sacrifice, you have to relocate to Washington DC often, and they need to make a big life decision. And so they need to envision themselves and the job. And so multiple times unprompted, they suggested video content, like a day in the life of the US Digital Service.
Ellen Butters: And so that is a perfect case where I don't have any quantitative data supporting this need, and it would take resources to develop this content, because it's not a skill set that's in house. And how can you even measure success, because sometimes just clicks on the video might not result in applications, but also applications themselves might not be the success measure. Because what we really want is people to not drop out at the later stages, they need to know enough information so that they won't drop out. So I'm just curious how you would approach this.
Alyshia Olsen: Right. So you don't want people who are applying to be quality candidates that you're excited about, they get to the end of the interview process and are like, well, I want to ask a couple more questions, and then kind of drop out at the end, because they didn't quite know what they were getting into.
Ellen Butters: Exactly.
Alyshia Olsen: Yeah. So I think, one, I think you can make some of that into qualitative data in fact, upfront. And it sounds like there's two parts here. One is like getting something on the roadmap to address this, and then the other one is like, how did this go once I got it on the roadmap and developed it? So as far as getting it on the roadmap, that's a question that we get asked a lot. Like, we're giving you this feedback, like, how does something get on the roadmap? And there's always a lot of competing priorities for a PM, so most of my job is to tell people that we cannot do something right now, which is really sad.
Ellen Butters: You have to [inaudible 00:12:08].
Alyshia Olsen: Sometimes.
Ellen Butters: Yeah.
Alyshia Olsen: But yeah, it's part of the job. And you have to choose the things that are going to have the highest customer value, right? But in order to say like, hey, I think that this thing is important, and it's going to have customer value, and to show that to the PM team. I think one way to do it is to say, hey, we did this user research. In our user research studies, this percent of users mentioned this unprompted. So even saying, like, if you have something like 20% of users mentioning something like that, like that's a pretty big number.
Ellen Butters: That's quantitative, yeah.
Alyshia Olsen: Yeah. The other thing is, when you get that kind of feedback, if you are not just saying like, hey, someone mentioned this, but if you're digging into it and saying, okay, like, why did you want that video content? Like, what problem did you think that would solve for you to the user? And it turns out, like, hey, there's this big problem, then you can frame it in terms of like, hey, this is a problem that we need to solve, rather than this is a feature I think we need to build to the PM team. And say, I think we should invest resources in this problem that we're having some issues with our pipeline here, here's a potential solution, I think that we should explore options.
Ellen Butters: These are great tips, I must write these down.
Alyshia Olsen: Yeah. And then again, having a hypotheses upfront about how you're going to do the measurement is always helpful, like, so I think that if we invest in this, we're going to get fewer people dropping out of the pipeline. Right now we have a, I don't know, I'm going to make up a number, like 7% success rate for someone who joins the pipeline to join the company. So if we could bump that number up to 10%, that would save us whatever amount of money.
Ellen Butters: It's incredible the amount of resources that have to be dedicated to get somebody in the door, because it's a rather intensive process of the background checks, as you can imagine, and just relocation, sometimes cross country. There's all these points at which recruits could just drop off.
Alyshia Olsen: And I think once you get like, hey, I think this is a problem worth investing in. If you get a PM who is invested in that with you, though, they'll be up for doing some more of that quantitative work, if you don't have buy in from upper management or leadership, they I think would help you do some of that work. I personally am more excited about like the quantitative side of things, but part of the reason I was excited to go back to a PM role was because I wanted to push myself in this direction. So it's really fun to be able to kind of do both and see how they interact.
Ellen Butters: Yeah, it sounds ... I mean, I would love to have you as my PM because you would side with us and help me think more in terms of the quantitative side and exercise that muscle. And I mean, along those lines, are there any like foibles of designers or like just behaviors that you used to do even or maybe that designers tend to do. Maybe it's just like, being very user centric, but also maybe just create, just be immersed in the creative process, like 30 things like that, that you're like, maybe you should check that or just keep it in check.
Alyshia Olsen: Yeah, that's a really interesting question. I feel like I have learned a lot going back and forth through both of these. And I think in my earlier days as a PM, I definitely did a lot of things that when I switched over to a design role, I was like, oh, that's kind of not the best when a PM does that.
Ellen Butters: Oh, that way, direction, I was thinking the other way.
Alyshia Olsen: No, I can speak to both, but yes, some of it is, like, I think from the PM side, like not understanding the value that your designers can provide, the value your designers want to provide. And just kind of saying like, okay, the brief is done, here it is and make it pretty, I think is not what most designers want to do, but I think a lot of PMs haven't, especially earlier in their career, like haven't worked with designers before and it just something they don't really know. Like, how to work with a ... Like, it's not something you get taught. And so I learned it by being a designer who worked with PMs. And then I think there's a lot of education to do sometimes about like, what does a designer do
Ellen Butters: With that now with your fellow PMs, like do you tell them about ... Do you try to pass on your knowledge?
Alyshia Olsen: Yes, but also there's like, the people who I'm working with are also very experienced PMs who have been in the role for a long time, generally know what they're doing. So I do try to push to like, hey, let's think about problems as much as possible. Hey, if there's not a designer in the room, let's notice that, and let's make sure that we bring someone in the room as early as possible, let's make sure that when we start talking about features and functionality, we're bringing our designers in when we're doing some planning,
Alyshia Olsen: As well as the rest of the company, really. We're actually like working on an updated way to do our planning because of some of the feedback we've gotten from others in the company. But to go back to answering your original question, I think one thing that can be a little bit frustrating is when a designer doesn't show options, or show like when they present a design, like why do you think that this is the design we should go with?
Alyshia Olsen: So knowing like, I thought about these two or three things, even if as the designer you're like, there is a way that we should do this, like I know it. And this is advice that I got from my design managers when I was working as a designer, the best advice I've ever gotten was like, if you have a way you want to do it, show two other options. If someone mentions anything, draw it out, make like a pros and cons list and be like, here's my recommendation. And-
Ellen Butters: Defending your decision in a really like, logical, concrete way.
Alyshia Olsen: Right, yeah. Because a lot of product managers come from an engineering or a business background, and being able to take your ideas and show them in a slightly more logical way than maybe you were working on them originally, is really valuable when you're presenting the work. And it gets you faster, like it gets you further a lot faster.
Ellen Butters: Yeah, absolutely. Yeah, we can sometimes think in a very abstract, sort of right brained way, but then presenting it and arguing your case needs to be done more in the other side of things.
Alyshia Olsen: Yeah. It looks like we have a couple of polls here. Excited to go through. So it looks like 84% of us are designers. We have 7% engineers and 7% product managers. So just a couple from non-design backgrounds. The other one, oh, I think we have a couple, we've been a little behind. As a PM, how do you bring in a busy designer? Early with a full cross functional kickoff meeting, I love it.
Ellen Butters: Yeah, that's great.
Alyshia Olsen: I was curious, you had mentioned the way that you do things at your current role, like how does that kickoff work? Because you mentioned you liked it.
Ellen Butters: Yeah. So the kickoff can happen ... Well, we have a number of types of engagements, some of them are very, they're almost like firefighting, like there's some crisis in the government and we have to solve a problem in an immediate way. And then other times we have a little bit more of a formal, written up contract, not a contract, but a statement of work with an agency and we decide together like what that engagement is going to look like. And we have a kickoff meeting to sort of say, here are our primary stakeholders, here are our goals and metrics of success and how we plan to hand it off in the end.
Ellen Butters: And so, our task forces, like I was saying, are always cross disciplinary, cross functional. And so everyone is present at those kickoff meetings, and we also have a very flat organization, so nobody is sort of the manager. We usually have like a larger team lead at an agency. So if it's Homeland where I'm at right now, there might be like three different small projects going on and there will be like a team lead sort of as like a manager of sorts of those teams. But everybody on the team has like an equal voice, and we just have different roles.
Ellen Butters: And what's cool is, your role at USDS can change as well, like you can become a lead. Sometimes people switch between disciplines, like you, you are someone who could do that easily because you've already served both roles. And so there's a lot of mutual respect, and I really love that because it's not like any one voice is stronger than the other. And so we tend to just define what the work is together, like we'll write and we'll define measures of success together. We'll have regular retrospectives to see what's working, what isn't. And we'll be generally strategic partners, although PMs can tend to think more along those lines because the designers and engineers are often in the weeds doing a lot of hands on work. But strategic thinking is not limited to one role, for sure.
Alyshia Olsen: Yeah. I feel like that sounds like a really good way to do it. Oh, we have some updates to the poll, 60% early, 40% with an async memo, 50/50 now.
Ellen Butters: Interesting.
Alyshia Olsen: Very interesting. I think, honestly it depends for me, depending on the scope of the work. Like if it's a huge project, I feel like you do need a big kickoff meeting. But if it's something like we need to add this pretty basic functionality to something or people have been complaining about this one thing, like, yeah.
Ellen Butters: Yeah, of course it all depends. And I think it sounds like in your situation, oftentimes, like a huge kickoff meeting might be just like, slow down velocity a little bit. But I mean, for us in the government it's just a prerequisite to have it because you kind of have to make sure you have a champion, a set of champions on the work on the civil servants side. So your business owner, to some extent, is a civil servant who might not understand technology super well, but who we plan on making a technology expert through working with them.
Alyshia Olsen: How long does a project typically last for you?
Ellen Butters: So they can range between three months and a couple years at the maximum. So we tend to want to have quick turn projects, because there's so many problems to solve and we just have like a very, a principle of just shipping delivery model. But there are some products that we're really most suited to build, and the problem is that it can be fulfilling a law. And so an MVP may be a little larger in the private sector because you are having to adhere to all the permutations of a law.
Alyshia Olsen: What does your shipping cadence look like?
Ellen Butters: I mean, like oftentimes ... Also to clarify with delivery, sometimes there's not like a software product that we're delivering, at times it's like a good data model or a infrastructure for better, like a warehouse or something like that. Or just putting a system into the cloud. That just sounds so simple, but in government things are often very antiquated. And so, shipping might not be like what you think of shipping is, but the cadence is very similar to private sector, because a lot of the USDS staff members come from the private sector.
Alyshia Olsen: Okay.
Ellen Butters: Yeah.
Alyshia Olsen: Makes sense.
Ellen Butters: Yeah, and that's why a lot of people come from Silicon Valley, and like, have to travel across country to DC to work there. Cool. I'm going to check the chat or Q&A to see if there are any questions about CNE. Feel free to ask us questions in the Q&A, if you have any.
Alyshia Olsen: I feel like we're ready for another poll, we could do, where does the product life cycle start in your personal opinion? This is personal opinion, not where does it start at your company? So I'm interested in seeing what people think, but you and I can chat a little bit about this as people are responding. What are your thoughts?
Ellen Butters: I think, of course, it depends. And I think you had alluded to this, like, if there's a mid flight product, oftentimes it will get kind of triggered by design research. But if it's sort of a brand new thing that's sort of a big idea and your kind of like, its design thinking, but it's not necessarily led by a designer. Like a [inaudible 00:27:00] product manager employs design thinking and will kick off the idea. Does that make sense?
Alyshia Olsen: Yeah. I'm trying to ... actually I don't think I have a super strong personal opinion on one or the other, I think my personal opinion would be all three of these things. I think product managers are informed by design, sales, marketing, user research, as well as product vision, like where do we want the product to go in the future and what types of things should we prioritize in order to get product in that direction, that we think that is going to be valuable for our customers?
Alyshia Olsen: But I think that means that like, all three of these make a ton of sense. And if you're leaning too far in any one direction, I think then you have to kind of question yourself, like, why are all of our product features coming from sales? Or why are they all coming from user research? Like, is this what we actually want to do or should we think about getting some ideas from some other places, too?
Ellen Butters: That's a very inclusive, human centered approach. I commend you.
Alyshia Olsen: Yeah, it can be hard to do that, though. You said that you worked at National Geographic, and there wasn't as much of an approach and it evolved.
Ellen Butters: Yeah, I mean, I think that historically the genesis of its content, it's like in early days was the magazine. And so I think the business model really followed this sort of print based approach for a long time, and I think that there was a good consumer insights department, but it wasn't fully integrated with people and the digital process of building things. And so, there was ... And then with the business owners from the business side, there was a lot of culture that they knew best.
Ellen Butters: We know how to tell stories, we know what the information should be that we're sharing with our readers, like not going to the readers and asking them what they want. So that I think because of the huge changes in media, in digital media overall, is 2000s end of the team, [inaudible 00:29:44], they kind of had to adjust to some extent, and they started bringing in more user focused, just UX as a discipline at all. It was very much print designers or visual designer, mapmakers, that kind of thing. And then they started investing more in UX, which was great.
Alyshia Olsen: Yeah. I feel like the industry as a whole has been kind of doing this over the course of the time that I've been in tech, at least. I've seen a lot of people kind of go from like visual design to more UX design to more product design. And I love that I'm seeing product designer now as a role, whereas I hadn't seen that before. Product designer used to mean someone who designed physical products, and now ...
Ellen Butters: What does it mean to you? I have to admit, I'm not totally clear on the distinction between UX and product design.
Alyshia Olsen: The way I see it, and I actually asked my design director here, because she was like, no, we have product designers. And I was like, what is the difference? And she shared out a really good article that I wish I remembered the name of off the top of my head, but I think the main difference is the user experience designer is less involved in the business side of things and the product designer is more involved in like, what is this as a product and how does the user experience design that I am building, fit into the product as a whole?
Ellen Butters: That's fascinating.
Alyshia Olsen: Which I love, and I love collaborating with my designers in that way, where I'm starting a brief and saying, hey, I'm starting something on this, like can we collab here and make sure like these goals, these non-goals, like where we're going, that'll make sense from where you're standing too.
Ellen Butters: Yeah. It also makes me think of working with engineers closely, because I feel like when I whiteboard and sort of do early stages of design with engineering, I avoid a lot of pitfalls, first of all, because I don't want a direction that is like not maintainable, for instance.
Alyshia Olsen: Yeah.
Ellen Butters: But secondly, I think, then, when we get to usability testing or the validation stage, and I invite them to the listening of that, and their observation, they have such good insights and synthesis of the actual usability testing, that they're able to suggest things that maybe I wouldn't have thought of, or sort of like, help me interpret the usability in a way that maybe I wouldn't have done on my own. And I really enjoy that.
Alyshia Olsen: Yeah. I feel like it can sometimes take a little while to get to the level of working with someone where you have that really good cadence, but once it happens, you're like, you just get so much more cross pollination and you get to figure out what works so much faster and what doesn't.
Ellen Butters: Yeah, absolutely. It does take a lot of trust. And then you have to leave your ego a little bit behind because people will be like, that ain't working and you have to just eat it.
Alyshia Olsen: Yeah. Some of my best projects I've worked on have had like five hour meetings in a room with my PM and my developer, and just like, we're just going, we're running into things going, okay, well, that doesn't work, what else can we do? What else can we do? And really jamming there. Versus one person having an idea and kind of throwing it over the fence and then having it thrown back.
Ellen Butters: Yeah, absolutely.
Alyshia Olsen: Oh, question for you.
Ellen Butters: Yeah. I have a lot of stories, some of them I can't tell 100%, but I just wanted to mention, okay, so USDS takes its field research really seriously, because we're designing public facing services. And sometimes we prototype or make a proof of concept for a possible legislation, but that legislation might not come to fruition, so we don't end up shipping, but most of the time we ship. Sometimes we have to prove something that's related to legislation, and without getting into too much detail, I did a proof of concept with a front end engineer around universal background checks. And for our field research, we had to go to gun shows.
Ellen Butters: And because our users were gun buyers and gun sellers, and so to understand this process, and this is a completely like non-partisan thing, we're not in a partisan business, but like we went there and did research in the field there and it was unlike anything I've ever experienced. And that's the kind of stuff we have to do in the government.
Alyshia Olsen: That is such a cool story. I would love to do that kind of user research.
Ellen Butters: I mean, it was awkward a little bit because I don't really look like the prototypical gun buyer. And so I had to like thread the needle and just like swallow any kind of apprehension I had about sticking out or any looks that I got.
Alyshia Olsen: Yeah, that makes sense. But yeah, still, so cool. So we have one more poll here that I'm curious about from designers perspective, which is, what is the best way to communicate and collaborate with your PM in early stages? Yeah, what do you think, Ellen?
Ellen Butters: Of course, yeah. And I want to know your thoughts as well.
Alyshia Olsen: And I was thinking about this, especially like from the remote perspective, since we're remote now. And since you mentioned white boarding, and I mentioned hanging out in rooms with people, like that's not quite something we can do right now.
Ellen Butters: Yeah. I mean, I think there's a lot of great tools now. And I'm sure everybody on this call has used Mural or Miro, or something like that. And that's something that your company is developing as well. I think those are really useful. I also use Figma. And just sort of, like in the same workspace and working together and hashing it out, I think is great. And I always like to hear my PMs perspective of like, what are we actually trying to achieve? And, how is this helping a human?
Ellen Butters: And they often have a really, in some ways, like a more elegant way of framing it. And so that really helps me with how I approach the research. And then ultimately, how I solve the problem, because when you form your research plan, the questions you ask, so depend on what you were actually trying to achieve from a product, right?
Alyshia Olsen: Yeah, that makes sense. I think from my perspective, I like to make sure I'm bought in to whatever the PM is trying to accomplish. So if it's, I don't know, we should build this feature being like, well, why are we building that feature, is that feature the best feature to build to do this thing? And if not, do we have a good reason that we're doing this instead of the better thing? Really asking all the hard questions up front, so that we don't get into them later, so that they're hashed out and we like start from a place where we're agreeing.
Ellen Butters: Yeah, that's what I appreciate about the PM role so much is that, is this like relentless prioritization, because it's not a habit. Like, I tend to just see all the problems and want to solve all of them and just get creative. And oftentimes I see like a future vision and want a future proof for the end stage and then work backwards.
Ellen Butters: And that can be effective from a design perspective, because you are always building things in a way that will not break in just one or two months. But knowing what order to do things in is so helpful. And like, what is going to be more impactful to users? And that thought process is so great to have a sounding board from a PM.
Alyshia Olsen: Yeah. And I think also knowing like, like sometimes it's actually a really good idea to start with a vision and move backwards, and sometimes it's not the right time. And just like upfront being like, hey, this is what I want to do here, is that cool PM? And sometimes the PM will be like, yes, that is the direction to go. And really knowing when you have the freedom and when you're like, okay, like this is not the time.
Ellen Butters: Just do this small thing, like we need to fix this little problem in front of us. Yeah.
Alyshia Olsen: I did want to touch on our process pages. And we're in ... hold on. Well, so you and I both have some notebooks that are process pages. I know a lot of us have like private scratch pads and programs we use as kind of sketch out initial ideas. And this is like a really important part of the creative process. And Abstract is trying to bring this out into the open with a process pages project, so we want to see your processes, we would love you to share them with us. Do you have your notebook to hold up? I can hold up my notebook as well. Mine is less drawing and more PM thoughts. But ...
Ellen Butters: Nice. That screenshot, I don't know how you got that up. This is a series of stepped navigation. Like different approaches.
Alyshia Olsen: Yeah.
Ellen Butters: It's backwards, right?
Alyshia Olsen: No, it is not backwards for me.
Ellen Butters: Oh, okay, good.
Alyshia Olsen: I think you see it ... I see mine backwards, too.
Ellen Butters: Let's see, oh, this is a service blueprint.
Alyshia Olsen: Oh, that is amazing.
Ellen Butters: So different approaches.
Alyshia Olsen: This is actually my favorite part of the design process is like, is these like early mental models of how something is going to work before you start the actual drawings. I think that's the coolest. Here's some other examples I think we have of some other people's process pages. Some people are a lot more artistic than I am.
Ellen Butters: Wow, you can get so tight, but it's like, if you have spent a whole day on this one thing. Which I am guilty of, for sure. Oh, in terms of like diagrams of how something can work, I'm with you, I love like those sort of conceptual diagrams to help with the mental model. I'm going to try to find that.
Alyshia Olsen: Yeah. I feel like they really help when you're having like those conversations with development, and trying to figure out like if something's a little bit complex, like is the decision getting made here or over here? Because that's going to change the design.
Ellen Butters: Absolutely. I have an example of something here.
Alyshia Olsen: So I wanted to add to promote the project, we're going to give away 75 process page journals. Our producers shared a link in the chat bar, so you can claim your own process pages journaling kit. So please try to claim one, record your process, share the results with us. Your submissions may be included in our digital magazine. And after the event, you'll find some more information about process pages in your email, or on our Twitter account. You can go ahead and show yours.
Ellen Butters: Oh, yeah. This is like a systems architecture diagram. So like, how different like layers of a process can work. I probably can't hold this up for too long.
Alyshia Olsen: Yeah. That is so cool.
Ellen Butters: Just because it's Homeland, and they get kind of nervous about stuff.
Alyshia Olsen: Yeah. Oh, yours are amazing. Yeah, I haven't been designing for a little while. So mine are more to do lists than anything else, but ...
Ellen Butters: I have plenty of like chicken scratch too.
Alyshia Olsen: Yeah. Cool, I think we are wrapping up. Yeah, that went by so quickly.
Ellen Butters: I know. Do we have any questions? Nobody else that had any questions.
Alyshia Olsen: We must have answered them all. So thank you all for joining us today, and we hope to see you on next time when Josh Burr and ... Oh no. I'm trying to remember how to pronounce her name. Megan Schofield will join us to discuss the art of reviewing. It takes hard work to get on the same page, but together we can get there.
Ellen Butters: Thank you. Thank you for coming.