Hacker News Reader

Comment by game_the0ry | Hacker News Reader

This will come off as a humble brag, but I will say it anyway.

Right now, I am tasked with building a PoC for a new product my team wants to build by the end of the quarter. We have one big problem - we have no designer on staff. But we do have a design system with a library with re-usable react components and tailwind css, and those are things I am pretty good with. So I have full autonomy when it comes to turning product requirements into a live demo. I was able to accomplish quite a lot in a short period of time with no designer and just my own taste in design + ux. And product stakeholders were pretty satisfied, which means the outcome was productive.

So from my perspective, Figma is not only an awkward middle ground, but not even necessary for me.

View on HN

My experience is that you should never code and design at the same time for non-trivial products.

When I'm doing design work, there is a product spec already defined but it almost always changes once initial designs are completed and people have a better understanding of how it would work in practice.

If you were to code and design at the same time you would inevitably writing some logic as well and this often turns into wasted effort.

Came here to write the same.

I used to teach at a UX grad program where students were required to learn both design and development. But doing both on the same project was almost always a mistake -- the designer has to deeply understand and advocate for the end-user's mental model while the developer has to deeply understand the technical model and constraints. Attempting to do both often end up conflating them or compromising on at least one of them.

Sort of like how many lawyers are skilled enough to handle either prosecution or defense but few do both on the same case.

I think there's a Nielsen/Norman article on this but can't find it at the moment.

I think it takes really senior designer/developer that can do both solo. Those people exists but still it's better to be responsible only for just one because it's tiring and demanding.

The best people added the other skill over time after they have been already excellent in main one (in my experience mostly designers learned to code rarely it goes other way). But teaching it from start side by side as equal seems like it would slow down the process. That doesn't mean i wouldn't want designers to learn to code from the start but just keep it simple at first.

Of the hundreds of my students and coworkers who had both design and development skills, only a few could fill both roles on the same project without compromising on either.

But when hiring I rarely bother reaching out to them. It's not just that being responsible for both is tiring or demanding, but a project team that dedicates one person to each role delivers faster than a team with one person wearing both hats. And given that people who can do both well at the same time on the same project are exceedingly rare, they typically earn high six figures (or comparable equity) so there's not much in the way of cost savings either.

Having said that, maybe it'd be worth it for a founder or an early employee where there is a strong pressure to maintain a low headcount?

On the other hand someone who can do both code and design has huge advantage of knowing where to cut corners, how to use platform features effectively and thus higher chance to make robust solution. But you need to have envinroment that allows this.

Perhaps, though personally I haven't found that to be an advantage compared to having two separate roles with decent communication skills.

> When I'm doing design work, there is a product spec already defined but it almost always changes once initial designs are completed and people have a better understanding of how it would work in practice.

In my case, I am just iterating on the fly with our end-user(s) (we also do not really have a product owner).

It may not have been obvious, but I am working on an app for internal stakeholders, not for external customers (the customers that my company serves).

So when it comes to designing for external end user + customers, design is serious and necessary consideration, which is where Figma would come in.

Worrying about wasted effort spent breathing some life into a mockup/prototype

vs Worrying about creating some figmentary Figma imaginarium that wont translate well into the actual app

I do think there is a risk, it's just not of throwaway code (the effort of that throwaway is vastly smaller than what this path replaces). The risk is more how & where the future could be constrained. If the prototype starts becoming the app, there's some risk the prototype imposes poor app architecture. If the prototype starts becoming the app the effort to mock/prototype new ideas risks becomes higher.

I strongly agree with the parent about getting in there & trying things semi live, not being afraid to wade in. The component offerings are excellent today, don't wire most of them up, just throw them on the screen as best you can & put in minimal stitching or hardcode a forward/back through states.

The fear of this going bad is way outsized. The design industry needs to get where the puck is going & stop playing around with fancy abstract design tools.

I don't code and design at the same time because I've noticed from experience that it's slower and gives worse results than designing first and then coding.

The wasted effort is one factor to it but another factor may be that I'm able to just focus on design and ux more and not think about implementation.

I think in the future product designers will shift into two factions. Live code generation and design system development. Design systems will be the backbone of any quality AI interface generation system. How we build those design systems will be the interesting part. Will most people unify around material/carbon or will they invest in house teams to ensure their UX doesn't fall behind the competition?

This has always been the case. Zero to one with a single developer or a very small team is the most exciting part of the lifecycle of a project. Medium to large size companies have very different challenges.

Reply on news.ycombinator.com