4 ms·
I think of UI/UX designer as kind of a distinct role from programming. Sure, if you don't have any designers, then your frontend person is also your designer,
by jmchuster 6y ago
I think of UI/UX designer as kind of a distinct role from programming. Sure, if you don't have any designers, then your frontend person is also your designer, so in that case, it makes sense that their job is distinct from backend.
The opinion I've adopted from my designer friends, though, is that once you have a designer in-house and the site's basic design has been established, what is more important is that the developers notice and care about details. That's not something I would consider a frontend vs backend developer trait, just more of a general engineering attitude. Do you notice that the padding here doesn't match up, do you question why this form is laid out differently from all the other ones, how does this flow from page to page work, do you go find a designer and work with them until it's right.
I would posit that the same person who cares that the UI is consistent and makes sense would also be pointing out why is our code formatting all over the place, why we use different libraries in different places to do the same thing, why our patterns and architecture is inconsistent. If you just copy/paste in random UI pieces and call it done, then you're probably also copy/pasting in random stackoverflow snippets on the backend and just recompiling until the tests pass.
- Myrmornis 6y agoOK but my understanding is that modern approaches to client side JS are based around the concept of web components. In which case, even though the JS code encompasses many areas of software engineering (data flow, dealing with asynchronous events, MVC-like architectures to achieve separation of concerns etc) there is no escaping the fact that part of your code is directly representing a DOM which is rendered as a UI. So I'm not sure I believe that client-side JS can really be divorced from the design of the UI. Sure, the CSS can be done by someone else, but the choice of components that exist in the (virtual) DOM is necessarily very much part of the UI design isn't it?
- jmchuster 6y agoRight, that's why designers generally work with a component library, in an application like Sketch that is designed for building websites and mobile apps. Your component library might first start off with just all the basic HTML stuff, but that eventually becomes tailored to your company's own custom stuff. You're not just hiring abstract artists who then whip up a fever dream in photoshop.
- Myrmornis 6y agoOk, so in the setup you describe can the js engineers focus on software engineering and not be involved in the choice of components and UI layout design? I.e. they can have all that handed to them by a designer? I didn’t know that, in my experience the JS engineers also design the UI layout (but have designers work on CSS styling )
- jmchuster 6y agoSo, if you start off with something new or large, your UI/UX designers would be the ones driving all the work. Then once you're working on something established, then your developers might suggest components based on common patterns they know, and then ask designers to validate it. And then once you're adding trivial things, like another field to a form, you wouldn't involve the designer at all.
- Silhouette 6y agoThe recurring theme in this whole discussion is "it depends", and that is the case here as well. If you're building a relatively simple UI, using common features like buttons and text boxes and maybe some simple charts, you might well do what has been mentioned in this thread. You can identify reusable pieces that the designers can use to define layouts and specify styling and that the programmers can use to implement those things in code. This is an easy method of UI design and implementation, and often it is all you need. If you're building something more challenging -- a rich document editor, a game, an interactive 3D visualisation of a complicated data set, basically anything that isn't just a combination of standard controls and UI patterns -- then the main part in your UI might not fit that component model very well at all. Now you're going to have to approach both the UI design and the programming from a different direction, just as you would in desktop, mobile or embedded software. This is harder, because you're moving away from patterns and tools that are well understood and readily available, and instead you're building something original. However, it's also much more flexible for the same reason, and sometimes that's what you need. Even in the latter case, you will often need standard features in your UI that can be designed and built as individual components as well. There's no rule that says you can't have a hybrid with both reusable components for the simpler, recurring features and then one or more features that are more sophisticated.