Product & framework thinkers: Case studies. And how about AI?

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.

Have you ever taken a moment to consider how software gets designed and developed? You might be intrigued to discover there’s often a split in perspectives between two prominent ways of thinking: product thinking and framework thinking. But what exactly does this mean, and how does it impact the user experience?

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

We’ll introduce the two points of view, then give some concrete examples. Finally, we’ll discuss how AI and LLMs might change this picture.

Product thinkers’ aim tends to be an integrated experience for users. Product thinking considers the consumer/user experience as a whole.

Imagine being handed a beautifully wrapped gift box. You just need to untie the ribbon and open the box to reveal the surprise inside. Product thinking is akin to that gift box—it’s a package ready to use, with minimal fuss.

Users need to figure out how pieces of your product fit together? Let’s avoid that.

Technical professionalism often steers towards framework thinking. It asserts that flexibility and re-use is a key priority.

To continue the previous metaphor, a framework thinker hands you a toolbox instead of a gift box. It’s filled with a variety of tools, each with a specific function, allowing you to combine and use them in your own unique way. Yes, it can be a bit more complex, but the payoff is greater flexibility and customization.

Systems like Emacs and more recently, Nix have proven their power to Unix enthusiasts. The challenge is, how to make that power more approachable?

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 integration. Their 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.

---

Manifestations of the Dichotomy

This theoretical divide is evident in a multitude of tools and platforms, and understanding this dichotomy can help us appreciate the design considerations that go into their creation. Let’s explore a few fascinating examples.

Spreadsheets: A Blend of Both

Spreadsheets are a staple tool across many industries and represent a blend of product and framework thinking. At first glance, they offer a straightforward interface for users to input and manipulate data—a classic instance of product thinking. But underneath this simplicity, spreadsheets offer a surprising amount of flexibility through formulas and functions, echoing the framework thinker’s preference for modularity and customization. However, this abstraction can be too oriented towards non-techies, and professional developers may feel it’s just not possible to achieve some tasks they would like to automate.

No-Code Platforms and Visual Programming Tools

No-code platforms and visual programming tools such as Retool are the embodiment of product thinking. They strive to provide a user-friendly experience, eliminating the need for users to write complex code by offering a visual interface instead.

These tools offer powerful building blocks for creating applications, connecting to various data sources, and even providing options for customizing components and importing libraries, all within a user-friendly UI. These platforms attempt to provide a seamless experience with the help of powerful debugging tools and secure deployment options.

I feel also Pharo deserves a mention here. It’s an entire operating system that’s malleable as an object oriented visual programming environment. I have no experience of it, but judging from the website, I feel it may be in a sweet spot between developer flexibility and ease of approachability, especially combined with LLMs.

Databases and Domain-Specific Languages (DSLs)

Platforms like Retool and Airtable, showcase the balance between product and framework thinking. These tools provide user-friendly interfaces and easy-to-use tools for data manipulation, aligning with the product thinking approach, while also offering the flexibility and reusability desired by framework thinkers.

Meanwhile, domain-specific languages (DSLs) add another dimension to this conversation. DSLs are computer languages specialized to a particular application domain, providing a high level of abstraction that allows non-technical users to understand and use them easily. They can be seen as a compromise between product and framework thinking, providing an easy-to-understand syntax (product thinking) while maintaining the power and flexibility of programming (framework thinking).

Advanced Visualization Tools and Feedback

Bret Victor’s thoughts bring an interesting perspective to the product vs framework thinking debate. Victor champions tools that offer immediate visual feedback, thereby empowering creators to experiment and iterate quickly.

Tools like my “Regular expressions you can read“, transform complex concepts into intuitive, visual representations—an embodiment of product thinking. Yet, they also provide the opportunity to delve deeper into the underlying complexity if desired, catering to the framework thinker’s desire for understanding and control.

The Advent of Large Language Models: Blurring the Lines

Advanced language models such as GPT-4 also blur the lines between product and framework thinking start to blur. GPT-4 can be viewed as both a product and a framework.

Disclaimer: I am not particularly advocating the use of LLMs – however, it also cannot be ignored in the discussion since it has the power of changing the above picture a lot.

From the product thinking perspective, GPT-4 can be used as a tool for a myriad of tasks, such as drafting emails, writing code, creating written content, answering questions, and more. It provides a seamless, integrated experience where users don’t necessarily need to understand how the underlying AI works to use it effectively.

From the lens of a framework thinker, GPT-4 offers a highly flexible and customizable tool. Developers can fine-tune the model on specific datasets, adjust its parameters, or build upon its architecture to develop more specialized AI systems. This allows for a high degree of customization and control.

By leveraging the power of AI, these models can help bridge the gap between the raw power of the command line and the intuitive interaction of more user-friendly interfaces. Let’s examine a few approaches for incorporating LLMs into the command line experience.

This space is sure to see a lot of development in the coming years. Expect the below modalities to converge into UIs that have elements of all of them.

Intelligent Command Assistance

One of the main challenges for beginners in using the command line is remembering and understanding the various commands. LLMs can be used to create an intelligent assistant that offers real-time guidance to users. This assistant could suggest the next part of a command, explain what a particular command does, or even provide examples of usage in context. The ability of LLMs to understand natural language can make this interaction intuitive and user-friendly.

Interactive Learning Environments

LLMs can be incorporated into interactive learning environments to guide users through the command line usage. For instance, an LLM could create a conversational, step-by-step tutorial that explains commands as users encounter them. By interacting with the AI, users can learn at their own pace and ask questions in a natural language format. The AI can also evaluate user input, provide feedback, and suggest exercises to solidify the learned concepts.

Natural Language Command Interpretation

LLMs can be employed to interpret commands given in natural language and translate them into the appropriate command line syntax. This approach would allow users to interact with the command line as if they were having a conversation. For example, instead of remembering and typing rm -rf /directory/path, a user could type delete all files in this directory and the AI would perform the correct action.

This also illustrates the need for robust guardrails. There is no undo for “rm -rf”. Should there be one? For example, “Try” is an instance of a tool that tries to create somthing akin to that.

Contextual Help and Documentation

Command line interfaces can be intimidating, especially when errors occur or when using a new command for the first time. LLMs can generate user-friendly, context-sensitive help and documentation that make it easier for users to understand and resolve issues. The LLM could understand the context in which a command is being used and provide relevant help, or explain an error message in plain language, making the process less daunting for beginners.

Code Generation and Error Handling

LLMs can be used for code generation and error handling, enabling users to describe what they want to do in natural language and having the AI generate the appropriate code. For instance, a user could say “Create a directory named ‘photos’ and move all jpg files into it,” and the LLM would generate and execute the corresponding commands. This not only helps beginners but also increases productivity for advanced users.

As for error handling, a core feature of chat UIs for LLMs is that you can keep iterating, i.e. continue the discussion and course correct if something was not readily understood by the AI. Though does not always work flawlessly with the current generation (GPT-4), it is a very natural conversational mode for humans. Interesting times ahead!

Conclusion: A Fascinating Intersection

The dichotomy between product and framework thinkers isn’t a hurdle but a fascinating intersection that gives birth to a plethora of tools and platforms. These creations balance user-friendliness with technical flexibility, which is key to catering to a diverse range of users and fostering innovation.

Understanding these perspectives not only enables developers and UX professionals to better cater to their users but also helps us, as end-users, appreciate the design and development processes that go into the tools we use daily. So, the next time you interact with a piece of software, try to think: is it more a product or a framework?

References

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.