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.
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 functional gui framework, rendered in realistically chaotic pencil style where nothing is perfectly shaped, the same size or aligned, with only 3 or 4 unalterable pencil colors, would actually be useful.
Separate visual function design from visual style.
Balsamiq had (has?) something like this. You could mock up in whatever fidelity you wanted, but you could switch view modes and it would look like a sketch. Great for ensuring people didn’t get hung up on minutiae prematurely. It was wonderful.
But I’m imagining what you’re describing as another level, where one would draw relationships and behavior … and visual presentation would be like textures applied to a scene’s wireframe.
In my process, there is “iPad time”. This is the step where I sit in a cafe and create a sort of hand-written design document in Notability. The goal is to flesh out ideas without being able to work on them.
Sometimes this stage lasts a few weeks as I let the idea simmer. I add a few lines every now and then, ask new questions, draw UI sketches and refine the concept.
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?
Which is not the approach being advocated here by the author.
A bridge should be engineered and then designed according to the following process:
Determine requirements based on intended use and available resources (engineering) -> make something that looks nice while meeting those requirements (design)
The author's process is:
Make something that looks nice while deliberately ignoring constraints (design) -> figure out how to make that and also satisfy requirements (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 only point from the article I agree with strongly would be putting the keyboard away for a bit and picking up a pencil & some paper and trying out some rough sketches (though I think you can do this just as well at your regular desk)
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.
Agree - this is why I believe the notion of “UX being a discipline” is nonsense. A good designer should be informing all of their decisions with the goal of crafting the best possible user experience. Otherwise, a designer is just being relegated to “make this look pretty,” just like a developer or engineer might be told to “code monkey this solution that I have dreamed up.”
If the author is talking about UI/UX design, then I couldn't disagree more.
In the practical real world, Designs need to be buildable. I've see too many months, maybe years, wasted on trying to get engineers to implement difficult and/or incomplete designs. Designers that haven't considers all the data that can be displayed, all the states an interface can be in, responsiveness, accessibility, localization, etc.
I think designers need to think more like engineers, and ideally work in tools that let them experience the engineering problems with their designs early on and first hand.
Importantly, UI designers should not be working in glorified illustration software. Figma and friends have really led the industry down the wrong path.
All my UX work starts with a sheet of (digital) paper. How are you supposed to design an experience is you go straight to the UI design part? You have not even considered the underlying needs yet.
This is the design step in engineering terms, aka think hard about your approach.
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.
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!
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.
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).
While decoupling is good, I think this is totally backwards with regard to how that should be done.
It is very easy to engineer something which is agnostic to the design. It is nearly impossible to design something (well) which is agnostic to the engineering.
When confronted with a new thing your mind immediately goes to "how do I build this" because from your past experience you know that's both the hard part and what is going to dictate everything else. Yes you will likely choose to do things in a way you know makes sense which will limit how much you are challenged by the overall process because that's the rational thing to do when your goal is to get stuff done.
There's an argument to be made this approach is good for when you are deliberately trying to get out of your comfort zone and try new things for funsies. Exercise requires you to deliberately add resistance to your progress. This is great for a weekend project. But it shouldn't be your standard workflow.
> 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 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.
(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.
Separate visual function design from visual style.
Balsamiq had (has?) something like this. You could mock up in whatever fidelity you wanted, but you could switch view modes and it would look like a sketch. Great for ensuring people didn’t get hung up on minutiae prematurely. It was wonderful.
But I’m imagining what you’re describing as another level, where one would draw relationships and behavior … and visual presentation would be like textures applied to a scene’s wireframe.
Sometimes this stage lasts a few weeks as I let the idea simmer. I add a few lines every now and then, ask new questions, draw UI sketches and refine the concept.
It’s very effective.
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 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.
He should test his notion on a bridge.
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?
"Define the solution" does not equate to design.
A bridge should be engineered and then designed according to the following process:
Determine requirements based on intended use and available resources (engineering) -> make something that looks nice while meeting those requirements (design)
The author's process is:
Make something that looks nice while deliberately ignoring constraints (design) -> figure out how to make that and also satisfy requirements (engineering)
> 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 only point from the article I agree with strongly would be putting the keyboard away for a bit and picking up a pencil & some paper and trying out some rough sketches (though I think you can do this just as well at your regular desk)
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.
In the practical real world, Designs need to be buildable. I've see too many months, maybe years, wasted on trying to get engineers to implement difficult and/or incomplete designs. Designers that haven't considers all the data that can be displayed, all the states an interface can be in, responsiveness, accessibility, localization, etc.
I think designers need to think more like engineers, and ideally work in tools that let them experience the engineering problems with their designs early on and first hand.
Importantly, UI designers should not be working in glorified illustration software. Figma and friends have really led the industry down the wrong path.
This is the design step in engineering terms, aka think hard about your approach.
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.
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.
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.
But it looks like this is design after problem domain mastering.
Or rewrite :)
That "newer rewrite - look on Mozilla!" is just half of the truth.
It is very easy to engineer something which is agnostic to the design. It is nearly impossible to design something (well) which is agnostic to the engineering.
When confronted with a new thing your mind immediately goes to "how do I build this" because from your past experience you know that's both the hard part and what is going to dictate everything else. Yes you will likely choose to do things in a way you know makes sense which will limit how much you are challenged by the overall process because that's the rational thing to do when your goal is to get stuff done.
There's an argument to be made this approach is good for when you are deliberately trying to get out of your comfort zone and try new things for funsies. Exercise requires you to deliberately add resistance to your progress. This is great for a weekend project. But it shouldn't be your standard workflow.
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.