The UX issues of development frameworks

Does a framework need a UX study?


Lorenzo Doremi

2 years ago | 9 min read

Here you are, scrolling an infinite list of design job offers that require development skills. You’re a designer who tried some HTML and CSS in the past, but when JS walked in, the problems started arising: variables, functions with absurd semantics, interfaces, callbacks. What the hell is even a callback?

These are issues most people face when starting with a new programming language, both if they’re beginners or more experienced coders. But why do some languages seem so cryptic?

Because they’re designed by coders.

Thankfully, the more coders are needed in the industry, the more people are starting to design more friendly development frameworks, both for web and mobile. In fact, developing today is a lot easier than it was 20 years ago: frameworks like Vue, React.js, and Flutter are (slowly) replacing vanilla JS and Java, finally forcing you to not reinvent the wheel every single time you open your favorite code editors.

(yes React.js it’s a library, not a full framework. I know).

Since frameworks aren’t traditional products like apps or websites, two main questions arise:

  1. Does a framework need a UX study?
  2. How can we improve a framework design?

Does a framework need a UX study?

Do people use a framework? yes. Are frameworks designed to become a standard? yes. Then, it’s supposed to be an attractive product that people actively choose: the answer to our questions is yes.

Often, when designing something, we tend to believe that concepts and processes we own are collective, but this is plain wrong. If you’re a UX designer, you know what personas are, what personas are used for.

This principle applies to frameworks too: you must not design it based on your coding abilities, but both on beginners/non-programmers and experienced coders.

Photo by 金 运 on Unsplash

How can we improve a framework design?

Even if currently I am mainly a UX/UI Designer, I have to develop pretty often. I started coding around 5 years ago, starting from vanilla JS, then JAVA and PHP+MySQL, and now Dart.

I had no culture on framework development since my teachers didn’t too, so I found out myself learning multiple frameworks at once in the last two years. The first one (except for Bootstrap, which is technically a mark-up framework) has been React.js, while the second which I am currently using every day is Flutter for mobile development. I had a brief experience with Django too, but it didn’t last much. And well, they’re great. But.

Experimenting with multiple frameworks and libraries, I noticed a lot of minor issues which led, paradoxically, to huge frustration. I wondered why they designed a good framework and completely didn’t care about these things: they basically neglected some basic design principles but excelled in others.

Let's discuss 5 common UX issues of development frameworks I noticed these years, and some tips to enhance the development process.

5) Installing/Onboarding

I know that developers love the fashion of command-line shells, but installing a framework shouldn’t be painful like it’s nowadays. Even Github is slowly evolving to drag-and-drop: the future of Human-Computer-Interaction is going to be gestural and vocal, so don’t be scared creating at least some executables.

Flutter tried to simplify the installation process via Android Studio, but something went wrong. (AS’s fault I guess).
To make Flutter work, I had to spend around 6 hours on forums finding a solution and then fixing the Flutter SDK not being properly installed and erasing 
random default proxy settings that made Gradle not work.

Thank you Android Studio for blocking me.

(my colleagues thanked me later for the 3 pages tutorial I made for them)

Some other colleagues couldn’t even install it in the end, because being behind particular firewalls.

Tip: Installing should be the easiest part, and making it buggy or nonlinear could make beginners hesitate a lot about your framework.

4) Readability

Oh god, Flutter what are you doing. I understand that “widgeting” everything is your philosophy, but sometimes it is just unneeded.

// Questo è un text input riutilizzabile in vari contesti. Functional Component.
Widget reportTextInput(TextEditingController controller, String label, bool enabled) {
padding: const EdgeInsets.only(bottom: 32.0, top: 16),
crossAxisAlignment: CrossAxisAlignment.start,
children: [
// questo è il titolo del textfield
Text(label, style: TextStyle(color: themeText, fontSize: 18)),
// questo gestisce la distanza tra label e input
padding: const EdgeInsets.only(top: 16.0),
enabled: enabled ,
decoration: InputDecoration(
hintText: enabled? "inserisci in kg o cm" : "ci pensa ABMeister!",
filled: true,
fillColor: enabled ? themeInputBackground : Colors.
borderRadius: BorderRadius.circular(16),
borderSide: BorderSide(
color: Color.fromRGBO(150, 150, 150, 0),
borderRadius: BorderRadius.circular(16),
borderSide: BorderSide(
color: Color.fromRGBO(150, 150, 150, 0),
borderRadius: BorderRadius.circular(16),
borderSide: BorderSide(
color: themePrimary,
TextStyle(fontSize: 16, color: themeText2),
controller: controller,
validator: (value) {
// siccome è molto complicato il validatore, ho creato una versione semplificata
if ( value.isEmpty && enabled || double.
tryParse(value) == null) {
return "devi inserire un valore";

return null;
onTap: () => {
setState(() {
controller.text = "";
// fontColor = Colors.black87;
keyboardType: TextInputType.
inputFormatters: <TextInputFormatter>[


The horrible thing you see up here is an extremely simple reusable text input functional component I had to code in Flutter, since putting 4–5 hardcoded inputs in a form would waste around 400 lines of code.

It’s a single input, but it has to be composed of five main widgets, and each of them has different style properties that resemble widgets again (OutlineInputBorders for example). Also, to remember every detail, I had to flood with comments the full mess.

Even the traditional android development XML is more readable:

One widget, multiple styles.

React.js on the other hand is incredibly easy to read with JSX, which empowers HTML with simple and useful features like props.

random JSX syntax.

I do not even want to talk about Python and the absence of punctuation. 1/10. Subjective.

Tip: Code should be able to scale and still be readable to at least 1000 lines of code. Classes in Java are around 100–150 lines, but in “half-markup-half code” classes like in Flutter, this number enlarges a lot: a simple 5 questions form in Flutter goes for around 400 lines.

3) Feedback

Flutter finally shines. Error notifications are extremely deep and try to explain every possible mistake you’ve done.

This is extremely important because it accelerates the learning process a lot: the framework self-explains itself.

On the other hand, React.js and JS in general just tell you what happened, without proposing any solution.

Oh you, Windows XP.

Tip: Force yourself to design a better standard error notification. By using Pareto’s Principle, you probably can write enough solutions.

2) Mapping

I’d love to easily understand what is exactly happening in every moment. Also, a framework should use clear terminology for its fundamental objects.

Speaking of Flutter, one great example of “below-average” mapping is the Provider class.

Provider works with the sister class Consumer, but both terms do not really mean what they mean: the Provider is a state manager/event notifier, while the Consumer is a listener.

I developed for three days thinking I was using the wrong class, but I wasn’t.

Tip: Just use clear terminology.

1) Simplifying / Constraints

As the job of a UX designer, the job of a framework is simplifying processes. If your framework just complicated things, throw it in the trash.

Thankfully, most frameworks really simplify coding, but there are some examples I could easily show you that make every user’s gears grind.

Common issues not being automatically solved

If you ever developed with Flutter, you have seen for sure what I am going to show you:

Everyone who has used Flutter got a pixel overflow exception. And how to solve it? well, you have to stack a load of “senseless” widgets every time you develop a piece of UI. I just ask myself why. Flutter should simplify UI development, and something so simple as constraints isn’t implicit?

Stackoverflow is full of people angry about this issue, so I am not the only one.

Widget -> Container -> ListView -> Expanded.

A similar thing happens when you want to make a child’s size relative to the parent: you need more widgets (LayoutBuilder).

A lot of people encounter similar issues in React.js: some obvious things like using additional JS, exporting multiple variables, or importing fonts or images in CSS are overly confusing and often do not work without particular configurations.

Tip: When designing something, you should at least ensure that common problems of beginners are automatically solved by your system. Heterogeneous User testing is fundamental.

Constraints when unneeded.

Constraints in a product are fundamental and should lower the number of errors a user can do, but they should fix problems, not increase them.

One thing that frustrates me in Flutter is forced async. I perfectly understand how it affects optimization in a positive way (I loved developing a triple thread plane flight monitor), but if I am calling a single variable inside SharedPreferences, do not force me to use a FutureBuilder and double the code lines.


The main issue I found out in years of development, is that most frameworks seem to forget the needs of beginners, and spend so much time on advanced features while neglecting basics.

In my opinion, the main concerns when designing human interaction with a framework should be:

  1. Easy installation.
  2. Readability.
  3. Extensive feedback on error.
  4. clear terminology mapping.
  5. Define common issues and solve them.

Feel free to criticize my ideas, since everyone’s experience with programming is different.


Created by

Lorenzo Doremi

A Jack of all trades UX guy. Mainly interested in human-computer interaction, contemporary sociology and art.







Related Articles