Anyone run into Agile Development teams that use UI Component Libraries (PrimeFaces and IceFaces) with horrible User Experiences ... who won't modify the code to support a better User Experience. Looking for responses on how to protect the Users Experience and convince upper management that the UI Component Libraries provide a bad user experience.

  • 2
    This could lead to a very interesting discussion. However, as the question stands now, it's not a "practical question" that's going to "elicit definitive answers" imo. Perhaps this is something for the chat room?
    – Jeroen
    Feb 16, 2012 at 7:44

4 Answers 4


I hate to stereotype, but, well, it's somewhat valid in this case: JSF developers don't understand the presentation layer code nor user experience. I think it has to do with the evolution of JSF as a web development tool...most all of the front-end code is out of the hands of the developers. It's all generated automatically (and poorly) via the server side JSF tags. As such, JSF pretty much hides client-side code from JSF developers so they never have a need or motivation to care about a good UX client side.

Things like PrimeFaces are meant to help but, IMHO, they really don't.

The only 'cure' is to get the JSF to STOP MAKING CLIENT SIDE MARKUP. To do that, you likely need to change the entire architecture of the software so that you're leveraging things like JSON and AJAX to a bigger extent--allowing the data to be handled by JSF, but the actual rendering of the page to be handled by the front-end devs.

Be careful about stating 'UI component libraries provide a bad user experience' generically, as there are plenty of quality UI component libraries that provide a fairly decent UX (jQUery UI is one to consider).

So, alas, that's a lot of typing, but I'm not sure I have an answer for you...if anything, I think I have the exact same question!

Some arguments to consider:

  • JSF comes from the server-side model of web development. It's a dated concept.
  • JSF tends to produce a heavy client-side code base. That impacts UX.
  • JSF libraries tend to be fairly rigid, reducing the ability of the UX team to tailor the experience for your customers
  • There are plenty of modern up-to-date client-side libraries that are being used to a great extent and are much more forward-thinking both in UX and development philosophies.
  • Thanks for your input ... greatly appreciated! Part of the problem i am running into is the Dev team doesn't want to employee Front-End developers and they're stating that using Prime Faces eliminates the need to worry about browser code updates. Difficult to protect the user experience with such obstacles. Any suggestions on modern up-to-date libraries to consider?
    – Ashlie
    Feb 15, 2012 at 16:34
  • Take a look at the EXT.JS library (Sencha.com). This is an example a client-side model that works. Feb 15, 2012 at 18:31
  • 2
    Your DEV team is lazy and scared of change. Feb 15, 2012 at 18:32
  • Yea, I'd leave this project and find one that has front end devs. Alternatively, bring the front end dev into UX (my preference). Then deliver front end code. If they can't work with it, then that's their problem.
    – DA01
    Feb 15, 2012 at 19:35
  • jQuiery UI is pretty sweet due to Themeroller, very easy to apply style and tweak for a good UX.
    – Ben Brocka
    Feb 15, 2012 at 23:38

To my mind, this isn't an issue specific to Agile development processes; this question gets at the issue of ensuring that UX is part of the development process, period. In one of the first comments on the question "At what point in the development process should UX come into play in an Agile work environment?", user Aaron McIver (rightly) says that "Agile accounts for anything that delivers end user value. If the Agile team you're working on is not accounting for UX, that is to do with the team, not the process."

Your situation seems to be that you/the UX team is not appropriately involved in the development process, developers who are part of the process are implementing UI without consultation with UX, and that UI is bad yet they then won't listen to recommendation to make it better.

This is sadly typical (regardless of software development methodology), and in my experience resolutions require UX buy-in a level or two above the "problem layer" so that responsibilities are made clear to everyone on the team(s). You can:

  • Continue to provide good UX-based recommendations for UI
  • Document everything that you recommend (obviously) but also immediately document what is actually done and very clearly state how the implementation is does not follow the recommendation
  • Constantly communicate with the Project Manager that the UX portion of the project is being undermined by the implementation portion -- not in a mean way, but in quantifiable ways based on your documentation.
  • Find a way (either you or through your manager, depending on the hierarchy at your place) to ensure that UX and Dev are working in coordination with each other throughout the product development lifecycle.
  • Continue to do the best job that you can providing recommendations and documentation for good UX, and if you come to the realization that UX is not valued there/you can't change the setup, then decide how hard you want to continue to fight.

The key for me has always to make a pest of myself until people understand there's a fundamental process problem, then go back to the work that I/the UX team has done to show very simply that "A is good. B is bad. We recommended A. Devs implemented B. If they continue to implement B, here are the problems that will arise." At the end of the day, management will decide what they want to roll with; if the stakeholders sign off on something that UX doesn't support, that's unfortunate but it's what they do.

You'll note that I didn't take the tack in my answer that DA01 did, which is to address the component libraries themselves. That's because I see the greater issue being one of process and management; without UX embedded in the development process, the non-UX/UI-oriented developers are going to grab onto and use whatever they feel like/are comfortable using until someone stops them.


Yes. I've had issues with a dev team who chose Primefaces as a toolkit - with our (usability team's) blessing - as long as it was totally customizable with CSS.

But it turns out that Primefaces is so difficult for them to customize that they are now refusing to do it - even though it won't comply with our standards or meet user needs.

What I don't understand is that they could easily use other tools along with Primefaces as a base (like JQuery) to do what we need them to do.

From what I understand, though, Primefaces is a toolkit you choose when you don't want to deal with a custom UI at all.

It's a real issue. Primefaces and a good user experience / solid usability don't seem to go well together.

I'm going to write an issue paper that says that Primefaces (out of the box) doesn't meet usability requirements. Hopefully they will either abandon it or use it as a base and supplement it with more robust technologies when it can't do what we need.


I feel your pain. Currently our company uses JSF 1.2; very old, very outdated, and sadly the newest application framework we can support. In order to get around JSF shortcoming we put together a user experience team which I currently work in. We have build a agnostic template/framework, custom JavaScript APIs and guidance to use other technologies where possible. We are still currently in our "beta" stage but development groups have been adopting our standard where possible.

Depending on the business needs you might be able to do the same. Some of the technologies we use provide developers with:

  • jQuery and jQuery UI
  • Modernizr
  • jQuery DataTable Plugins
  • jQuery Qtips Plugin
  • Many custom developed plugins
  • Custom CSS to help style around JSF structural deficiencies.

We then eat or own poison in that all the functionality and styling we provide is built on top of JSF 1.2. As the "application" provides no real application need it proves that the framework is somewhat solid. We also provide syntax highlighting showing how we implemented the style and functionality. In most cases developers on need to attach a class to a an element like a table and our client side data tables plugin will automatically style the feature accordingly.

Currently I can not provide a link to our UX Guidelines as we are still working on them and they have yet to be promoted to a public facing server. But its in our backlog.

Hope this helps!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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