3. So a designer who uses lorem ipsum is not a designer? What? So if he's hired to work on a project he sits around waiting for copy before comping design ideas? As someone who's been in this position it is quite wonderful to start with finished or semi-finished copy but that doesn't always happen.
4. A designer who sweats every detail is a designer that never finishes. Sometimes the designer just has to let loose those details that only that designer realizes are a potential issue in the design, not functionality. If during review enough comment on it then fix it, otherwise let it go.
10. I cannot agree with this more. Although I'm a front-end developer so I may be biased just a tad bit.
14. I don't necessarily agree with this. It depends on the project and established goals. As someone else pointed out, if you do this you may give the desktop user a less than ideal experience. If you're willing to put some of that cut stuff back in for the desktop people at some point then sure. But to give a mobile experience to desktop people cannot be a good thing.
15. Almost contradicts rule #4. Some people would say sweating the details is close to over design.
26. This is excellent advice. The hard part is knowing the difference between an app with a good design versus bad. This is a hugely subjective thing. Popular apps don't necessarily have good UI. Also, be careful, because in today's environment if you get an idea from an app you may get sued for it.
29. Not necessarily true. Depends on the people. Your best bud may refuse to document his code in a useful way (or he may just suck at it) and the best coder in your group may be a total jerk outside the professional environment.
I'm a glass half empty kind of guy so that's the focus of my comments. The rest can be assumed I agree with or neutral on.
Also, I kept getting confused over which designer he means as he explains his points. There are three examples in the article; Visual, UX, and UI. But then he just uses "designer" too often for all three.
totally annoyed with his #3 as well. Been working with a folks who want everything to be decided by the "designer" first and make copy-perfect photoshop templates first - even if they're not that happy with the design.
This introduces an annoying 'waterfall' process where I can't test whether the designer's ideas actually work in-browser and practice until they're officially 'done'.
CN to managers: don't make a designer your product todo list. use a system for that and accept some quirks and broken-ness at first.
4. A designer who sweats every detail is a designer that never finishes. Sometimes the designer just has to let loose those details that only that designer realizes are a potential issue in the design, not functionality. If during review enough comment on it then fix it, otherwise let it go.
10. I cannot agree with this more. Although I'm a front-end developer so I may be biased just a tad bit.
14. I don't necessarily agree with this. It depends on the project and established goals. As someone else pointed out, if you do this you may give the desktop user a less than ideal experience. If you're willing to put some of that cut stuff back in for the desktop people at some point then sure. But to give a mobile experience to desktop people cannot be a good thing.
15. Almost contradicts rule #4. Some people would say sweating the details is close to over design.
26. This is excellent advice. The hard part is knowing the difference between an app with a good design versus bad. This is a hugely subjective thing. Popular apps don't necessarily have good UI. Also, be careful, because in today's environment if you get an idea from an app you may get sued for it.
29. Not necessarily true. Depends on the people. Your best bud may refuse to document his code in a useful way (or he may just suck at it) and the best coder in your group may be a total jerk outside the professional environment.
I'm a glass half empty kind of guy so that's the focus of my comments. The rest can be assumed I agree with or neutral on.
Also, I kept getting confused over which designer he means as he explains his points. There are three examples in the article; Visual, UX, and UI. But then he just uses "designer" too often for all three.