[HN Gopher] Decoupling design from engineering
___________________________________________________________________
Decoupling design from engineering
Author : jwworth
Score : 61 points
Date : 2024-10-31 17:01 UTC (5 hours ago)
(HTM) web link (buttondown.com)
(TXT) w3m dump (buttondown.com)
| joshdavham wrote:
| Anyone else getting "Application Error?"
| fuzzfactor wrote:
| 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.
| 9dev wrote:
| 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.
| josefrichter wrote:
| 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.
| karaterobot wrote:
| > 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.
| efitz wrote:
| 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.
| chrisjj wrote:
| I don't get it either.
|
| He should test his notion on a bridge.
| gffrd wrote:
| 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?
| datadrivenangel wrote:
| A bridge should be designed backwards from intended use...
| JusticeJuice wrote:
| 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.
| gffrd wrote:
| 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.
| smoe wrote:
| 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.
| gffrd wrote:
| 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.
| Nevermark wrote:
| 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.
| gffrd wrote:
| I'm about to do an old person thing:
|
| 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.
| 6510 wrote:
| 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.
| gffrd wrote:
| 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.
| nyeah wrote:
| I think "design" here means something like "graphic design"?
| dmurray wrote:
| Graphic computer interface design. He's not talking about how
| to make a great book cover or a promotional poster.
| Rumudiez wrote:
| visual communication design
| jbranchaud wrote:
| 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.
| pan69 wrote:
| 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).
| jbranchaud wrote:
| The core advice of the article seems relevant and useful to
| both of those types of design.
| danjl wrote:
| 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!
| spankalee wrote:
| 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.
___________________________________________________________________
(page generated 2024-10-31 23:01 UTC)