4 ms·
To the developer, every decision is a trade off, a tension between the demands of the now (features and time) and the demands of the future (elegance, maintaina
by kybernetikos 13y ago
To the developer, every decision is a trade off, a tension between the demands of the now (features and time) and the demands of the future (elegance, maintainability).
Designers are not in a good position to appreciate the trade offs. It's very easy for a designer to think 'this infelicity decreases delight, and fixing it involves just moving this thing to there'. This is probably an excellent spot of a real design issue, but that isn't the only thing that determines whether the work should get done or not.
I have no solutions, but problems like this are generally because of an insufficient appreciation of the other professions challenges, and if you're working in an environment with skilled practitioners of both disciplines, more communication is likely to fix it.
Here are some suggestions that might help designers talk to developers: Never use the word 'just' when talking to developers, frequently apparently simple things have huge ramifications and just as a designers specialty is understanding how the little things create a full experience, a developers specialty is understanding how little changes affect other things in the full system. Talk to them about the effect you're aiming for, rather than just the change itself - if the change is trivial, the worry is that you're not respecting their time, but if you convey that the trivial change will have a large specific effect then they will understand and may be able to do other things proactively to help you achieve your effect. Show that you care about more abstract values such as 'maintainability'; the ability to add features quickly in the future and having a low bug count are both massively beneficial to the user experience. Where you can, show that your fixes are not merely matters of opinion but are based on empirical evidence, good developers respect evidence. Get involved early in the process and talk regularly to the people implementing the design - show that you care about their opinion, but educate them in seeing things from another viewpoint too.
As a developer, you are probably used to having a discussion with the person who reported a bug for technical issues. Do the same for design issues - even if it's just 'move this button three pixels', talk to them about it, find out why it's important, find out if they really mean that it needs to align with some other element. If you have a legitimate reason to not want to do it, explain the problem - you might be able to work out a better solution together.
- Chris_Newton 13y agoNever use the word 'just' when talking to developers, frequently apparently simple things have huge ramifications Sometimes that is true, and that is so whether you’re talking about changing a design or changing the underlying implementation, and whether you are talking about web design/development or software development more generally. Having said that, if a designer can’t request and a developer can’t implement trivial changes that really are as simple as shifting something by 3px, most of the times that means at least one of the following is true: 1. The person who implemented the previous version wasn’t very good. 2. The person who implemented the previous version was pressured to take short cuts in order to hit time/money targets and produced work that wasn’t very good. 3. There is some more general problem with the development process that means a designer requesting a trivial change and a developer then making it are expensive when they shouldn’t be. Obviously there could be exceptions where that 3px change has much wider implications for the overall layout, but I don’t think those cases are really what any of us are talking about here.
- kybernetikos 13y agoThe point is that if you use the word 'just' you're saying that you already know that the change is trivial. Perhaps it is, perhaps it isn't. Show respect to the person who will implement it by letting them say whether its trivial or not. It's absolutely true that moving a button 3px should be trivial, but it's also true that things are often not as they should be.
- Chris_Newton 13y agoI agree with your fundamental point that making the assumptions about what colleagues will have to do can be dangerous, though I would still challenge your earlier suggestion that apparently simple things “frequently” have huge ramifications. It’s sensible and polite to acknowledge the possibility, but if trivial-seeming changes are getting push back more than occasionally, IME that probably indicates a more serious underlying problem with how the project is being built.