Product and framework thinkers: When developers and UXers don’t get each other

See also: Usability and being human blog

Developers and UX professionals often seem like beings from different planets. I’ve found that shared understanding about software project goals can sometimes be hard to achieve.

Product and framework thinkers is a helpful way to reason about this (Reichelt, 2009).

  • Product thinkers’ aim tends to be an integrated experience for users. Product thinking considers the consumer/user experience as a whole. Users need to figure out how pieces of your product fit together? Let’s avoid that.
  • Technical professionalism often steers towards framework thinkingIt asserts that flexibility and re-use is a key priority. Let’s give our users freedom to combine the tools the way they want them.

Value means different things

Modularity is a key value for framework thinkers. Unix philosophy comes close, too. Framework thinkers don’t necessarily empathize with what they perceive a consumer attitude. They are often builders themselves. They want access to what the thing is made of and they wish their users did, too.

Product thinkers tend to be more oriented towards integrationTheir criticism towards framework thinkers may be that framework thinkers tend to overload users with options — making the user experience worse. Sometimes people just want to get the job done – a job where the inner life of the computer may not be a central focus.

The tension between user simplicity and system flexibility reflects a fundamental challenge in HCI (Human-Computer Interaction). As pointed out by Jakob Nielsen’s “paradox of the active user”, users tend to focus on immediate usability over learning more powerful system features. Balancing these needs is a recurring theme in the literature.

The dichotomy also resembles the debate between user-centered design (UCD) and system-oriented design in the UX literature. Product thinkers’ approach aligns with UCD, emphasizing the user’s needs, goals, and context of use. They focus on building intuitive, seamless experiences, in line with Don Norman’s concept of “invisible design” where the best design is unnoticeable because it fits so well with the user’s needs and tasks. Framework thinkers, however, resemble system-oriented designers who focus on technical requirements, modular architectures, and system efficiency, often giving users more control but at the cost of increased complexity.

Finding common ground

Product thinkers are focused on the reality of the market of customers out there. They aim to evaluate the abstraction level appropriate for target users. A pile of lego blogs, or a ready-to-use solution? Perhaps something in between — a suitable mix of flexibility, and ease of use? They may want to decrease need for documentation. Instead, they learn about the the user and their goals. Based on this, they prioritize what to present, and when.

“Product thinkers take users to be more simple-minded than they are!” 
This is something you might hear from a framework thinker. Integrating products too tightly results in users losing freedom —and so, degraded UX. Documentation is the natural price users must pay if they want the power of the software.

Both product and framework thinkers aim to provide good service to users. Their approaches to this are different.

Hope to gain favor among your group of users? Your product will need integration and top-down design. To suit various needs though, your architecture will also need flexibility, and documentation to match.

Should you emphasize product or framework thinking? Depends on the kind of software product you are building.

Professionals might use the software even if it has a poor UI, if they are committed to the need it meets. They may be willing to spend the effort and wade through extensive documentation. Applications for non-developer users will nonetheless require more careful thinking of your users’ goals. Bad UX puts you in a vulnerable position in any marketplace.

What is important here is to be aware of the differences of thought when discussing goals. If the makers and builders understand each others’ motivations, they can achieve a common vision. What’s that?

Get something out the door that is valuable to your users.



Reichelt, L. (2009, October 12). Designing for the wrong target audience (or why Drupal should be a developer tool and not a consumer product). disambiguity. Retrieved May 27, 2010

Adapted from my thesis.

Leave a Comment