4 ms·
As a developer I actually agree. Too often we let “straightforward” or “fits best with the backend design” cause a knee jerk reaction to reject designs that are
by joshstrange 3y ago
As a developer I actually agree. Too often we let “straightforward” or “fits best with the backend design” cause a knee jerk reaction to reject designs that are better for the end-user. I’ve been working to catch myself and say “yeah this won’t be easy but in the end it’s going to fit better with the user’s mental model of what they are doing”.
The example I think of is if you have 2-3 related entities a developer might like a simple CRUD for each thing where you have to create the parent object before you can create the child (in a relationship). However sometimes the child is the obvious first thing a user wants to create so it’s important to build a UI that lets them create the parent on the fly or even have no parent until later.
As a younger dev I dug in my heals too often on things like that and I think it’s made me much better as a dev to approach designs with fresh eyes and think about how I’d want to experience the UI/UX instead of bringing preconceived notions based on how we built the existing code/UI.
One thing I will point out is I love working with designers who are open to “what if we did X instead of Y? X will take me 1 hour but the Y in your design will take 1 week”. Sometimes the “Y” is worth it and some times the designer thinks “X” is just fine (or even likes it better). Nothing is worse than strict designs passed down that need to be pixel-perfect with no wiggle room.
- tsunamifury 3y agoI generally agree with you and its how I operate, but then you see Apple who strictly requires engineers to follow design/marketing requirements to the pixel -- and they are the most successful consumer business on the planet.