Designing like an Engineer
Designers and Engineers have a lot in common, they’re cut from the same cloth. They’re quite close family but they’re definitely good friends - they share the same interests and their approaches to work are almost identical.
Regardless if you’re an illustrator working on a new marketing campaign for a startup or a java programmer building a trading pipeline for a bank, projects and pitches usually begin with a kickoff meeting with your new client. Beyond the initial ‘vibe check’ to figure out if you’ll both get along and be able to deliver good work, your objective in this session is to be a spy. By this I don’t mean steal their secrets and sell them to the competition next door - your goal is to listen beyond what your client is asking you to do and figure out what they actually want. Some clients are incredibly clear and know exactly what they want down to a tee, but in my experience most are juggling a mix of desired outcome, timelines, politics & budgets and they’re asking for the benefit of your experience to figure out whats practical. Listen carefully, ask open-ended questions, then gather and distill that information so you can walk away with enough to design an effective solution.
To do this, you need to do a few things:
Diagnose the Problem — What’s the challenge you need to tackle?
Distill the Goal — What is it? What will it do? How will we tell if it worked?
Define the Scope — Define what it can and can’t be.
(Optionally) Iterate — Try it out and adapt.
By running through these things, your design process will be hyper-focused, and you won’t waste time chasing bad ideas.
1. Diagnose the Problem
Most often, clients are experts in their own domain but they need assistance to convert that expertise into a product. A chef may have a Michelin star but they’ll still need an industrial designer to bring out their own line of cookware. This is why you’re here, you’re equal parts translator and builder, you bring the how to their what.
Whats the challenge you want to tackle?
Both design and engineering are problem-solving. With every project, you’ll have a set of challenges you’ll need to surface and address for your client. After all, that’s what they’re paying for. Here’s what you need to know to diagnose the problem you’re trying to solve: the who, how, and what.
Who is the Target Audience (The User) and why is this important to them? Why do they care?
Its rare that your client has just one user in mind, usually there’re a few with potentially competing interests and objectives, and targeting all of them can make a project needlessly complex for diminishing return. Work with your client to identify the top three kinds of users and prioritize the most important one - what will give you the biggest bang for your buck.
What does this project need to communicate? How should the audience feel after?
If there are too many objectives in play, prioritize and define the hierarchy with them. This will be like pulling teeth, but its necessary and demonstrates that you’re a partner in the project - rather than just pushing pixels or writing lines of code, you’re collaborating with your client to provide clarity.
Now you have an objective, how will it be executed? In what context? What part of the sales cycle is the user?
Depending on the context, a user or potential customer will engage with your solution in a different way. Is this a new customer and you’re working on a YouTube pre-roll ad? You need to hook them in 5 seconds or they’ll skip. Are they existing customers and you need to demonstrate you’re listening to their feedback? You can take your time and ship features they’ve asked for. I’ve often seen this in action at hackdays and game jams - a project could be technically impressive but not very flashy and would be judged less favorably than something with more visual panache.
Its important to pay attention to the sales cycle here too. Depending on what stage the customer is in, they’ll have different needs and intentions. If it’s early in the sales cycle — they need to be made aware. If it’s late– they’re ready to buy.
Now you’ve explored who the customer is, what you’re trying to do for them and broadly how you’re going to do it, you’ve identified your challenge. That probably took a lot of discussion - time to refine those conversations down into a goal.
2. Distill the Goal
Once you’ve got an idea of the problem your client wants to solve, the next job is to distill that conversation into a goal - a north star that everyone can agree on regardless of expertise.
If you ask a client “whats your goal?” without first discussing the problem they’re actually trying to solve you’ll find they’re quick to give you a goal, and that goal is almost always not the best way to tackle the challenge.
Most people, myself included, are prone to solution-izing - using their own domain expertise to try to solve a problem in another domain. To give credit due credit sometimes these solutions are great. I’ve been pleasantly surprised more than once at how good doctors are at solving mechanical engineering problems (I suppose we’re just different kinds of machines). Far more often though these solutions fall short. Instinctively an experienced designer or engineer will have a quick internal-giggle at the proposed solution, but hear your client out - while their solution might be terrible they’ve encoded a lot of subtext into it about whats important to them. Deconstruct it, then help them prioritize what they want and give guidance on the tradeoffs.
Your goal should be one sentence that everyone can agree on, more than one sentence and the interpretation gets fuzzy leading to equally fuzzy solutions. It should not only include the deliverable outcome (the thing your client is ultimately paying you for), but also the main reason you’re undertaking the project, and some way to measure how successful you were at achieving that goal. Often goals will have a time component, but they don’t always have to.
Your goal should follow: “This <X> will <Y> so we can <Z>”
A couple of examples from projects I’ve worked on:
“This chat widget will let customers talk to us directly so we can get product feedback faster”
“This teaser will announce our new game at E3 so we can build hype for release next year”
“This keypad should be quick to release so we can test the waters in the desk accessories market”
Now you’re all on the same page about your goal and how to measure success, you’re likely already figuring out a plan in your head before the meetings even finished. Hold that energy, there’s one last step.
3. Define the Scope
Problem-solving & design thinking take a lot of time and effort. Even if you’ve identified the challenge you’re taking on and agreed the goal you’re all working towards, its easy to spin your wheels exploring solutions in an unbounded problem space. You’ll save a huge amount of time and effort by narrowing the possibilities of what’s valuable to explore before you begin. Its a balancing act, but you’ll spend less time theorizing about problems a client may have in the future and can focus the solution they need now.
So how do you filter out possible solutions? There are a few key questions you can ask:
What the boundaries we need to work within?
What are the absolute no-gos?
What can it look like?
What can it sound like?
What should it feel like?
As before when discussing the goal with your client, things will get tricky here and you’ll need to look out for coded language; words like “Modern”, “Efficient” or the perennial “Magical”. These are words that have a lot of room for subjective interpretation, “Modern” to a coder working on AI tools is worlds apart from what a potter making fine tableware thinks of as modern. Get specific with examples and break it down into simple language.
A client who wants their mobile app project to be “Efficient” could mean that they want it to be technically efficient, a very small download that uses little memory and gets the job done quickly. Equally, they could be switching “efficient” for “responsive” aiming for an app that feels very quick to use, so adding fast animations to make the app feel quicker with the tradeoff of a larger app install size might be the way to go.
Again, use your detective skills, if an answer doesn’t feel like the full picture, dig a little deeper into the wording. Your whole goal might change, but its worth finding that out now rather than a year into a project.
4. (Optionally) Iterate
One of the best ways to figure out if your solution is a good one is by actually trying it out.
This is pretty common in the tech and advertising worlds, building an “MVP” and iterating based on feedback or running many campaign variants to figure out whats landing best. This it can be a lot tricker when you’re dealing with physical products and minimum order quantities though.
Iterating doesn’t always have to mean shipping to customers, you can often do it internally even if you’re dealing with physical products - you’ll see this often at product companies like Apple or Ikea before they ship at scale. The key is to build a version of the project that fulfills all of the criteria you set out in your goal, then use the last part of your goal to measure its effectiveness and use the feedback to make another attempt.
Speed is the important factor - the goal and type of project you’re working on will dictate what you’re able to change to enable you to iterate quickly. Sometimes this can mean sacrificing fit-and-finish producing a lower fidelity version of the product to test functionality, something that still fulfills your goal but perhaps isn’t as elegant. Other times this might be a much more refined version of the product with a lot of attention paid to how it feels to use, but lacking functionality (an experience prototype vs. a service prototype). Each give valuable information that will help you and your client refine the solution further, potentially leading to a follow-up project.
Review
You now have the essential building blocks to create an effective solution. Let’s quickly review the key steps:
Diagnose the Problem — What’s the challenge you need to tackle?
Distill the Goal — What is it? What will it do? How will we tell if it worked?
Define the Scope — Define what it can and can’t be.
(Optionally) Iterate — Try it out and adapt.
With these things established, you now have a clear, narrow target to hit when you begin designing. This is the blueprint for you and your team to follow, something you all agree with, a banner for you to work under and measure your success. The goal should drive everything you create and should be filtered by the criteria you’ve collectively established.