UX Roadblock #17: Development tools and frameworks

In every software release, there are always resource constraints. It's an immutable fact of life, like the sun rising in the east or your toast falling butter side down. There's not a lot of value in complaining about it... and pretending that your work should be done without regard to resource constraints or ship dates will lower your credibility.

However, even if we accept that resource constraints are a fact of life, it still can be the case that these constraints are inappropriately impacting the user experience. In other words, resource constraints are an issue for everyone in every discipline, but sometimes the impact on one area is out of whack with what other areas are facing. One way in which this can happen to user experience is via bad development tooling and frameworks.

Development tools and frameworks are intended to make developers more productive. When done poorly, they can create a situation where developers are more productive if they follow a single path, but any deviation from that path results in a huge development effort. And deviating from that path is often requested by the UX team. This can result in mind-boggling conversations like, "Sorry, I can't change the label on that button... the framework is giving me the label, and I would need to custom code the entire page to change it." The trick is to recognize when a developer is feeding you a line of crap to avoid extra work versus when there really is a tools/framework issue. Or both!

As an aside, one area where I've repeatedly seen this issue is in the area of product installation tooling. These try to make things easier by giving the developers a bunch of common install functions for free. But it's often an all or nothing proposition... you either use the common function EXACTLY or you have to start from scratch. So there's a resource cliff. A minor design change creates a huge impact on the development sizing. So as a designer you get stuck with accepting a bunch of minor irritating behaviors because none of them individually are worth throwing out the free behavior.

As with most roadblocks, we UXers often have to live with them rather than remove them. Removing the roadblock in this case obviously means choosing new tools or creating better frameworks. Sounds good, and worth fighting for, but that doesn't happen overnight. In the meantime, what can we do to detour around the roadblock? Here's my advice:

1. Learn everything you can about the tools and framework so that you know exactly when you are designing something that will force extra effort. Don't rely on the developers to tell you.
   
2. Only design "outside the framework" when it matters. This builds on #1. If you ignore the framework when doing the design, you'll run into situations where you are deviating from the framework randomly, out of ignorance, which causes unnecessary battles with development or forces developers to spend their time on things you don't really care about. When you deviate from the framework, make it count.
3. Build an expectation into the development sizing effort that deviating from the framework is normal. This builds on #1 and #2 - they give you credibility so developers know that you aren't being a hardass for no reason. You want to avoid a situation where any deviation from the framework is considered "extra" work that needs to be separately contained. Assume there will be some deviation upfront, and size accordingly. This is also the key to removing the roadblock altogether - the cost of sticking to the framework needs to be exposed via the sizings.