| "It's especially hard to affect UX when developers are typically given requirments from someone who has a specific (bad) design in mind." I agree, but that's because I think it's hard to write good software when developers are typically given requirements but aren't a part of creating those requirements. The best scenario is when developers are engaged with the users and actively participating in design. While this approach has gained a lot of credibility over the last few years, especially with the advent of the "developer-driven culture", there are still plenty of projects and groups that want to treat development as the "construction" phase of a project, something that happens after design and, perhaps these days, "UX". As a developer, this has been my big worry about "UX" so far. It seems like it could turn out to be another version of "coders know how to code - but UX designers know what software really ought to be, so we'll design it, and when we're done we'll let you know what to code up in your cubicle. Oh, and could we have some work estimates? Thanks!" I want to be sure I recognize that developers have their own version of this. "I'll write up the software, but it'll have a crappy UI. Here, designer, pretty this up for me would ya? Should take you about a day, right?" I liked the 37signals notion of the "three musketeers" (http://gettingreal.37signals.com/ch03_The_Three_Musketeers.p...), a developer, designer, and "sweeper" who can play both roles. All three work very closely together in a project. I think UX is a great idea and could be an important park of a development project, but I'd recommend UX advocates start thinking about how it would fit into a small team (no more than three people). You really don't have room on these teams for people who don't contribute directly to the working software application. As ThomPete pointed out, this means you can't afford staff who work in abstractions. I'd see this as a skill set that people in design or development roles should strive to obtain. If you mainly do design, wireframes, or front end work, see what you can learn from UX. Same for back end development - sometimes projects do start with very simple UI and focus on application functionality, so it could be hugely helpful to consider the context of UX. As others have pointed out, this is also something you can invest in, because you get a tangible product. |
I've found this is one of the more powerful and easy ways to prevent feature creep, at least for the smaller/shorter projects I have worked on. When I start with a UI, I find it's easier to ask what the bare minimum of a) inputs and b) feedback/guidance for the user that needs to exist. In the projects where I've started with a backend first, I often end up having to create more noise on the UI side to complete it.
I think this just goes back to your first point, how developers are more effective when we're involved in creating the requirements. Practicing good design is going to be more effective when you choose to focus on it up front, instead of relegating it to something to check off a list when the application has been developed.