|
|
|
|
|
by jlind
5484 days ago
|
|
This is one of the toughest things I've learned in the last year or so while interning (in IT) for a fairly large insurance company. It's especially hard to affect UX when developers are typically given requirments from someone who has a specific (bad) design in mind. Anecdote:
Just the other day we had a request come through to have a flash video (with music) automatically play on the splash page for one of our bigger applications. We ended up taking it down the very next morning after the original requestor was getting bombarded with emails and phone calls about it. I hoped they might have learned from it, but their initial response was to just move the video to another page and continue to let it play automatically. We didn't let them make the same mistake twice, though. |
|
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.