Scott Jenson has done strategic UX design work for some of tech’s most important companies, including Apple and Google. Now he’s semi-retired and focused on improving the experience of using open source software. In this conversation, we talk about what’s different about open source, how design can make it better, and how designers can benefit from participating in open source projects.

Show notes

Show notes include Amazon affiliate links. We get a small commission for purchases made through these links.

If you're enjoying the show, please rate or review us in Apple's podcast directory:
https://podcasts.apple.com/us/podcast/the-informed-life/id1450117117?itsct=podcast_box&itscg=30200

This episode's transcript was produced by an AI. If you notice any errors, please get in touch.

Transcript

Jorge: Welcome to The Informed Life. In each episode of this show, we find out how people organize information to get things done. I am your host, Jorge Arango.

My guest today is Scott Jenson. Scott has done strategic UX design work for some of tech’s, most important companies, including Apple and Google. Now he’s semi-retired and focused on improving the experience of using open source software. In this conversation, we talk about what’s different about open source, how design can help make it better, and how designers can benefit from participating in open source projects. And now, scott Jensen.

Jorge: Scott, welcome to the show.

Scott: Welcome. Thanks for having me.

Jorge: Well, I’m very excited to have you. I’ve been following you on Twitter for a long time and always appreciated your perspective. You have very nuanced takes on very important subjects in design that are clearly informed by a deep experience. So, I’m very excited to get to talk with you here on the show. Some folks listening in might not be familiar with your work. How do you go about introducing yourself?

About Scott

Scott: I see myself as a UX strategy person. I started off as a UX designer. I actually got my Masters in Computer Science, but got my first job at Apple System Software and worked my way up onto the Newton team, as a programmer for the Newton Project. I left; ended up being a consultant for a number of years.

Went to London where I was design director for Symbian, the mobile phone operating system company, you know, before iPhone. I came back and did some more consulting. Eventually joined Google as its first mobile UX designer. Managed that team for a number of years and then ended up doing some work at FrogDesign as Creative Director in San Francisco.

Did a couple of startups. Came back to Google and worked on Chrome, the physical web project and a bunch of UX projects for the Android team, and now I’m semi-retired.

Jorge: That’s a very impressive resume. I get the sense that a lot of it revolves around the design of mobile experiences. Is that fair?

Scott: I spent a lot of time on mobile. Yes, that’s correct.

Jorge: Well, that’s obviously how most people interact with computers these days, so it’s a very important area.

Open source and UX design

Jorge: What prompted me to reach out to you was something that you wrote on Mastodon wanted to try to unpack, and I’m going to quote the ‘toot’ back to you. And folks who might not be familiar with Mastodon, a toot is the terminology that they use instead of tweet.

So you wrote, “I’m convinced we’re stuck in our UX ways. Not seeing desktop, mobile, or ML” — which I think means machine learning here, right? — “for what they could be. Open source is a profoundly positive force if we could just figure out how to work together on UX design problems.”

I was very intrigued when I read that. What is your experience with open source software?

Scott: I think open source software has all of the right motivations, right? It’s trying to not worry about capturing the user or having incremental income, and just tackle the specific problem in a way that has privacy, open file formats — you know, all the kinds of things that a for-profit company would not necessarily be motivated to do.

So, that’s why I’m really attracted by it. But you talk to almost anybody in the open source community, and there’s this concern that several of the projects don’t quite tend to have the same polish, let’s say, as more for-profit companies. And I’ve been attracted to that and have given a couple of talks on that to just help the open source community understand how to get started with better UX design.

Jorge: So you’ve actually been involved in doing design work for open source projects?

Scott: Well, I had my own open source project at Google in the physical web project, so I kind of started with that. And I volunteered at several projects or tried to volunteer and had very limited success and some frustrations in that. The classic example is you go into a team and you’re like, “Hey, I’m trying to help!” And they’re like, “Great! Glad to have you here. Please help us with our icons!”

Like, that’s like the number one thing that you get asked for. And when I tell that story, a lot of UX designers just shake their head sadly, because ythat’s part of the issue: these open source things only work as programmers and they only work with files as their lingua franca and issues on GitHub, so the only thing that a UX designer can give to them is another file.

So of course, icons become the obvious thing to work on. Where if you want to do a strategy or a user study… I mean, where do you put that in a GitHub issue? Which is why I’m intrigued with GitLab and it’s UX showcase because it’s actually trying to kind of expand UX deliverables in the open source community. So people are nibbling away at this problem. It’s exciting stuff!

Jorge: The sense I’m getting in what you’re saying there is that there’s something about the communication or collaboration tools that are being used in the development of these open source projects that constrains the type of conversations you can have. Is that a fair take?

Scott: Oh, exactly. I mean, these are programmer tools. It’s just like 1984 where, you know, things are “double plus un-good,” right? You know, the language that we’re using is a programming IDE. And so guess what? We’re framing every UX problem as if it were a programming issue. So I think we should just start with the fact that that’s not the healthiest place to be and then just talk about what should we do about it. How can we fix it?

Business models

You made the distinction between open source software and for-profit software. Can we dive into the differences between those? The sense I got when you were describing it is that there are different motivations behind them and that that somehow influences the experiences that end up coming out the other end. Is that a fair take and if so, how does that work?

Scott: Well, I want to make sure we’re nuanced here because it’s not a binary thing like: open source: good, profit: bad. It’s a continum and we can talk about maybe the extremes.

So, I think the better example — the most obviously negative example — in the for-profit side is the fact that, like, mobile gaming: you started off buying games for five or ten bucks and they were doing just fine for a little while. And then a couple of companies realized that if you charged nothing, you got massively more installs. Because it turns out that actually getting people to install your software is expensive and people are doing ad buys and the mechanics of getting it installed was…

So, that’s what ended up happening, which then encouraged the freemium model and you had to like buy more crystals to beat the level. And then you created this horrible thing called the “digital whale.” Have you heard about digital whales?

Jorge: I’ve heard the expression, but I’m not entirely sure. I think it’s related to Las Vegas. Do you want to unpack it?

Scott: The basic idea is that way less than one percent of users of mobile gaming are the ones that pay for these crystals or stars or whatever it takes to beat the game, but they pay hundreds of dollars. And so, the game companies are now designing for this digital whale. All of us normal people are kind of inconsequential.

And so, this idea of making money in this way has kind of transmogrified mobile gaming from something that was delightful and fun and lovely to this horrible grind. It’s kind of like the perversion of what money can do to design. I think we can all agree that that model isn’t very healthy. That’s the extreme that I hopefully can trickle down into other, more nuanced, smaller aspects and corners.

Jorge: The impression that I get is that underpinning a lot of the products that we interact with — commercial products that is, perhaps even the games that you’re describing — there are layers underneath them that are open source software, right? A lot of it is a hybrid.

Scott: Oh, agreed. And so picking on games is a little tricky because I doubt we’re going to see a lot of open source games, right? And I’ve heard someone say, well, “You’re never going to see a AAA game as open source!” Of course not. But AAA games, like you said, are using products like Blender, which is open source.

What I love about open source is that it started off as being this very, very low level, geeky, open, operating system thing. And then slowly worked into various utilities and then the whole LAMP stack for web development and so forth. And now we’re starting to see it grow into more applications and tools and even consumer-facing things that can reach more niche markets.

So, I just feel open source is a moving target and it’s stretching its wings a little bit to go to places that we wouldn’t think it would normally be. I find that to be really fascinating.

Jorge: There’s a distinction, I think, to be made between products that are aimed at the people who make them versus products that are aimed at a bigger audience.

Scott: Yeah.

Jorge: Emacs is a tool used by developers, and developers develop tools like Emacs. So there’s this notion of like, you know, “I made the thing to scratch an itch that I have.”

Scott: Right. And now you’re quoting Cathedral and the Bazaar, which is where this all comes from.

Aiming for a broader audience

Jorge: That’s right. The question in my mind is: is the notion of user experience design and open source software more applicable to open source products that aim for a broader audience than just the developers who work on open source projects?

Scott: Well, I think you’re making a very good point that when you have a small insular community and you’re building for yourself, that is possibly the more efficient way to go. You know, the developer is the user. And I think what’s happening is that mobile source is, like I said, stretching its wings, trying to be more consumer focused and realizing that that model breaks down.

If there’s one thing that UX designers have tattooed on their souls is, “You are not the final user.” Which is exactly the opposite of what you just said. So, to me, it’s simply a discussion around can open source expand and reach these broader markets and what it takes to do that. I don’t think that should be a problem.

But, like you said, breaking out of the mindset. I mean, I’ve literally talked to people on an open source project I was working on that said, “Well, I wouldn’t do that.” And I’m like, “You’re right! You wouldn’t. What’s your point?” You know? And so that is I think part of the growth that needs to happen in these projects. I mean, those that wish to be more consumer-focused.

Jorge: I’m going to put myself in the position of someone who would be managing one of these projects. I would also expect that if I have an agenda or a roadmap for features that I want to roll out, I would prioritize the features that I perceive as solving problems for my core constituency, right?

My sense is that what we’re talking about when we talk about improving the user experience is about kind of broadening the appeal of the product beyond that initial set of users, perhaps.

One of the other… and here, I’m going to be, I guess, making public my ignorance of how open source development works, right? And that’s part of why I wanted to talk with you, just to learn about this. But the impression that I have as a user but not a contributor to open source software, is that a lot of it happens in the open, through collaborations that involve discussions. And it’s a very community-driven approach.

Scott: Very consensus-driven, yes.

Jorge: Consensus is the word I was looking for. Is there a design by committee problem happening here?

Scott: Well, I want to be careful because I think there’s many different ways to tackle this. I do think that’s one of the biggest problems I faced from a closed-source person trying to help in the open-source world, [is] that I had trouble, personally, getting used to the fact that it was more community driven and much slower. I was used to the PM coming in and saying, “go left!” and everybody went left. And that really doesn’t work very well in an awful lot of communities. And I’m not saying it should. I’m just pointing out the cultural differences.

Because one of the fundamental aspects of UX design is that you are fighting for perspective. Who is the user? Who are the users? What are their primary, what are their secondary goals? How do you layer them? How do you prioritize? So that idea of perspective and prioritization means that you have to make some hard decisions. And it’s often quite challenging for a community to make a prioritized decision because someone is always going to want feature X.

So I do believe that is one of the core challenges that open source software has to do when you’re trying to make challenging decisions to layer your software so that mere mortals can use it.

Jorge: Yeah, and I expect that just in hearing that answer, I think that my previous question perhaps was a generalization, right? Because there might be some projects that have more of a consensus driven culture than others. Like some might have leadership that is giving a very definitive vision, right?

Design maturity

Scott: Well, I don’t want to say that you can’t have prioritization in user-centered design without… I mean, consensus shouldn’t prevent that from happening. What you need for consensus in this environment, I would argue, is effectively a little bit of design maturity. How do you talk about it? What are your shared artifacts? Can we talk and agree on these things and then make a consensus decision?

So, consensus shouldn’t be the enemy of UX at all, but it does require a certain maturity so that the team can have these conversations about who the user is and what the real problem is.

Jorge: hearing you talk about it makes me think that consensus is also a part of the design process in for-profit projects, right?

Scott: Oh, agreed.

Jorge: I’m trying to think about the distinctions between them and perhaps one might be that the consensus in a for-profit project… you have to take in perspectives that might not be part of the constraints to an open source project. Such as… well, you mentioned earlier financial concerns, right? Sales targets or a particular launch date, stuff like that. I would expect that that would be much more malleable in an open source versus a for-profit project.

Scott: One of the advantages of closed-source or for-profit systems is that you do have a metric called money, which just gives you a number. And it’s a number that you can optimize for, and that gives you focus. And so yes, I think making money will drive a sense of urgency. It will also drive a sense of competition, which a lot of open source projects don’t have. And so, you are motivated to step up your game.

I would argue in many ways that when I got started in UX in the 1980s, it felt like open source does today. Then we had this shining star called Apple, which kind of led the way and really said, “Oh wait. We need to do this UX stuff!” And so, just to compete, a lot more companies started doing better design.

I just don’t think that urgency — that competition — exists as strongly, and so therefore it hasn’t been there. But, the flip side of course, is… I did an undergraduate in economics, and one of the key things you learn is about externalities. And I do think there’s an externality to only focusing on money, which is now the flip side of open source. By not having that, you may not have the urgency, but you also have flexibility. You don’t have to do stupid mobile gaming tricks.

So, to me, it’s this understanding of what each side brings to the table and how can you take advantage of both.

Jorge: One of the things that’s interesting to me about this discussion is that I get the sense that there might be really good opportunities for designers to flex their consensus-building muscles by participating in these things, right?

Scott: If there’s one group that works harder than any other to build consensus, it’s UX designers because we are almost always at the receiving end of a lot of harsh questions. So we’re really good at trying to reframe things and ask open-ended questions and find that. So, yeah! I think we’re well suited for that.

Jorge: As we’re having this conversation, Twitter is going through a lot of changes, right? And…

Scott: Oh, you noticed!

Jorge: Right! And I mentioned earlier that, you know, I quoted a toot from Mastodon, which means you and I are both on Mastodon, right? Which is…

Scott: I have… I have switched over. I am fully on Mastodon. I only basically go to Twitter for schadenfraude. That’s it right now.

Jorge: The reason I’m bringing that up is because I think that one of the… well, I see a lot of schadenfraude and very negative reactions from folks in the UX community to what they perceive as the opposite of a consensus culture being implemented in Twitter after Elon Musk acquired it.

And I just wanted to kind of name it. And that it might be that that’s of the reasons why all the negative reactions… or a lot of the negative reactions is because we do try to work through building consensus in design, right? And this feels like the opposite somehow.

Scott: Oh, absolutely. I mean, you mean how he’s running the company?

The value must be greater than pain

Scott: Oh, I completely agree with that. But I also say something I find really fascinating, which is: the number of UX people that absolutely despise Mastodon is really quite shocking to me. Because, let’s be clear, Mastodon has problems, right? And its biggest problem is the signup flow and the concept of having an instance and how do you find an instance? I mean, there’s no question. And I’ve been active on Mastodon trying to talk about it and fix it.

But I I have a fundamental rule of design I call “value must be greater than pain.” And I’ve used it as a fundamental organizing principle. Not because you just want value to be greater than pain, but what happens at the extremes. Part of my physical web project was about reducing pain to zero and when you just… pain to zero. Value can get quite low as well. Fascinating things happen at that level.

But Mastodon, I would argue, that the value is so high that the pain can be high. And so when people are complaining about all the UX problems, they’re right. But it doesn’t matter because the value of Mastodon is so high that people like you and me are willing to go through the hoops. And so, there’s a vibrant growing community there that’s really quite powerful.

Now, absolutey the pain must be reduced. I’m not trying to justify Mastodon’s poor design in that sense. But to talk about the signup flow and say, “Well, I’m never going to join,” is kind of like missing the forest from the trees.

Jorge: One of the counter-argents I’ve heard against this sort of thing is that there’s a lot of pain in learning to drive, right?

Scott: Yeah. Yeah.

Jorge: But the flexibility afforded by being able to drive — you know, having mobility in that way — is an incentive to overcome that pain somehow. But to dive into the Mastodon signup flow — because that might be a good example to talk specifically about some of these things — I want to call out an issue that I noticed. I signed up for Mastodon several years ago when I first knew about it.

Scott: Me too, actually. Yeah, yeah.

Jorge: So I have not gone recently through that flow, but I’ve been seeing people complaining specifically about the fact that when you sign up for something like Twitter, all you need to concern yourself with is perhaps picking a username to represent you, right?

Scott: It is much, much easier.

Jorge: Whereas with Mastodon you have to go through the additional step of picking an instance, right? Which is kind of like a server. And what this brought to mind… well, first of all, I want to call out that this is a characteristic of the onboarding flow that is not UI specific. It is kind of an information architecture problem, in that you have to pick an instance because of the way that Mastodon is structured, right?

And the reason I wanted to dive into this is because you wrote a paper which is it’s part of a collection called… it’s available in a collection called “HCI Remixed.”

Scott: Oh, right. My “One Plus One Equals Three” paper.

Jorge: “One Plus One Equals Three,” right, which is riffing off Edward Tufte. And I was hoping that you would talk a little bit about that in the context perhaps of this issue with the Mastodon signup, right? Because you have an example in this paper of an an elevator… a set of elevator buttons and how an experience might be simplified. And I’m wondering if we could analyze the Mastodon signup process through this lens of one plus one equals three.

Reducing information complexity

Scott: Sure. Happy to! The key thing is that Edward Tufte talks about of this idea that when you have one line, you just have the single line. But the minute you add a second parallel line to it in a graphical approach, you’ve actually created three objects: the two lines in the negative space between them.

And it’s a well-known aspect of graphical design, that you create these unintentional objects, these spaces in between. And I just claimed that UX has a very strong equivalent, which is if you have one button, it’s pretty clear. You just push the damn button. You don’t have much choice in the matter! But the minute you have that second button, you’ve now generated a question. Which one do I push?

And now all of a sudden it’s like: what does it say? How are they different? What’s the nuance? What should the icon design be? And you’ve… it’s a whole different level. And this just keeps going with 3, 4, 5, 6, 7 buttons. And so, I use that in the elevator to say, “Well, what are we trying to solve? What’s the biggest issue here?”

And it’s pretty clear that the more important problem is that you want the door to stay open. You don’t want to rush the closing. You want to make sure that as someone’s coming, you can open it. So the idea was go back to the one button. Make that one big giant button, and then discuss other ways in which you could get rid of the close button. And so it was just using that as a foil to talk about reducing — effectively — information complexity. So that’s where that came from.

Now, the same thing applies to Mastodon right now, which is like, “Okay! I now have to pick an instance. What’s an instance? Why do I need an instance? Oh, there’s 10,000 to pick from.” I mean, it’s the perfect example of the paradox of choice, right?

So, to me, the argument there would be that… because, I mean, the comparison to email is strong and a little bit overused. If you were to say that you should have one email provider in the entire planet, everybody would freak out, right? That makes no sense. So, we’ve internalized that. But Mastodon is built on the email model.

However, you could make it easier. And so, to me, I would argue that you should assign up for Mastodon and it says, “Hey, why don’t you pick from one of these top 10 instances. If you want to, you can go find the knitting one. You can go find the one that’s for firefighters. Go find that. But if you don’t want to think too hard, just pick one of these 10 and go for it.”

So, it’s making it easy to get started and then allowing the more advanced users to find the more specific ones that they want. So anyway, that’s the the brief summary of how I would would do that.

Jorge: And the way that I see it is, it’s a call for simplifying the experience, reducing it to the key steps that you need to take in order to have a successful interaction. Because — and this is one of the points that I got from the One Plus One Equals Three paper — that every option that you add to an interface in this case causes you to have to learn about a different set of concepts, right?

Scott: You have to internalize the unspoken structure.

Jorge: Yeah. There a mental model that you don’t possess yet, right?

Scott: That’s it.

Jorge: You somehow need to be onboarded into the systems conceptual model. And we’ve been, in the case of something like Mastodon, we’ve been trained to think about our onboarding into these social networks as a one-step process, and all of a sudden we have this whole other set of concepts that we need to acquire.

Centralized consensus vs. no central authority

Scott: Well, but can I jump in real quick on that? Which is to say, we also, I think, have ceded a lot of control and a lot of ease of use by letting one company control everything. So, by having the one company, they will make it easy for you. You literally just pick a name and you go. So my solution to Mastodon, saying “Here’s the top 10 instances,” is actually is almost culturally against the approach of Mastodon, right? Who’s the central authority that says these 10 things are the “right” 10 things?

So it raises this deeper question, which is: how do we rank these servers? So if we could come up with something that is more unified or more distributed: “What is your size? Do you have these abilities? Are you publicly funded?” There’s all sorts of criteria that you can do that would create a database. And yes, you’d have a centralized database, but that’s not quite the same thing. And then you’d say, “Okay. We’re going to rank the top 10 based on this open criteria, and whoever’s in the 10 we will release.”

So that would be the more open source approach to say, “We don’t want there to be a centralized authority, but we want there to be a centralized criteria that we agree on as a community.” I want to make sure that people that are really into Mastodon don’t freak out that I suggested something that is possibly difficult for them to do. But it’s still worth having the conversation and maybe we can eventually get there. Does that make sense?

Jorge: Yeah, absolutely. And it’s such an important point that I think echoes what you were saying earlier about enough value allowing you to overcome pain. Part of what will allow you to overcome the pain of having to learn this new conceptual model is if you have bought into the idea that having one of these things, but federated and decentralized, is a worthwhile undertaking, as opposed to having the public square be owned by one company.

Scott: Right. Well, and as it grows, I think it will naturally become easier. So, for example, I can imagine IxDA, for example, having their own Mastodon server, right? And they actually have their own criteria. “Do you belong to IXDA? Are you a paying member?” And so forth. And then anybody who’s in that community, it’s easy, just go join IXDA.

So I would think that as Mastadon grows and more organizations get their own Mastodon servers, this signup problem will naturally get better. It’s just this kind of… as they call this, you know, “eternal September” that we’re having right now where everyone just right now, there’s a huge rush for the doors. But I am hopeful that as we get more and more of these…

Was it Jeff Jarvis who actually suggested the one thing newspapers could do would be to have two different servers, one for all their journalists and then one for their community? I mean, how cool would it be if a local newspaper had its own. And then, it’d be like an open source NextDoor. And so, I would think that as we get more and more of these well-published trusted entities creating instances, this problem could get significantly better.

Jorge: I agree and I’m very excited by the energy that I sense in Mastodon.

Scott: People are super excited by this. Yes.

Jorge: Frankly, it reminds me a little bit of, the era in the web when we were, well, I’m still doing it, but when more people were blogging there was and this kind of decentralized sharing.

Making money

Scott: To me, the big advantage of open source is that it allows tiny things to be explored. And the fact that, for example, I can go to Elastio and hit a button and install my own Penpot instance, so I’m running my own personal private copy of Penpot is amazing, right?

And then starts to talk about, well, what are these niches — because you don’t care about money — that you can explore that means that we can now start to build very private-preserving servers with our own things on it. So I think Mastodon is the tip of the privacy iceberg, and there’s so much more that is uncovered when you don’t need to justify a lot of money. To me, that’s the work I want to be doing.

Jorge: I’m trying to put myself in the position of folks listening in and they might be wondering, “Well, it’s fine and good to do this without concern for the money, but, you know, I’ve got to pay the rent and where am I going to make time to actually do any of this stuff if I am not going to be compensated?”

Scott: Oh, I think that is one of the biggest issues. So, I think there’s at least two different personas with open source: there’s those people that just basically work part-time and so they have a full-time job and they just feel strongly about these things and do what they can. And I think that’s perfectly fine.

And… Well, I’m sorry; there’s probably three. The second is there is now funding in place to hire people to do open source projects. So, I think that helps a lot.

And in a side parallel, you’ve got what they call the open core model. There’s open source projects like Penpot or Home Assistant that have the completely open source model, but they have money on the side. They have a separate thing that they do that doesn’t compromise the open source, and now they are hiring people. So money can come into open source, but it’s just done in a way that’s ethical.

And then the final one is I think people like me, which is semi-retired. Which is like, “Don’t pay me. I don’t care. I’m just looking for something ethical to work on.” So I think there’s a range of people and they’re all going to find their level.

Jorge: Another project that comes to mind that has an interesting business model — I mean, there’s no other way to put it — is WordPress, right? Where they provide WordPress as a service that they charge for.

Scott: That’s exactly the open core model. Ghost does that as well. Penpot is considering it. Now they’re going to an enterprise model and that’s the Figma equivalent. And so there’s a ton of people that are following that model and my guess is that there’s going to be some good self-perpetuating, self-funding models based on that. Red Hat even did that, by the way, Linux.

Jorge: It’s really exciting to consider what alternatives there might be, not just to software, but to the means for funding software development, right?

Scott: I think everybody has this itch in the back of their head that, “Is this really how we want to be working for the next 50 years?” Something just doesn’t feel right and I think we all feel that. The question is what are the alternatives? And I will not say that open source is perfect right now, but it’s a prototype. It’s a good direction that we can move towards and a lot of good companies are being built on it. So I think it’s worth looking at it.

Jorge: And to your point, it does feel like it’s early days and it is an open platform. How can designers help? Because I do sense that there is going to be design help needed in order to allow systems like Mastodon — it doesn’t have to be that one, but all other open source systems — to become more widespread. What can designers do to help?

How designers can help open source

Scott: Well, I’m starting by basically just making noise on Mastodon itself, and I’ve already had some conversations that were really eye-opening. I mean there was this kind of initial flow of original Mastodon users. It was kinda like, “Well, get good.” You know? And I’m like, “Really? Are you going to go there?” But that’s actually faded away a little bit.

I think people understand that there’s a need in just getting that understood is… I’m having a really interesting conversation with a few people online about what does it mean to do a quote tweet, which is anathema to original Mastodon users. And there’s a discussion of, “Well, what’s the pros, what’s the cons?” And so, several of us are having a side conversation. What we’re trying to do is just to put together a proposal.

When in doubt, produce something that people can point at, right? So we’re going to have a little side meeting in a week or two. We’re going to produce a little Google Doc or something, and we’re just going to just send it out and say, “Go throw rocks at this.” So, I think Twitter encourages people to bitch, right? And that doesn’t do anybody any good. And so, I think what we’re trying to do is to move towards concrete artifacts.

They don’t have to be the answer, but they can be an answer that then gives people vocabulary. If there’s one thing I’ve learned in my writing that seems to help is when you provide structure and vocabulary. It doesn’t mean it’s the answer, but it gives people tools to talk about better ones. And so that’s where I’m at right now. Banging the rocks together, trying to see where sparks are and finding like-minded people to produce some things.

Jorge: This is fantastic advice. I love this idea of providing structure and vocabulary because it’s right up the alley of folks who are into information architecture.

Scott: Yeah!

Jorge: And I also love the idea… I’m going to try to… I’m going to sumarize it by saying: “Don’t complain; make.”

Make without being attached

Scott: Right! Exactly. And make without being attached. I mean, we don’t know what we don’t know. We effectively have to prototype our way intellectually out of this problem. So build something and see what happens. But don’t be too attached to it.

Like, this morning I just tweeted something about how to do UX bugs in open source and I already got a lot of comments back and I’m like, “Oh shit, I didn’t get that right. I should have done…” You know? So, I’m now reformulating what I said. So that kind of evolving approach I think is a lot more productive.

Jorge: And it’s a very designerly approach to working, you make things, you get feedback, and you refine what you’ve made.

Closing

Jorge: So where can folks follow up with you if they want to get involved in any of this?

Scott: I have a blog at jenson.org. I’m temporarily at Twitter. I’ve been on Twitter since 2007, you know, I’ve got a lot of followers. I mean, I’m really proud of what I’ve built up there, but I just don’t see… you can find me there. But I’m also on Mastodon. I think if you just go to Mastodon and you search for Scott Jenson as one word, it might pop up. I mean, in fact, that’s a good question. I think it’s an issue about how do you find people on it. But if you go to jenson.org you will find my link to Mastodon, so that’s probably the shorter way to do it.

Jorge: And I’ll also include links in the show notes to your account that folks can follow you there. Scott, it’s been such a pleasure talking with you. Thank you.

Scott: Oh, thank you for having me. It was a great conversation.

Jorge: And thank you for listening. As always you can find notes and a transcript for this episode at theinformed.life. If you’d like to be notified when new episodes come out, please subscribe to my newsletter at theinformed.life/newsletter. And if you’re enjoying the show, please rate or review it in Apple’s podcast directory. This helps other folks find it. Thanks.