Decoupling design from engineering

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 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.

> 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.

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.

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.

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.

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).

I think "design" here means something like "graphic design"?

People interested in the topic should go read the free "Shape Up" book by the Basecamp team, where they explain that process and contextualize it in great detail within the product development cycle.

It's nice someone appreciate coffee [shops] ;)

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.

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.

Anyone else getting "Application Error?"