5

First, some criteria:

  • The product is an application and is heavy on user interaction. Think web 2.0 or mobile application, not a marketing or commerce site, or some back-end tool with only command-line access.
  • I realize that it is not always clear who is a UX person and who is a developer (nor should it be), so I'd like to focus on overall team resource allocation. For instance, "My team puts 25% of our resource-time into UX design/research vs. 75% of our resource-time in development."
  • I am not distinguishing between front-end and back-end development as it is too platform-specific and difficult to tease out the dividing like. It's all software development for this question.
  • EDIT: Development is occurring in an agile-esque, ongoing manner, rather than a one-time, big-bang delivery.

So:

  • How does this proportion commonly look in practice?
  • How should it look? Or, better yet, what has been the proportion on successful teams?

(I realize this is a classic "it depends" question, but I suspect that there is some use in asking when constrained by a few parameters, and allowing that conditions will vary. I am also open to suggestions to further constrain the question.)

Improve this question

5 Answers 5

Reset to default
3

It's hard to draw a line between UX and Dev. There shouldn't be a line (as you state). It's going to depend on the project and the individual skill sets of the team.

The bigger factor, IMHO, is that the team, as a whole, isn't too large. You want to avoid the 'too many cooks' syndrome which seems all-to-common at the enterprise level where you end up with dev teams pushing over 20 people. That's just a mess.

You can do a lot with with just a team of 2: a skilled programmer and a skilled UX person who both have some skills that cross the line or, at least appreciate both sides of the equation.

Maybe a better way to look at it is in reverse...what's a BAD team. I think a sign of a bad team make up is when there is a discernable line between UX and Dev. I'm suffering a bit through that situation right now, where our UX team is entirely independent of the dev team (which I am on)...which is entirely independent from the enterprise architecture team (who's applications services we rely on). Even though we call our selves an agile shop, it ends up being waterfall as there is this assembly line mentality UX -> Dev. Which simply does not make for efficient software development with UX being a priority.

Improve this answer
1

Its important not to overlook how important UX is. It looks like you don't but I just want to restate it. I change in the UX can mean a week or two more work in development.

Before you start it is better for the the team to gather and plan out the UX (with developers too), then after the structure and plan is set. Something like 25% 75% would do.

Improve this answer
1

We have been at the same ratio for about 4 years. 8 engineers to 1 UX designer. Works well for us.

Improve this answer
1
  • This is pretty close to my current situation - more like 1.5 to 12. For us (and I'm sure this varies by product) it sometimes seems like we're shorting UX.
    – peteorpeter
    May 8, 2011 at 21:59
1

In my experience there never seems to be enough time devoted to design and UX considerations. The result: less than happy users, more rework, wasted money. We all know the story.

I think that a strategy for success is to do design and UX tasks with prototyping combined with user testing (even limited, quick user testing) until you see satisfactory user acceptance. What is satisfactory will be different things for different people, but as long as you get a feeling that the users are keen and excited to see the end product then you are probably on the right track.

The problem will be that some people in the team and in particular managers who are quite often nervous types when they don't see any real code in the repository, will see the need to abandon the design phase too early. This is false economy because ill-conceived designs cost more money to fix later (if they can be fixed at all) than it would to do it properly in the first place.

Also, I don't think design and UX activities are really things that are ever fully complete in a project. There should always be UX review and design tweaking. I have worked on projects where the project management scheduling mechanisms combined with billing systems actually prevented, after a certain date, any design/UX work!

I personally like to work at roughly 1/3 design-UX to 2/3 application development with effort spread over the entire timeline not in contiguous blocks. There is an emphasis at the start on the design and UX issues and more flat out coding at the end but both exist at pretty much all times during the project. I'm sure this could be described by some fractal maths, but that's a question for another stack.

Improve this answer
0

I'm working on a 1ux:9dev and it's clearly inefficient. also because the dev teams are dedicated to various projects at the same time with different dimension each one. In my case, each ux does research, design, user testing and follow the work of dev team. besides, they work as product owner (so they hare required to several meeting, priorize and define user stories). The feeling I have with this proportion is we are always in a run, with few time to explore and design better services

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.