Transcript
(00:02)
My name is Lauren, and I am the design director at Thinkmill. I think you’ve heard about them, a software company. Before we go any further, I’ve got to disclose to you, I’m actually in a new job at the minute. I started five and a half months ago when we welcomed a small little humanoid into the house who doesn’t pay rent, and last night decided to wake up and be like, “hiya!”, every two hours. So, yeah, feeling great today. I’m having a new problem now where I literally can’t remember words I’m trying to say. So, when that happens invariably in the next 20 minutes, heckle me, please. I actually appreciate it. Yesterday when I was trying to practice for this, I kept getting the wrong word in place of another – differential and deferential, and difference, they all got mixed up. In your brains, just go, I think she meant this. And I would really appreciate it. If you are parents and have looked after small children and know how to make them sleep, please come talk to me afterwards because I can’t figure it out. So yeah, in this new role... failing at it. But when I come back to work, not too bad at it.
(01:14)
As I said, I’m a designer. Product designer. I specialise in user experience and user research and generally for functional products. That’s my happy space. Give me a form and I’m your gal. I get overly excited about sorting content into simple flows and making sense of it. Or really nailing an information architecture. Or even, you know, you can see me having a little dance if I’ve reduced the certain amount of clicks it takes to enable a user to achieve an action.
But I’m just a designer. And I’ve been just a designer since I graduated in 2008. And was recently, up until very recently, working in design-led environments. What I mean is design-first. We start with design before we start talking to any engineers. And then in 2017, I had this bright idea to join Thinkmill. And Thinkmill was a pure engineering-led company. At the time we were mostly software engineers. There were few of those engineers who’ve come from design, and then shunned it and gone, yeah, no. And rock star into the engineering space (generally in the React space as well, just saying). There was a lot of design that was happening every day, but it was kind of happening in pockets. And it is fair to say that the design practice was somewhat basic, somewhat scrappy, and somewhat meek.
Basic in that, yeah, it was UX/UI. But there was only a little bit of research (not in a rigorous way) going on, and it was heavily informed on intuition. Which isn’t always a bad thing. Scrappy in that there wasn’t a shared, cohesive view of what design at Thinkmill was. And meek in that it just wasn’t confident that it played a crucial role in making good software.
(03:19)
Now, I was invited in to change that. To develop a more mature shared and confident design practice in that engineering-led environment. So, that kind of became my brief. Introduce a proper design practice in an engineering-led environment. So, not scary at all. And not terrifying.
A quick note before I go any further. These things [Components, GraphQL, React], they are absolutely lovely. And I think they’re absolutely amazing, but I’m not going to talk about any of them whatsoever. Because everyone else who will be up here at this conference will do so much more knowledgeably and eloquently than I could. It would be funny to see me try to do it, admittedly but I’m not going to. I think they’re amazing tools to work efficiently at scale. But I’m going to talk about engineering-led design.
(04:09)
Engineering-led design as we see it is a mindset. It is a mindset embedded into shared behaviours. Now, these behaviours are what we’ve established and identified along the journey since I joined Thinkmill in 2017. They are becoming the vehicle in helping us to introduce a proper design practice into a company full of engineers.
These are particularly useful to use when you are in the context of solution design. In an engineering-led environment which many of you I imagine are, or when you have designers on your team. And I am hoping there are a few designers here. But if not, it’s when you come into contact with them.
Please bear in mind the other thing. I am a designer talking to a room full of engineers, I’m guessing. And these are basically going to be practical things that you can do as an engineer. But especially as an engineering leader. But they are just the starting point. And this mindset does run a whole lot more deeper. And if you want to talk about it in more specific detail later on, we can do so. These behaviors are a starting point for you to get going with.
(05:37)
So, let’s dive into them. There are five that we’re going to cover:
- Context together.
- Create a dictionary
- Teach as you work
- Play it back to validate
- Break down language barriers
I’m gonna kind of unpack them as we go.
(05:53)
Context together
Shared context isn’t just valuable. It’s really, really valuable. When adopting an engineering-led design mindset, we gather context together. In the early stages of a project, when we’re still discovering the requirements, the constraints, the opportunities, all the unknowns, the known unknowns, etc., getting this shared context as a team is really hard.
It takes time, it takes focus, and it takes a lot of brain power and attention. But so much depends on having shared context for making good decisions. Technical decisions, product decisions, business decisions, strategic decisions, timing decisions, release decisions, all the decisions.
If we can ensure that we have shared context as a multidisciplinary team, we can be confident that when we’re making decisions, that are design, or technical decisions we’re using the same inputs and parameters. So, what does it mean to context together in practice? Well, context together means everyone, and I mean everyone, attends all context-gathering meetings early on – regardless of if the focus is design or engineering.
This is vital because what it results in is on one hand, you’ll have designers like me who immediately become informed about technical constraints. And about what hard problems are going to be as we go into them. And for me, I get a bunch of engineers who become very acutely aware of user needs. And what they’re going to have to have down the track.
So, that means that those engineers are in a much stronger position to be able to spot relevant technical overlaps much, much, much sooner. Context together means engineers are in the room when we do research. This is key. We need engineers to see what designers are seeing.
A quick interlude here. This is some research that we ran. And the majority of the team that attended that research are engineers. They saw what we saw. There was zero translation needed after the fact. And the last thing is that context together means educating your designer about the hard problems in software, in real time.
Designing with dates? Help a designer understand why time zones are hard and why you can’t just use server time. Because I know you guys know that. But we probably don’t. Contexting together prevents gaps, prevents rabbit holes, and tangents in the early stages of a design project.
(08:54)
Create a dictionary
I hope that’s self-explanatory. Naming is hard. Using precise language is very important. But in design and technical practices, the same terms such as users often have different meanings but come up quite often. And I think it’s fair to say that we’re both quite guilty of using jargon from time to time. And look, creating a dictionary, you might be sitting there going “You know what? That sounds like busy work” and I can absolutely assure it is not. It is really simple. Yes, it takes some time to maintain. But the payback is absolutely huge. So, what this means in practice:
We create a shared document using a low friction tool that everyone can use. By low friction, what I mean is that if you guys have some designers on your team and they’re not comfortable on markdown or GitHub, please use that. Use something they are comfortable in so that they can be part that have club. We define project-specific terms. Like data structure, interface elements, etc. This is because using accurate language is very important. What this dictionary gives you (even a rudimentary dictionary) is it makes using that accurate language much easier, and makes sure that the team can adopt it much, much faster.
This next one is really important. Always be a diva when defining your freakin’ acronyms. We all have them. I got them, you got them, everybody got them. And sometimes, you know, it’s a little embarrassing to put your hand up, I’m sorry, what does HTTP mean? But it is important for us to be able to have those conversations. And it’s also important for us to realise that, *“oh, your acronym is the same as mine, but they mean completely different things”,*because that’s expensive down the track. Such is why we need to REST all the time (yes, I did ask that question once; don’t laugh; it’s not nice; safe space).
And lastly, define practice-specific jargon and note reserved words. So, in user research, for example, there are these three words: Observation, finding, and insight. They mean completely different things. An observation is a similar thing, a finding is a group of observations, and if you take the time to figure out what that means, it might turn into an insight. That’s pretty loaded. These are also everyday words. If we don’t reserve those meanings how will they know what we mean with an observation versus an insight. The weighting is very different.
Equally, accessibility, it’s got a lot of meaning behind it from both a technical and design point of view. We need to make sure we reserve words like that so that everyone is on the same page at all times.
This is an example of a dictionary that we did for a project. You can see some definitions around the schema and acronyms, etc. And we just used Notion for this tool. The important thing here is that we created and maintain this across practices, both in design and engineering. And we pretty much used this every day. We use this every day from the beginning of the schema design through to the design system build.
And this wasn’t just a nice to have. It was a foundational item. Now I want to note that this kind of basic dictionary evolves into a much more sophisticated source of truth that will be housed in many places such as the design system, schema, and now the documentation. But at the start, it’s just a page with definitions. But don’t underestimate that page. Because it is a crucial bridge between design and engineering.
(12:50)
Teach as you work
What this refers to is the acknowledgment that as designers and engineers, we have deep knowledge and expertise and that we cannot become experts of each other’s domain.
I’m not going to become a React engineer. And you probably don’t want to become what I do. And that’s okay. That’s cool. But what we both need to do is learn from each other.
Because you know what? When we do, that’s when the magic really happens. In practical terms, what this means is injecting short, structured lessons into your day-to-day work. In Thinkmill we tend to call them like little asides. They’re usually 30-minute sessions, delivered by an expert on the team, whoever is most knowledgeable, into a topic that unlocks something so that we can actually make sure that we’ve moved forward from not being able to understand to all going, ah, the pennies drop.
The trick here, though, is to frame them not as a distraction, but to make them a key part and a first-class citizen of every day work. This is just an example of some work that we did on a medical annotation platform. For those who don’t know what a medical annotation platform is (and that was once myself) that is when you go for a scan and they take the scan, a radiographer has to go through it and mark it up later. Now, there’s a lot of UI work based around processing radiological images in this. And if you know anything about radiology, you know that involves basically finding something in a 3D space A.K.A. spatial localization.
So, this is a bit of a whiteboard session with myself and the lead architect on the project called Tim. He’s basically breaking down the concept of spatial localization, so that we together could potentially construct the rudimentary form of the UI. From a design point of view, what this unlocked was an underlying foundation that I could use as constraints as an inspiration to fly forward though. It was time well spent.
This is another example, Tim the architect explaining the basics of graph theory. I didn’t need to know the whole shebang, but I needed to know some of it to move forward.
(15:40)
Play it back to validate
No matter how much we context together, and create our shared language through this diligent use of a dictionary, or be open to teaching each other in all of these little asides; we will always carry a lot of assumptions.
Sometimes these are explicit and documented. And that’s fabulous. But sometimes they are implicit and hidden, which is less fabulous. Playing it back is a way to reveal your thought, rationale, your logic, your steps. The parts that got you to that point. And doing so with your team regularly is a great way to uncover the hidden assumptions. Those unknown unknowns which help you to avoid very expensive mistakes.
In practice, what this looks like is: I’ve just designed a UX workflow. Awesome. Before I lock it in, I play back the thinking to the engineers or the architect on the team, so that we can validate my thinking and assumptions against things like the data model. What this might show is, ah, the data model doesn’t actually have a provision for this at this moment, we can’t account for that. Which may mean that I need to change my design. Or it might mean that we need to change the data model. But either way, we spotted it early.
The second thing to think about is begin a sentence with, “let me play that back to you”. Actually have a go at playing back what you understand back to them. So if an engineer makes a change to the data model - how might this impact the UX or the UI and play it back and check that we’ve both got it. And the other thingto do is keeping this front of mind. Do I need to go and talk to the engineer? Do I need to talk to the designer? Will this impact? If you get that gut niggling feeling, do it. It might take 10 to 15 minutes, but you might find that you have a big saving after it.
(17:33)
Break down language barriers
Now, between our two practices, there’s a language barrier problem. I know we all know this. And in an engineering-led environment, when it’s actually engineers who are the majority, and designers that are the minority, you, the engineer, need to be the translator. That’s on you. You need to be in a heightened state of awareness. Taking extra care with empathy to rephrase or reframe in a way that your designers can come to the table and actually get on board. Because if the designers aren’t understanding, it’s not because they’re dumb. It’s because it just hasn’t been explained well enough for them to be able to make sense of it.
So, here’s a few sentences you can try to get over this hurdle.
- “Did that make sense?”
- “Can you play that back to me?”
- “Can I explain it in another way?”
You’ll be really surprised how powerful doing this can actually be.
And pro tip. Most designers, they actually think visually first. Stick men are fine. If you can draw this, it will actually help to unlock it a lot quicker so don’t hesitate to pick up that pen and go to that whiteboard. Let me just give you an example. And this is a real-world example. Take the concept of one to many [relationship]. Imagine we’re in a conversation where Content is 1, and Author is N. That all makes sense to you. That doesn’t make sense to me. News flash, I went to art school. I understand a lot about products, a lot about people, and how to get people and products to work together. But I didn’t study relational databases, and I’m probably not going to either. So, we’re in a bit of a gulf here. Sorry. You, the engineer, [need to] unpack this for me. Ah, a Post has a single Author, an Author can have many Posts - amazing, I got this. Now I can contribute. When the Author wants to transfer the Authorship to somebody else, what happens? Is there a provision for that? What if the Author wants to edit that later? How do they do that? Is that sorted? How are we going to grouped these, under the author or something else? Can I have categories?
(20:01)
And suddenly we’re back to beautiful greatness, heading towards the product of our dreams.
So, engineering-led design. These are the five very early stage kind of behaviors that you can really champion. So why bother?
Well, as engineers, what you’ll get out of this is you’ll receive designs that are much more in line with engineering thinking. They’ll be more viable for the schema that you have actually undertaken. As a multidisciplinary team, you’re going to be able to discuss constraints and negotiate tradeoffs much more effectively and efficiently than ever before. You will be able to make better decisions in a faster context. And you’re going to uncover things that you didn’t know were there.
(21:06)
You’re going to get a lot more wins, a lot more bang for your buck. And ultimately, I promise, you will have a better time doing it. I’m no longer just a designer. I’m an engineering-led designer these days. And when we adopt an engineering-led mindset, design can thrive within an engineering-led environment. And as engineers, you’ve got the power and are crucial to making this change. Give these behaviors a go. You’d be amazed at how much it’s going to improve your products. And when you do, come and tell me about it because I will be dying to know. Thanks so much.
