Mindful Design for Developers

• Mindful Design book
• Mindful Design resources
• Alicia Laidacker's talk in 2016
• The Rise of the Systemic Game - Game Makers Toolkit

OK. My name's Scott, this is my dog, she's called Lana and I love her, you should, too, Mindful Design is my book about bringing cognitive science and positive psychology into design and it was born from being disenfranchised and disappointed in the application of behavioral science in technology.

Lots of exploitation, lots of coercion and thinking there has to be a better way, and there is, and now it's a book. You're welcome.

Now, I'm not a big fan of self-promotion or book promotion. It gives me the ick, this isn't going to be a half hour talk of me asking you to buy my book. I'm going to get a little drink of water. Now the clicker's not working.

This isn't -- that was Sara's clicker, I tried the other one. Yeah, if you do want to check it out, if you like this talk, if you like the idea of Mindful Design, please, do check it out. We've got a toolkit in Figma, we're working on getting it into open source tools, because quite frankly, fuck Figma, and the end of this year, we are releasing a video course, as well.

So if that interests you, go check out, it's all on the site, thank you. Mindful Design for developers is what I was going to talk about today. Dave suggested this title to me, yeah, great idea, I'm a developer myself, I spent my entire career writing code. I'll go through the book and separate what designers should care about from what developers should care about, and cool, I've got a talk.

But the more I tried to do that, the more shit it felt and more kind of -- I thought for a while now. I hate to be the one to break it to you, but you are probably a designer. I know some people don't like this type of talk. But if you are a frontend developer, there's a big chance you're making design decisions. They might not be the traditional design decisions that you first think of, like color, typography, shadows, all of that shit. But some of the more overlooked decisions that kind of tend to get lost in transition, especially if you have a very typical, over the wall handover type of process.

So I want to ease us in with a fun game. Take a shot for every one of these you've had to assume responsibility of. Animation time is ease in functions, heading orders in typographic elements the designer forgot to mock up, cross component interactivity, keyboard navigation, shortcuts, every fucking thing about accessibility.

Now, it might not seem like it, but these are all design decisions, they all impact the experience someone has with the things we create. And as developers, we are just as accountable to this as designers.

And I want to highlight this, I'm going to talk a bit more about this throughout this talk. But I want to get this up front, the way we decide to build something and how much of the underlying system of our product and the underlying system of the browser that we expose to people. That's not something we speak about a lot. I want to talk about the state of the web. Feels like a good enough conference to do that. And I hate the state that software service left the web in. I hate that we use React for everything even though it's fucking shit.

I hate that everything looks the same, the teams, the organization structures look broadly the same. It's the same investments, all trying to rule the world and we report to execs who are almost always white dude man children who look like they would ride around on a trike if they wouldn't get bullied. And you know it when you see it.

This is a bit doom and gloom. I'm not ambiguous, I'm not talking about web standards, web standards are fabulous. I'm talking about standardization and convergence that I'm seeing in this industry of how we work in this convergence of what success looks like. I don't know what that squeaking is, but that's strange.

But yeah, we try to repeat the success of others by doing what they did even though so much of that success is riddled with unchecked privilege and survivorship bias. We try to repeat what they did, but we might not have the same background as them, might not have the same safety nets to fall back on, might not have the same network as them, and we don't have the same brain as them because probably we weren't kicked by a horse in years. But a process by LinkedIn thought leadership, a lot of these things become industry standards. But when we all work the same and think the same, we really do lose something.

I think there's so much potential with web technologies right now and we're kind of not using them in the tech industry. We're not using them to their full potential. So I want to kind of have us reframe for a while how we think about our work and how we think about our impact on the world.

This is first place I want to start. I don't say you're probably a designer facetiously. I actually do mean it. We're told that design and code are these separate disciplines that there's a hard line between the two. But why?

Why are we made to think it takes something special and magical to be a good designer who can write good code or a great developer who can draw sick rectangles? And why do we call it a unicorn when just good designer or developer is perfectly fine.

And for something so mythical and rare, I personally know a fuck load of so-called unicorns. And only like three of them are actual fairies.

And I really do believe this, I think that every frontend developer is already capable of being an amazing designer. We kind of default the visual still even now, the state of the industry, we think about the visual stuff, the motion, but there's so many in betweens there in design that we're thinking about.

That go into designing the environments we create, where your knowledge of the browser, your ability to write and understand code and your knowledge of accessibility already set you up with a bunch of tools to actually just be great at design now.

And, this is a big thing for me, you can't be what you can't see. The more that we try new stuff, the more that we build fun things and interesting things, the more that people are going to see that and see its value. And the more we approach things differently while still achieving success, the more we can show that's possible.

So, I want to talk today about systemic design and this is an idea that's been rattling around in my head for a while now. And I want to talk a little bit about how it can present ideas for this true convergence of design and code or designing with code.

And how we build on top of the amazing technology we have in the browser can lead to better experiences for folks. This is going to be a pretty hypothetical talk. It's not super practical. But I will be sharing a bunch of stuff kind of as we go through, some links and stuff like that. So please, feel free to take a photo of the slide or check it after today.

And kind of browse through that and learn about that on your own time. But systemic design is all about seeing what we create as an environment. Now an environment is just a place where shit can happen. So it has objects that are placed into it. It has rules that govern how objects can interact with one another, and it has moments, these things that can happen that give some sort of narrative, some experiential quality to the environment.

And we can go a step further by focusing on autonomous environments. And these are places where action, possibility, and causality are prioritized, where goals can be achieved autonomously, and where human agency is preserved and respected.

And we get there by embracing nonlinearity. So if systems thinking in nonlinearity go hand in hand. Systematically, we're thinking about cause and effect, input, throughput, and output, that's inherently nonlinear. And of we're not constraining our thinking to the basic flows and steps that we might be really used to seeing.

So for a little while, at least, I want folks to get this idea of neat little user flows or interaction flows out of your head and just embrace thinking in environments, objects, and moments.

I want to touch on why this matters first. Why am I so focused on autonomy and nonlinearity. And to do that, I want to look at human motivation. And this is the only real sciency bit from the book I'm going to present today.

To explore motivation, though, we need to take a look at kind of where it all started. Which is behaviorism. Behaviorism is mostly outdated, it's pretty much a dead science. I am not promoting behaviorism.

I think the next few slides will prove that I'm not promoting behaviorism. But when I give talks about mindful design, I usually like to do a deep dive on this. But that's not the point of this talk. So, I'm going to very quickly give you the whistle stuff tour of behavioralism to move on to the fun stuff.

Pavlov's a prick, fucked around with dogs and gave us conditioning, learned stimulus that the dog learned stimulus predicts a reward that made its brain work to trigger Dopamine to go into do the work to do the work. That's Skinner, he's a prick, what if Pavlov but with pigeons? Electrified pigeons? I'm good science man. I think that's the exact quote.

So by fucking around with pigeons, gave us condition, his pigeon's driven by Dopamine, developed a compulsion to work. The other stimulus, a lever, and offered the reward or in Skinner's case, punishment, getting electrocuted, sick work.

And that fed into classical conditioning and introducing reward variants. Skinner and Pavlov together were the Dopamine boys and everything they did showed Dopamine's role in reward-seeking behavior.

So, I really want to focus on reward seeking, a lot of the time, for some reason, like Dopamine is famous in tech. Everyone seems to fucking write an article about it, they usually get it wrong. It's reward seeking. If you're ever reading an article that calls Dopamine the reward chemical or even worse, the pleasure chemical, just close your laptop, go for a walk, dissociate for four hours, whatever you need to do, forget it exists. It's all bullshit.

Dopamine is what has us get up and seek a reward, what makes us do the work. There's an experiment on rats, that's dogs, pigeons, and rats all been fucked over by behaviorism that prevented them from being able to synthesize or produce Dopamine, and what it showed is if they were hand fed, they displayed what is known as a hedonic response. They enjoyed it, they still enjoyed the experience of being fed.

What they didn't do is get up and seek the food. So if you're going to give Dopamine a stupid fucking name like the chemical, it's more likely to call it the compulsion chemical. And this is kind of where tech adopted this kind of, like, Dopamine reward application. It's all around compulsion and it's been applied to so many various shit. Things like slot machines, social media, and habit-forming products.

This is the eventual culmination of compulsion in design and technology, and I've gone through that quickly. But -- can anyone just recall what these three things have in common? Yeah, they're all shit. We're moving on.

So I want to take a look at self-determination theory. And that's something so much more suited to what we say we want to achieve with design. And it's a theory of intrinsic motivation. So a lot of the behaviorist stuff, it was extrinsic motivation. Things like -- kind of when they move towards, human studies, things like offering people money to do stuff. But intrinsic motivation, these internal machinations that govern our desire or willingness to perform tasks.

The only real thing you need to know about intrinsic motivation is it is incredibly more impactful, all things equal, than extrinsic motivation. And there are three key factors to self-determination. And if an environment can give us any combination of these, there's a good chance it'll be intrinsically rewarding to existing, to perform tasks in, to do the work in.

So the first one is autonomy. To feel in control, to act with volition, and to achieve our goals on our own terms. Then, we have competence. To show mastery and progression in the things we care about, to learn and to grow.

And then, we have relatedness, to find belonging, to be looked after, and to look after others. Aloma Medina is awesome, she's expanded on self-determination theory with the biceps model. It's focused around team building and creating good environments for teams to succeed.

But it suggests that people thrive in environments that give them belonging, improvement, choice, equality, predictability, and significance. And I think this, to me, is such a better model for what we want to try and give people, or try to have people feel a sense of when we design for them.

So what changes when we start designing for self-determination? This has been on my mind for years now. So much of what we're told is best practice in tech is based on this outdated exploitative behavioral shit. And it's from early stage design work through to success metrics, being impacted by it.

What happens if we say fuck that, I don't want to do that? I want to try something else. So this is where systemic design comes in. The whole focus around systemic design is on autonomous environments, places where people can potentially achieve self-determination to craft environments where that is possible.

And I think we can look at it as two broad disciplines and design in general as two broad disciplines, and that's sense making and play making. And I want to look at both of these in a kind of, you know, shallow-ish sense and show if we change our thinking a little bit in each of these stages, how we can get more towards that intrinsically motivating experiences.

So starting with sense-making. Sense-making is basically saying, everything's fucked, let's unfuck it. Read this book by Abby Covet, it's incredible, around information architecture, but it presents it in such a zoomed out and interesting way.

But yeah, she really, really dives into sense-making and what it means in this industry. One way to unfuck things is by understanding systems. And there are a million different ways to understand the million different systems. But I want to look at today is viewing your product as a system and why that can be important.

And especially, relevant for developers. So, our product will have a system model and sometimes, this is a diagram, sometimes, it's just what your team knows about how the product is built. But there is always a system model of a product in some way. But you have things like its objects, inputs, throughputs, outputs, all that kind of stuff. And this is often the closest kind of asset you produced to how your product actually works at a technical level.

And it can often resemble something like a schema. On top of the system model, we have our designed model, and this is an abstraction layer that allows people to interrogate the system or effect change upon the system. This is the purest representation of what we try to do with design. It's take complex systems and give people access to those systems that they maybe would not have without technology.

The flip side to a design model is a mental model, the interpretation of your designed model. And influences what they believe is possible within the environment that you have given them. So this is probably the most famous designed model. So the system model here is data storage and retrieval. And it's zeros and ones on some kind of storage media, right? This isn't zeros and ones, it's pictures of Shrek. But this design model is based heavily on metaphor of real world files and folders.

And it's such a genius abstraction, especially at the time we first got into file and folder structures on such a complex system model. But this is also a design model on top of the same system model. Typing commands into a terminal window.

It's incredibly more complex and more difficult to learn, but it's also closer to the system model, which makes it a lot more powerful if you put the time into learn that. And again, it lives on top of the same system model.

Now, I think many of us here will be used to jumping between these two design models. You know, the GUI file and folder structure for kind of sending attachments, and typing NPM install for the tenth time today. But having the two design models coexist on top of the same system model is multi-modal design, and that is really good.

If you want to document a system model that then can lead to really fun, interesting, creative design decisions, check out OOUX, object oriented UX, it's an amazing way of having an unstructured representation of your product as a system. It kind of ends up looking something like this where we have objects across the middle there, we have the action possibility above it, we have data below it, we don't really care about data right now.

But, it's all unstructured, there's no hierarchy or taxonomy at this point. It's just an unstructured representation of the objects in your system.

And we can see these as kind of conceptual components. We know at some point if we're building a music app, we're going to need to build a song, we're going to need to build a play list, we're going to need to build and design all of those different objects. But right now, we can just think of them as kind of just these objects away from design, away from code.

We can take that a step further and look at them as systemic components. So, most of the components we make can have things like state, life cycle, but they can also be inputs to other components, or outputs from another component.

And these can, then, be placed into environments. And it's all very conceptual right now. But it's really important to be exploring this together, especially if you are a developer who works with designers doing this type of exploration before you get into prototypes or wire frames, you can have the vision of the system you're building on top of.

It also gives us organic relationships. How can these components coexist? How do they react to one another? And we can start thinking about that, again, really early in the process.

But we need to put these somewhere. And this is where placemaking comes in. Now, placemaking is a bit of a forgotten art, I think. And it's all about turning spaces into places by purposefully arranging elements within them and structuring a purpose or a narrative to a space.

So if you've got a big fuck-off field, congratulations, you've got a big fuck-off field, this is more of a space, it's ambiguous, you can the go to the field, all sorts of stuff, go for a walk, play frisbee. Dogging on a Thursday. That was fabulous. I'm shocked, now, I don't know where I am. This is versatile, it's also really ambiguous. If you take your field and you draw some lines on it and you put some goals down, then you have a football pitch.

This is a lot more purposeful, the way you have structured things in that space has turned it into a place where it's less kind of ambiguous and it's more implicit what you want people to do in that.

An empty room is more of a space. But when you place make inside that room, when you arrange furniture, decorations, all of that kind of stuff, it becomes a place, it has a purpose to it. And it encourages certain activities. Is it for entertaining? For cozy conversations? Is it for preparing and serving food? What you put into a space determines the type of place it becomes and how well you placemake within that place impacts the experience that people are going to have in it.

This is a space. A blank canvas. An empty browser tab. This is a place and it's fucking fabulous. I want to take a look at placemaking in action. And the best way to do that is through Pokemon, obviously.

So I was enjoying my yearly play through of Pokemon in yellow, I turned up late when they were giving out autism specialists. I'm reminded about something that really fucking bugs me with this game.

So, you're plugging along, your video doesn't start, yes, it does, you're on the SSI, you go bin dipping, nothing in this bin. You look in this bin. And there's a great bore. This is nothing amazing, but it plants a seed now. These have been placed into the environment, and we have updated our mental model of this environment of bins have good shit in them.

So, we make our way through the game, check in every fucking bin. Hoping that we find more amazing items. Does anyone want to guess how many more bins in the 80% left of Pokemon yellow have left in them? Yeah, it's fucking none of them.

This gets to me every time. My cortisol. I'm not stressed from the talk, I'm stressed thinking about fucking Pokemon bins. We have this mental model we've took from the environment, someone's placed this bin in there for us. We said, cool, right, I'll remember that later. And then every single bin you try after that breaks your fucking heart.

Systemic games is what systemic design is based on. What my idea of systemic design, at least, is based on. And these are -- tend to be environments that get placemaking and objects and systemic components right.

This is a great video by game makers toolkit, the Rise of the Systemic Game. I definitely recommend checking this out. It's a higher level exploration of how games are becoming more systemic and the impact it has on player autonomy.

It does lift heavily from Alicia Laidacker's talk in 2016. Please, watch this talk, it's fucking amazing. It really helps she starts by throwing shade at Elon Musk, but it's great throughout. And she goes on to say this. Systemic means there's a link between all of the systems in your game.

They've been developed and designed with the intention that one can influence the other. And she talks about things like game components and world components and how they can have inputs, outputs, and life cycles and how designers, game designers, then, place them into environments where shit can happen. Hopefully, that sounds familiar.

So what happens if we think a little bit more like a game designer? What happens if we think a bit more systemically about the environments we create? We know we have to craft these environments, we know that we have components that we need to place within them.

And to get extra special bonus points, we can allow those components to interact with one another in seamless ways. My favorite example of this is TL Draw. TL Draw is a whiteboarding app. You make whiteboards, little user flows and stuff.

This is what I said if I can make in TL Draw, the standard flow chart, nothing to see there, but this is what an actual intelligent person can make in TL Draw. This is a will fluid simulator that can be controlled by moving in front of your web cam in a whiteboarding tool. Some people might ask, why does this exist? To which I reply, shut the fuck up, it's cool. You like games? And this stuff is possible because TL Draw is built in a systemic way.

Elements in the environment have got these inputs, throughputs, and outputs, everything is potential little related. And everything is potentially extensible, and people have fun making this kind of stuff, like someone sat there and made this, fucking play to them, it looks absolutely terrible, but someone's been like, you know what my whiteboard needs? Collision and Mario Cart. At the micro-interaction level, that's probably a little bit more grounded. Is my video playing that will be grounded and realistic?

This is AIM.E. What we have here is a component acting as an input to a calendar slot component. Seeing it like this, you're like, yeah, fucking obviously. Do you know how many productivity tools don't let you do this? It seems so basic. But this is a much more streamlined and simplified way of saying, look what happens when we treat components in a more systemic way.

And it creates a much more seamless environment, it's just drag and drop, there's no complex user flows to go about achieving this. And this leads me back to this. How it's built is how it's designed. So much of good systemic design comes from making good architectural decisions.

If you're considering things like connectedness, statefulness, and interactivity early on, that is going to be incredible for the environments that you create. And they're just not things that are solved in a Figma mockup.

And you can do this kind of stuff, stuff like this only comes from an intimate knowledge of what's possible, especially what's possible in the browser. And these days, designers very rarely know intimately what the browser is capable of.

So when are they ever going to suggest it? If they see it in another product. We know the browser, it's where we live for 8 to 12 hours a day. We can do this kind of work, we know what it's capable of. And brings me, as well, to the idea that the browser is unique in terms of it being a space, but also, kind of a place some bullshit quote about limitalty in there.

A blank page is not just a blank page. I can go on a blank page, and start writing web audio code on someone else's website because I feel like.

There's so much of the browser's capabilities ready for someone who just happens to be on a web page. And we know how those things work. And especially, the way that different, like, the different web APIs work, things like the web audio API. We can use the web audio API, maybe not kind of always encouraged, but to create these auditory experiences, or enhance experiences with audio.

But it's almost just as easy to expose the actual capabilities of the web audio API to users. And this is one example that I think is just so fun, so nice. Josh is just stunning. And I really love this.

This has been enhanced with the web audio API, I'll just play it through now. If you can see as we go, we've got these little noises and stuff like that. But we get the side quest of the secret, and all of this is web audio API. It seems a bit silly, you know, but this is autonomous, I can do whatever the fuck I want for this.

It was just a really elaborate way to fuck you all over. But the browser, like I said, the browser is our bread and butter. It's full to the brim with these tools that help us create seamless, useful, fun, and autonomous experiences, and we don't need to gate keep that technology.

And, I still think that the browser is still the best design tool that we have. I think it's wild that we do so much of our work outside of the browser. Going back to game design, I just imagine someone having somehow, like an almost finished game before they ever pour it into a fucking engine, and it's like, why would you do that? The browser is our engine. Why are we waiting so long to get things into the browser when there's so much behind the scenes, so many capabilities to the browser that can help us create better things.

So I'd get stuff in the browser early, break the handover cycle bullshit. And I think it's also weird that we leave all of this early stage exploration to designers, they do personas and that bullshit stuff that no one tells them to do.

But our code explorations are almost always technical. Can we write the best API for this kind of thing? Exploring fun or interesting things that the browser's capable of in the fucking browser should not be revolutionary or weird, but it kind of is when you get to like SaaS product design.

We are the experts in this technology, but there's no rule that says we shouldn't let users harness the power of it. If we have a system model of our product, that has all the capabilities of the browser baked into it already.

So we can ask how much of this do we want to expose to users? What kind of ways can we enrich their experience? Whether that's for fun, product it, or whether it's just for necessity. And sometimes, it can feel like you're just fucking around with technology, it's not productive.

But so what? Not everything we make has to feel this KPI obsessed shit show of modern web tech. I'm not even finished yet. But when people ask why are you making this thing? Why are you doing it? It's fun, shut the fuck up, is a valid response. Having fun, fucking around, learning new stuff in an environment that's rewarding for you is an amazing feeling and you can take that stuff and start applying it to your so-called real work.

So that's me pretty much done. I'm going to leave you with this. A person is not a fucking edge case. If your designs empower disabled people, if they're usable for people with neurodevelopments, say the fucking word, Scott, if they're usable for people with cognitive impairments and neurodevelopmental disorders, you will be a better designer, and you will make better experiences. Accessibility is important, don't treat it as a bolt on, and give people the tools and environments they deserve.

You know what's possible, start exploring it more. Never stop fucking around, never stop having fun. And most importantly, never shag a (inaudible). Stay safe, love ya, bye.