I dont get along well with UI designers generally unless they have a strong engineering background, and I want to explain why by raising a couple of questions: Do you want the most beautiful font face in your software, or do you want a multi-lingual software that can adapt to different screen resolutions? Do you want the most ergonomic, hand-crafted panel layout for everything or do you want multi-selection? These questions highlight some of the conflicts between UI designers and engineers. Engineers want things like architectures that support multi-selection, and UI designers are often against it -- not explicitly against it, they would say theyre for it, but have a tendency to do things that make it about as impractical as possible. Engineers are obsessed with consistency at a central level, while UI designers are obsessed with aesthetics and only some sense of consistency in this respect (consistent color palettes, e.g.). The difficulty for engineers is that UI designers, especially good ones, feel the need to hand-tune everything. They want to go into every single possible panel in the software and adjust things on a per-pixel basis: This field should have a 3 pixel spacing from the previous field to the left, the field below should be 5 pixels down. This tends to set impossibly high standards for a software that allows an infinite range of possibilities, screen resolutions, etc. It looks gorgeous, no doubt about that. It gives that professional human touch to everything. But the problem is that when we do things like multi-selection in a system that allows you to select an almost infinite combination of different things like a light, a scene, and a surface all at once, then the properties they have in common would vary with every possible combination. There would be too many combinations to design by hand. From an engineers perspective, if youre going in and hand-designing everything and especially hard-coding pixel spacings into the software, youre already doing it wrong if your goal is a flexible system. From a designers perspective, its the only way to make things look really great. So maybe we can compromise and say that for homogenous selections, we design each individual property panel layout by hand. For non-homogenous selections of different item types, we procedurally generate the layout. But then the problem is that the generated layouts end up looking tacky when we already went in and hardcoded hundreds of panels with 5 pixel spaces here, 4 pixel spaces there, 7 pixel spaces there. All that enormous coding effort starts to become almost outright incompatible with these flexibility needs: its work that we should at least consider tossing out at some point. Without uniform rules created with an engineering-type mindset to generate these panels that are consistently applied throughout the software, it begins to look like a mess, both in code and to the user. The same kind of problem happens when a designer chooses this 8 pt, non-resizable font and wants to use that in the software. He gets everything looking just perfect with that exact font, except now it looks too small on some peoples screens. We cant change it because he got the design of everything else just perfect for that exact font. Its also not available in any other language but English. So a practical person here, like a programmer, would want to step in here and use a standard, flexible font that can handle all of these needs. It might not be as pretty, but it would work in every scenario. Engineers are functionality-first type of people: they want something initially that works for every possible scenario before they go in and tweak things on a case-by-case basis. They generally want to avoid things that can only work for one possible scenario, thinking that this can all be redone later as an afterthought (engineers see the cost of these afterthoughts first-hand, and theyre rarely cheap). Its really tough to balance these needs. I recognize the need and desire for the professional designers touch, but it has to be balanced against the need for procedural generation and consistent functional rules established by an architecture/API. Theres only room for a lot of hand-tweaking in the rigid parts of the software that dont ever need to be dynamic. In an ideal world, I think engineers should design the functionality of the software and the overall workflow rules, while UI designers take what the engineers do and try to make it look as pleasing and ergonomic as possible based on the rules and constraints that the engineers established. Unfortunately things usually want to work the other way around, and engineers rarely do this kind of design work. When the engineer refuses to hardcode individual pixel spaces into the software, the designer finds a really horrible engineer who volunteers to do it, writing the most rigid code imaginable that would require being completely redone to make any kind of design change. And the designer now thinks that programmer is better than you because he did something you refused to do: he happily wrote unmanageable code that is hopelessly incompatible with other needs to make the designer happy.
Posted on: Wed, 10 Dec 2014 04:56:35 +0000
Trending Topics
Recently Viewed Topics
© 2015