More generally, any work that a developer does outside of coding will improve their coding. If they learn a bit more about the business side of the company, they will have better conversations with the business teams because they speak (some of) the same language, and the developer will be better at prioritizing their tasks because they consider business concerns in addition to technical concerns. The same for Design, hiring, or testing. The most important task at a startup for both business and technical people is actually talking to customers, which should drive both Design, Business and Technical decisions. Most developers avoid talking to their customers, or are prevented from talking to them by other folks at the startup. The author alludes to this approach when talking about Design. You can and should go deeper, creating customer personas and workflows (like one of those Great Designers) to understand your customers better. The more time you spend talking to and watching your customers use your tools, the better!
A very important step is buried right at the bottom:
> Hand drawing is ideal because everyone can do it, it's fun, it encourages simplicity, and it's easy to start over. When the timer ends, I show the work to someone or wait a while and review it with fresh eyes.
Working in a fast, low-commitment medium is key. It really doesn't matter what it is, as long as it's easy for you to churn out many ideas. It makes you more open to feedback as you didn't put a huge amount of work into it, and for the same reason others will be more willing to give genuine feedback about it. It promotes many iterations before you actually start building.
One step that could be added is spending a few minutes before starting the design phase is collecting context about the issue.
- Who is this feature for?
- In what scenario will they use it?
- What is the issue they're facing?
- Can I collect some real-world examples of people with this issue?
- How would this idea be useful to them?
It might seem really obvious at first, but as you get deeper into the design process it's easy to get sidetracked. Starting with a clear understanding of the user's problems makes the whole process go soooo much easier.
As a developer with a non-technical manager, I have run into the issue of design iteration being seen as "wasting time". I was able to talk through that one - and explain why my desk was littered in papers - but there was still a certain stigma around it.
I never got stopped at my desk again, but I almost always had trouble getting the time of day from the people who'd use our apps when I asked them to comment on a design. The best coworkers I ever had on that front were our controller and receptionist!
I agree, and I would also add that the great thing about sketchy hand-drawing is that it keeps people focused in discussions, making it clearer what they should be judging.
As soon as you have something that looks remotely like the real thing, people will get distracted. Why is this yellow not our brand yellow? What is this font? Those two boxes don't align! etc. While those details do matter, they are not important in the early iterations of a design.
I don’t get what the author means by “design”. Do they mean architecture or UX design or ???
I have a much simpler approach. Most engineers I have met (myself included) tend to design an architecture and data model, then overlay an API on that and finally overlay a UX. Both UX and API tend to be CRUD shaped around whatever object model the engineer implemented.
I’ve found that you get better results if you work backwards. Start with the goals/tasks that your typical user will want to perform, and design a clean, minimal UX to do those tasks. Then design the APIs that you need to enable that UX. Business logic should be in the code that calls the APIs, not in the APIs themselves- an app then becomes an API call composer/orchestrator.
Finally, define the service and data model/stores needed to support your API.
If you’re just doing an API and not a UX, then start out by writing the program that your customer would write - make up the APIs/objects & methods that most elegantly match user concepts, goals and expectations. Then work backwards to the service and object model.
This also works for classes and libraries as well- be your own user/customer first, then implement the code to deliver that experience.
Are you saying the process the author proposes—that the user’s needs should define the solution, and that process should be performed separately from engineering—won’t work on something like civil or structural engineering?
> But we as engineers try to do both. We're already in the code, we have the CSS and components, so we start designing and engineering at the same time. When I hear about a feature request, my brain starts churning: can I build this? How does it align with the code I already have? I start estimating the work, and like any engineer, I begin to think about how I can do the work faster by cutting scope.
> This isn't how designers work.
It sort of is! The designer at a product organization has to keep in mind the same set of constraints: how would this work, how does it align with the rest of the product, how long is it going to take, and what is the tradeoff between essential functionality, and nice-to-haves? When working on blue-sky designs, some of that doesn't apply, but I don't believe most of his engineering considerations apply in that case either.
In general—speaking as someone who did both for a long time—I consider engineering a kind of design, just as UX and Product and so on are kinds of design. Design is just intentionally solving a problem while adhering to a set of parameters which includes goals, requirements, and constraints. That's engineering, that's UX, that's graphic design to a large extent, that's certainly product design. It's a lot of things, when you think about it. Mostly the tool sets and culture vary, but the central activity is equivalent. That's why I don't think turning off your engineering brain and turning on your design brain makes a lot of sense.
The author should provide more context around this article. From the title I assumed this was about software solution design, like architecture or something. But reading through the article I get the impression the author is referring to UI design (still not 100% sure though).
Hmm there are some oversimplifications of designers' work. "you're coupling how something looks to how it works" – how something looks is actually just a tiny part of designers' work. It's almost negligible, even overrated :-)
I tend to say devs program the machine, designers program the human using that machine. Most design is about understanding how brain works and "coding" a flow that the brain will execute, hopefully the way you expected.
Decoupling is a big topic. I've witnessed a lot of organisations where this decoupling was basically a complete detachment, and the result was a disaster. As a designer & developer at once, my step 1 in all teams was to build the bridge between these two sides.
Ah, that touches on something I would call the journey of becoming a designer; most people just don’t have much experience in designing things supposed to be used by other people.
This fundamental distinction between creating how something looks and how it works may help at the beginning, with some experience, you’ll hopefully get to a stage where design and functionality come together as one. Designing a thing purely from a visual perspective brings its own dangers, like including stuff that only looks good, but doesn’t work well. That isn’t good design. Design is about things that look good because they fulfil their intended purpose well.
Great article -- I'm going set aside some time with a notebook and pencil today and give this a try.
I'm not sure I agree with the left brain/right brain, analytical and logical vs creative and emotional dichotomy. I think good design work can be just as analytical as it is creative. I think it has to be when it comes to UI and UX.
It's nice if it looks perfect but if I can get 3/4 the way with 1/20 of the code and 1/50 the effort I'll go with the less bloated version. It does depend a lot how often it is used and how annoying the missing functionality, how strange the order of steps or how sub optimal lay-outs are.
This is the beautiful dance of UX and Engineering!
A proper pairing means both parties that make trade offs so everyone benefits: the engineering constraints provide healthy check to user needs, forcing the designer to evaluate and either find a novel solution or let it go. Sometimes that remaining 1/4 is worth a huge effort, sometimes it’s not, and sometimes the pushback uncovers a 2/50 solve that still nets the benefit of that final 1/4.
More generally, any work that a developer does outside of coding will improve their coding. If they learn a bit more about the business side of the company, they will have better conversations with the business teams because they speak (some of) the same language, and the developer will be better at prioritizing their tasks because they consider business concerns in addition to technical concerns. The same for Design, hiring, or testing. The most important task at a startup for both business and technical people is actually talking to customers, which should drive both Design, Business and Technical decisions. Most developers avoid talking to their customers, or are prevented from talking to them by other folks at the startup. The author alludes to this approach when talking about Design. You can and should go deeper, creating customer personas and workflows (like one of those Great Designers) to understand your customers better. The more time you spend talking to and watching your customers use your tools, the better!
A very important step is buried right at the bottom:
> Hand drawing is ideal because everyone can do it, it's fun, it encourages simplicity, and it's easy to start over. When the timer ends, I show the work to someone or wait a while and review it with fresh eyes.
Working in a fast, low-commitment medium is key. It really doesn't matter what it is, as long as it's easy for you to churn out many ideas. It makes you more open to feedback as you didn't put a huge amount of work into it, and for the same reason others will be more willing to give genuine feedback about it. It promotes many iterations before you actually start building.
One step that could be added is spending a few minutes before starting the design phase is collecting context about the issue. - Who is this feature for? - In what scenario will they use it? - What is the issue they're facing? - Can I collect some real-world examples of people with this issue? - How would this idea be useful to them?
It might seem really obvious at first, but as you get deeper into the design process it's easy to get sidetracked. Starting with a clear understanding of the user's problems makes the whole process go soooo much easier.
As a developer with a non-technical manager, I have run into the issue of design iteration being seen as "wasting time". I was able to talk through that one - and explain why my desk was littered in papers - but there was still a certain stigma around it.
I never got stopped at my desk again, but I almost always had trouble getting the time of day from the people who'd use our apps when I asked them to comment on a design. The best coworkers I ever had on that front were our controller and receptionist!
I agree, and I would also add that the great thing about sketchy hand-drawing is that it keeps people focused in discussions, making it clearer what they should be judging.
As soon as you have something that looks remotely like the real thing, people will get distracted. Why is this yellow not our brand yellow? What is this font? Those two boxes don't align! etc. While those details do matter, they are not important in the early iterations of a design.
A place I’ve worked recently had design leadership who:
(1) Asked to be included as early as possible in the process, and …
(2) Would not tolerate sketches, demanding at least a mid-fidelity level to discuss work.
This was fun.
100%
I’ve found working in pen is key for me. Imprecise, no ability to fix, so the impulse to tweak/fix has nowhere to go.
I don’t get what the author means by “design”. Do they mean architecture or UX design or ???
I have a much simpler approach. Most engineers I have met (myself included) tend to design an architecture and data model, then overlay an API on that and finally overlay a UX. Both UX and API tend to be CRUD shaped around whatever object model the engineer implemented.
I’ve found that you get better results if you work backwards. Start with the goals/tasks that your typical user will want to perform, and design a clean, minimal UX to do those tasks. Then design the APIs that you need to enable that UX. Business logic should be in the code that calls the APIs, not in the APIs themselves- an app then becomes an API call composer/orchestrator.
Finally, define the service and data model/stores needed to support your API.
If you’re just doing an API and not a UX, then start out by writing the program that your customer would write - make up the APIs/objects & methods that most elegantly match user concepts, goals and expectations. Then work backwards to the service and object model.
This also works for classes and libraries as well- be your own user/customer first, then implement the code to deliver that experience.
I don't get it either.
He should test his notion on a bridge.
What do you mean by this?
Are you saying the process the author proposes—that the user’s needs should define the solution, and that process should be performed separately from engineering—won’t work on something like civil or structural engineering?
> But we as engineers try to do both. We're already in the code, we have the CSS and components, so we start designing and engineering at the same time. When I hear about a feature request, my brain starts churning: can I build this? How does it align with the code I already have? I start estimating the work, and like any engineer, I begin to think about how I can do the work faster by cutting scope.
> This isn't how designers work.
It sort of is! The designer at a product organization has to keep in mind the same set of constraints: how would this work, how does it align with the rest of the product, how long is it going to take, and what is the tradeoff between essential functionality, and nice-to-haves? When working on blue-sky designs, some of that doesn't apply, but I don't believe most of his engineering considerations apply in that case either.
In general—speaking as someone who did both for a long time—I consider engineering a kind of design, just as UX and Product and so on are kinds of design. Design is just intentionally solving a problem while adhering to a set of parameters which includes goals, requirements, and constraints. That's engineering, that's UX, that's graphic design to a large extent, that's certainly product design. It's a lot of things, when you think about it. Mostly the tool sets and culture vary, but the central activity is equivalent. That's why I don't think turning off your engineering brain and turning on your design brain makes a lot of sense.
The author should provide more context around this article. From the title I assumed this was about software solution design, like architecture or something. But reading through the article I get the impression the author is referring to UI design (still not 100% sure though).
The core advice of the article seems relevant and useful to both of those types of design.
Hmm there are some oversimplifications of designers' work. "you're coupling how something looks to how it works" – how something looks is actually just a tiny part of designers' work. It's almost negligible, even overrated :-)
I tend to say devs program the machine, designers program the human using that machine. Most design is about understanding how brain works and "coding" a flow that the brain will execute, hopefully the way you expected.
Decoupling is a big topic. I've witnessed a lot of organisations where this decoupling was basically a complete detachment, and the result was a disaster. As a designer & developer at once, my step 1 in all teams was to build the bridge between these two sides.
Ah, that touches on something I would call the journey of becoming a designer; most people just don’t have much experience in designing things supposed to be used by other people.
This fundamental distinction between creating how something looks and how it works may help at the beginning, with some experience, you’ll hopefully get to a stage where design and functionality come together as one. Designing a thing purely from a visual perspective brings its own dangers, like including stuff that only looks good, but doesn’t work well. That isn’t good design. Design is about things that look good because they fulfil their intended purpose well.
Great article -- I'm going set aside some time with a notebook and pencil today and give this a try.
I'm not sure I agree with the left brain/right brain, analytical and logical vs creative and emotional dichotomy. I think good design work can be just as analytical as it is creative. I think it has to be when it comes to UI and UX.
I think "design" here means something like "graphic design"?
Graphic computer interface design. He's not talking about how to make a great book cover or a promotional poster.
Anyone else getting "Application Error?"
Yup, failed on the first try.
Refresh the page and it worked.
Not declining as fast in usability as a huge number of websites which used to be just fine, that's modern webmasters for you.
It's nice if it looks perfect but if I can get 3/4 the way with 1/20 of the code and 1/50 the effort I'll go with the less bloated version. It does depend a lot how often it is used and how annoying the missing functionality, how strange the order of steps or how sub optimal lay-outs are.
This is the beautiful dance of UX and Engineering!
A proper pairing means both parties that make trade offs so everyone benefits: the engineering constraints provide healthy check to user needs, forcing the designer to evaluate and either find a novel solution or let it go. Sometimes that remaining 1/4 is worth a huge effort, sometimes it’s not, and sometimes the pushback uncovers a 2/50 solve that still nets the benefit of that final 1/4.