Slashdot Mirror
The New Link Between Designer and Developer
Scott Kinder writes "Ryan Stewart of ZDNet discusses the importance of the workflow between designers and developers. Both Adobe and Microsoft have a lot at stake in their respective software projects. Given how important experience is in making software, ensuring that it is easy for designers and developers to work together is more important than ever." From the article: "The key here is going to be the workflow between designers and developers and making sure that the tools support both types of content creators. Creating world class RIAs simply will not be possible without an efficient workflow between the two areas. Adobe has focused a lot on incorporating Adobe and Macromedia products, making sure that designers can easily move between both companies software. But they haven't quite perfected the designer/developer workflow, and I think Microsoft has a bit of a head start here. The Expression Suite seems built from the ground up to work well with their developer tools. The question will be whether or not designers will use these new tools."
Let me guess, this guy is a developer and that's why he prefers the MS approach?
...I still have no idea what its point is.
Are they working on the basis that companies have graphics designers who work out the visual appearance, and programmmers who write the scripts to update the content in whatever way, and these two roles are independent?
In my experience, that rarely happens, just as it rarely happens for desktop apps that there's someone who designs the user interface, and then there are guys who write the code behind it. Perhaps for very large projects in very large companies this is more common, but certainly not in smaller outfits IME.
Even if the larger companies want to put more effort into the presentation/usability aspects of their web sites, how is this any different to the problems of UI design for desktop apps that we've been working on for years? Just get the guys who are experts in graphic design, accessibility, and so on to put together the concepts and work out the HTML, CSS and graphics they want to use. Then give the specs and prototypes to the programming team to insert their code into them. This idea is not difficult to implement for even the largest desktop applications, and I don't see why the fact that the presentation medium is a web page makes any difference.
Then again, I still code up my pages using text editors and scripted tools rather than all these funky "web design" applications, and I only maintain a few hundred pages with thousands of hits per day single-handed and in my spare time, so I have no idea what I'm talking about. :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Nice flame troll, not very subtle though. Cooperation always results in a better product than if people each sit in their own corner and only talk when the project is in danger of being derailed. This guy seems to be talking about interaction between (web)designers and (web)developers but planning and design in general, even if we are only talking about the design and structure of the software code it self, is something that is completely missing in a lot of coding projects. I wish I had a penny for every badly planned, badly designed and as a result bug ridden and semi useless block of Java, C#, C and C++ code I have had to rewrite because the original coders didn't take the trouble to apply fundamental software design principles like layer abstraction, code re-use and modularization to their projects.
Only to idiots, are orders laws.
-- Henning von Tresckow
So the visual interface is exactly the same for developers and design.
The problem is that designers and developers have very different needs, so giving them the exact same interface/tools doesn't particularly make a lot of sense. You don't give the guy who's painting your house a hammer and say "go to it." I'm amazed that you guys can't figure this out.
Discussing design and development always suffers from the various definitions people attribute to those roles. At the extreme end, designers are seen as graphic designers responsible for surface styling, 'skins', while the developers are expected to be socially incompetent eccentrics who value only code elegance.
That's just stupid, there's a huge gap there where no-one is looking at interaction design.
Any product still ends up with a design - a form - whether there is a dedicated designer or not. How well that product then fares from its users' point of view should be used to assess the quality of the design.
In my opinion, it's fair to assume a designer being the person in charge of the end user's experience, the individual using the product. Can they do what they set out to do? Are they happy using the product? A designer must absolutely be able to justify the rationale of user-beneficial design decisions to others, who may not be on speaking terms with the actual end user, like developer and marketing types.
And hopefully they do that way before a single line of code is written.
That's my definition of a designer.
You must be joking. Most companies _have_ to pander to their customers. They dont make money otherwise. Even MS have gone to astonishing lengths to support their customers. OSS tends to utterly ignore the mainstream user which is why many mainstream users would rather steal a copy of windows than use OSS. Report a bug and be told to fuck off thats intended behaviour/user error, request a feature and be told to fuck off its a stupid request, ask for help and be told to fuck off and read the documentation, point out there is no documentation and be told to just fuck off. Think about that for a few mins and tell me if you can see a problem.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Perhaps I'm not understanding you right, but are you really suggesting that users have no place in the software development cycle other than buying the software and firing off feature requests into the void? That seems like a broken view, but I may not understand what you're saying.
Now, I'll agree that the *developers* are probably not the right people to be fielding user feedback directly. This isn't because they have "more important things to do," rather, it's because a developer doesn't usually have the authority over the architecture of the product to engage in that sort of decision one-on-one with the end user in the first place.
However, to suggest that the users should be left out of the loop entirely is an arrogant view that puts WAY too much confidence in the ability of the architects ("designers" in this article's lingo, I guess) to anticipate every need of the users. Instead, the architects should have some mechanism to get feedback from users. The users are the folks who actually know what they're trying to do with the software, so even if they don't know what's easy to implement, they know what is holding them up. The architects are in a place to understand why the user has requested a feature and to decide whether it is consistent with the design and reasonable to implement.
Every company I've worked for has done this and it's often invaluable, but it does require some effort and discipline. It's a part of understanding the application that the architects must do to some degree as part of the design process. The level of hand-holding that the user gets while making requests will depend on his clout as a customer, ranging from application engineers or even architects going on-site to tailor software to a key customer's needs, to tech support tallying requests for various features and passing them along in aggregate.
One other thought -- just as the user shouldn't be telling the *developer* what to implement, it's also more useful to solicit feedback as "capability requests" rather than "feature requests." The distinction is that a feature request implies (to me, anyway) something like "I want to click here and here and then type "blah blah" and it's done." This is usually too detailed. Instead, the feedback should be "I need to accomplish XYZ rapidly" and the architect should be free to design a solution to this that's consistent with the existing design.
And, I might add, the same applies to graphic and layout artists. Just because you can draw pretty doesn't mean you know a thing about human/computer interaction.
I'm awake! The answer is BONK!
It is far moire likely that designers have studied and understand interface design than for a programmer to have done so given that it is the very thing we do, we do not just "draw pretty pictures". Design is a commercial art for which I make no apologies. We utilize type and image to interact with people in a myriad of ways. If it's print, then the use of paper, folds, and design all come into play to guide the audience through the piece. If it's broadcast design then understanding how to fit a huge amount of information in as tight a space such as tickers or lower thirds requires a bit more knowledge than how to draw pretty pictures. Same goes for the web. I'm sure you coudl find examples of designers who used pretty pictures on the web simply to use pretty pictures. However, I point to sites like http://www.geoterra.com/, or http://www.bmwusa.com/allnew3 for examples of excellent design with human interaction in mind (both won top honors in Communication Arts - you can view more great sites by following this link). If you want to see a coupe excellent examples of design studios who do web sites very well hop on over to http://www.secondstory.com/, http://www.terraincognito.com/,
Is hard for programmers to help users. Is also a bad idea to be the developper AND the tester. And this why we have teams. One guy can be a programmer, other guy tester, and another do the marketing/media stuff. And thats Ok. The problem here are tiny teams with tons of programmers, but not tester or not marketers. You really need people that think like clients, and is not a programmer.
-Woof woof woof!
Instead, the feedback should be "I need to accomplish XYZ rapidly" and the architect should be free to design a solution to this that's consistent with the existing design.
That is precisely what a requirement is. You find that users are really quite particular however, because they're not really sure what the requirement is, all they typically have is a vision of how their ideal app might work that they narrate back to you. A good architect distills requirements out of this sort of thing and makes sure the customer agrees on the shared idea before proceeding.
A decent use case is good for documenting a requirement, as any use case that dictates implementation is probably too detailed. It's always a continuium from perfect to broken: there's always functional specs that creep into requirements as well as vague requirements not given functional specs. Hell there's probably some sort of incompleteness theorem that says the two won't ever meet perfectly, but getting everyone clear on the difference is a good first step.
The problem is that none of use knew JSF. A few of knew JSP and had experience writing beans and whatever, but JSF turned out to be a nightmare. Had I known the technology and how it worked, I would have designed the GUI differently. Having a working knowledge of the implementation tools helps you to design a more appropriate application from the beginning. It turns out that we had to make some changes to make JSF "fit" my design, and in other cases we simply had to re-think some of the functionality.
I will give credit to my tech lead for making me code my design and actaully write a few of the backing beans (we had four developers, so most of the beans were written by expreienced Java folk).
My point: a designer must also wear the developer hat, and I might add, the tester's hat. I think many dev shops are splitting up roles too much. Working in a vacuum is, as I have discovered, counterproductive.