Bring Your Own Abstraction (BYOA)

Apple recently deprecated a favorite development feature of mine—@IBDesignable. Given the direction SwiftUI is heading, it makes sense, but the attribute was a little nod to how even the smallest abstractions can make people effective. @IBDesignable was an attribute in Swift that allowed you to preview and interact with custom views directly in Interface Builder without running the app. It provided a visual way to edit attributes in the inspector and allowed designers like me to make interface tweaks without constantly running Xcode, which took a lot of time for larger applications. This resulted in a huge productivity gain over time.

An abstraction in computer software is a way of simplifying complex systems by focusing on the essential features and ignoring unnecessary details. This could be on the interface, data structure, or codebase. Abstractions are very powerful, and in this next phase of software development, we’ll see Bring Your Own Abstraction (BOYA)1 as a common pattern in authoring environments.

Blockers to BYOA

The concept of a personalized workflow for people is not new, so why isn’t this a norm today? The reason is typically legacy ways of approaching software, adoption, and behaviors of the end user. Three reasons come to mind for me: rigid interfaces, comprehension, and alignment on default interfaces.

Rigid interfaces

Most software is not designed to be personalized, especially in Software as a Service (SaaS). Instead, SaaS’s patterns are modules that can be sold with a bit of customization. There are patterns buyers and users of SaaS software are used to, such as Single Sign On (SSO) and Role-Based Access Controls (RBAC)—common and expected. Where rigid interfaces are problematic is a software buyer usually is forced to make a trade-off on the product’s behaviors as opposed to the people who will use it. For example, simplicity vs. power is a common trade-off companies make. A Marketing team needs to decide between Canva vs. Figma or Wix vs. Webflow.

What skills people on your team have, whether it’s their current knowledge of a tool or ability to learn, is a big factor in how software is decided. Regardless of what you choose, it’s likely someone on the team will be at a disadvantage as a result of the decision.

Comprehension

“Ease of use” and “intuitive product” are common terms when describing product desires. However, they are vague. It’s not simplicity vs. complexity—the capability of understanding something is what’s important. Comprehension is focused on building a “low floor, high ceiling” environment. You can’t define ease of use without having an understanding of comprehension for the end user.

For example, an abstracted no-code site builder is viewed as easier to use by a person who doesn’t know how to build websites. They may find the familiar sliders and switches that allow them to be able to code visually, which is wonderful. However, if you have a person who has advanced level knowledge in programming, the tools might be cumbersome for them to navigate. They may prefer to write their own CSS as opposed to defining each property with a mouse.

Comprehension is dynamic and changes over time. Rigid interfaces don’t accommodate for this and as a result, comprehension is often neglected.

Alignment on defaults

There is an image that goes viral every so often about interfaces. It depicts the typical Apple and Google products; and then shows what your company’s app:

We should strive for an elegant experience to make end users as successful as possible, but you can’t expect all animals in a zoo to shit in a cat’s litter box. Various roles and behaviors have different expectations. Being too abstracted might create more work for people who need to achieve complex tasks while being too complex might create a barrier too great for people to adopt it.

The biggest blocker to tech adoption isn’t access or availability to the technology, it’s the time it takes for people to change their existing behaviors. This was a lesson I learned at One Medical. There were instances where we’d propose new designs that were more tidied and hidden in affordance. The feedback was it created more work for the admin to find the affordance and they were used to having everything in front of them. For BYOA to be a viable concept, you have to build an abstract experience that’s more effective and intuitive than the current behavior.

Designable abstractions

Large Language Models (LLMs), Generative AI, and Cloud Development Environments (CDEs) are pushing for a change. What if there was an @IBDesignable for entire companies? There are three major themes in this next phase of software development:

  • Platform: The API and infrastructure you build for your team and third parties to build off of.
  • Interoperability: How the capabilities of your features compound impact and integrate.
  • Extensibility: Partnerships and distribution with other products and service providers. It allows you to build desired bridges across your moat.

These themes provide capabilities for BYOA to be configured through 3rd party software or built internally. I attempted to draw what this could look like in Eraser. Keep in mind this is not a technical diagram and a rough pass at how a Designer and Marketing Generalist can work in the same authoring canvas with their abstractions.

Diagram made with Eraser

Role-based controls are something that exist today, but it usually is more about limiting a few tabs or features vs. maximizing success. In a world where LLMs can retrieve data and abstractions can be tailored to an individual, we could see a world where the authoring space is completely personalized in real-time.

The Design Engineer will be one of the most important roles of this decade2 and they’ll play a huge role in enabling these abstractions for teams. In addition to working on product architecture, Design Engineers can be the enablers of designing abstractions. Enablement is the goal; of providing the right guardrails to make people more effective. At Webflow, I described this as Bumper Bowling Empowerment, where guardrails are empowered instead of limited. If the Job To Be Done is to bowl a strike, putting bumpers for a less experienced user is a more viable path than expecting them to become a professional bowler.

Building in a BYOA world

I believe this new paradigm allows malleable abstractions, personalized to the end user as opposed to the product or software—allowing everything to be designable. Four factors move us into this world: a shared workspace, new methods of data retrieval, generative AI being an equalizer, and role-based abstractions/workflows.

A shared workspace

In Issue 129, I agreed with many that the desktop metaphor needs to be retired. My proposal is instead of Personal Computers with time-shared commuting, the new metaphor is a shared communal space. Whether it’s the infinite spatial canvas on Figma or an aesthetic structured document like Notion, we’ll see companies adopt common workspaces. In Episode 160 of the All In Podcast (a very academic citation!), David Friedberg predicted Vertical SaaS taking a hit as a result of the advancement of AI and the ability to build tools internally. In 2022, it was reported that 65% of Figma users were non-designers. Figma is no longer simply a design tool. It’s a tool for design work to get done (by anyone). These forces of nature will result in common workspaces that span broader across companies.

New methods of data retrieval

Throughout my career, I relied on close partnerships with Data Scientists to retrieve data for me. I didn’t trust myself. What’s worse than no data is misinterpreting data. Unless you know SQL and Python, it is tough to retrieve data with confidence. The experience is very rigid and specific.

LLMs and new database implementations like vector databases are changing the game. People now have a more natural language experience in retrieving data. In addition to people, interfaces (programmatic or agentic) have the same ability to do this. Abstracting this away removes the need to have interfaces and workflows.

Generative AI as an equalizer

I’ve worked on both ends of the spectrum of code and no-code, and with Generative AI, I can tell you the debate between the two is irrelevant. BYOA is the next phase of no-code. Instead of building an entire product with a rigid interface, Dynamic Interfaces will adapt and evolve based on the end user needs.

Personalized abstractions and workflows vs. role-based

This may be the end of rigid access controls where you group people to a static list of access and abilities. Instead, everyone at the company will have a world-class Bumper Bowling Enablement experience in their day-to-day work. AI-powered workflows will increase organization intelligence and allow dynamic personalization in abstractions and workflows based on the person.

You’re invited to the workspace (BYOA)

BYOA will be like bumper bowling in a tailored article of clothing. The entire experience is personalized to you maximizing your success. What’s exciting is we don’t have to wait to see how this might take shape. We get to define it in this paradigm shift of dynamic software creation.

Manager coverage and scope

People often ask what the different responsibilities are between levels of management: manager, director, and VP. First, there is no perfect way to draw this as organizations are all different. This sketch is an attempt to show different areas of coverage and daily interaction.

1. Team view: Primarily focused on the success and performance of direct reports.
2. Cross-functional: Working with other team leaders across the org
3. Upward: In addition to overseeing larger scope of org, works upward with senior leaders on strategy
4. Company level: Usually executives or department heads. Focuses at the company/board level

Sketch from “the art of experiments”

I made a drawing for this article about running experiments. People often cite Steve Jobs as someone who made decisions solely from intuition so I drew a turtleneck to juxtapose it with data.

Binary thinking stunts innovation. Data and intuition are complementary, and should not be put up against each other. Quantitative data can foster creativity. The new Gmail UI isn’t perfect, and this isn’t a critique of it specifically, but rather an opportune time to discuss experimentation and testing. As Ran Liu says, growth design is good product design. The practice of growth is dear to my heart, and it typically gets a bad rep. Though there are certainly people who mispractice it, growth is not about getting people hooked. It’s helping guide people and teaching them to get the maximum value from your product. As a result, it grows your business. It’s one of the reasons our product pillar that has growth teams at Webflow is called Lifecycle.

Originally posted on Substack

Metaphors and allegories sketches

In issue 92 of Proof of Concept I did a piece about metaphors and allegories. This article covered how you can create metaphors and allegories to discuss really abstract and complex challenges. I made a drawing of a whale to depict Moby Dick, one of the most famous allegories of all time.

Instead of getting frustrated about literalism disrupting the process, find ways to deconstruct it. The reality is developing products is hard, and getting a group of people to have a common language and align on direction is even harder. It’s inevitable that this happens. Metaphors and allegories spark an excellent level of fidelity to building common understanding. Alignment doesn’t happen in one meeting and must be fostered over the course of the product development lifecycle. Let’s look at ways how these figures of speech can be used in the design process.

Original post: https://www.proofofconcept.pub/p/designing-with-metaphors-and-allegories

Startup growth: oil and water

When you join a startup that is growing rapidly, there are usually two groups of people. The first is the tenured employees who were there super early to get the company off the ground with the founders. The second are people who’ve been at other companies that have scaled to where the company desires.

The two groups integrate at first like oil and water. Instead of picking, “this is how we’ve done it” vs. “we did this at company y” the goal is to blend the cultures together.