Generative UI: A First Look at v0

Introduction

Recent advancements in AI coupled with growing interest in low and no code movements has led to the emergence of a new class of tools. These tools leverage the power of AI enabling Users to generate UI without having to open a code editor. One such tool is v0 developed by Vercel and currently in beta release. Curious to understand how tools like this would support the development of Enterprise applications, we conducted a simple study to determine its efficacy. It was anticipated that such a study would enlighten us to the capabilities and limitations of this particular tool. This will be especially informative and useful given that the tool is relatively new and there is a current lack of comprehensive documentation (understandable as it’s a beta release).

We identified 3 candidate features that are commonly found in Enterprise applications and which will present complex challenges in code generation, namely:

To assess the suitability of v0 in developing these UI components, we outlined a set of evaluation criteria:

It’s worth bearing in mind that the main focus of this exercise was to generate components that closely match functional requirements. Less attention was paid to the appearance other than to make the components visibly acceptable.

The UI for v0 is quite simple as shown below. It offers you a prompt input where you request the component to be built. The app will initially offer you 3 variants and you select the one you like best. Thereafter it will refine the design and implementation of the requested UI based on a series of prompts. You can ask it to add/remove elements, style things in specific ways, and there is a gallery of components built by others from which you can gain inspiration.

The 3 components we generated with v0 are discussed below.

Form component

The initial task set for v0 was to generate a Form component. Forms are ubiquitous in many web applications and can consist of many different types of inputs such as Date Pickers, Drop-downs and other such controls. Another characteristic of Forms is the ability to validate User input. This exercise will be useful in determining how much of a fully functioning form can be generated by v0.

The image below shows the form that was generated with relatively few prompts:

The component was generated in real time within a matter of minutes and using a small number of prompts. Each iteration to refine the UI took several tens of seconds - more time was spent on designing the prompt.

Note that the form has a functioning Date Picker:

It handles drop-downs as well:

The file upload opens File explorer when clicked on. Further iteration could have refined the design, but the current implementation adequately addresses the question of form generation capabilities.

The next step was to assess v0s ability to handle form validation. We asked it to add validation to ensure that the user must enter 3 or more characters in the ‘Name’ field. It responded with this:

This was a bit of a surprise, v0 is supposed to use shadcn’s impressive component library under the hood, which does contain form components based on the React hook Forms Library. We would have expected that this would feature in the generated code. It has also incorrectly generated the name and value type of the minLength prop. Fixing this was straightforward though, and just involved changing the prop to camel case and its value to a number:

During this small study, this was the only error detected in the generated code.

With the rise of frameworks such as Next and Remix, it’s easy to forget the original philosophy of React, which is that it is unopinionated. It leaves it up to the developer to decide how they will perform certain tasks such as i18n, validation amongst others. In a similar vein it makes sense for v0 to provide the skeleton for a form but leave it up to the developer how it gets wired up. There are multiple ways to implement validation with React based forms. You can use native HTML props, roll out your own library or use popular ones like Formik and React Hook Forms. Additionally, you can use different validation schema libraries such as Yup or Zod. With v0 not wiring in these, it gives you the power to choose your own validation approach. It’s not yet clear if it’s on the v0 roadmap to support form validation.

Table component

Tables feature quite heavily in Enterprise applications. Often, they can be quite interactive, rather than just presenting data in a read only format. Consider some of the features in these dynamic tables:

With these requirements in hand, we asked v0 to generate a table component for Invoices, the result of which is shown below:

The output was once again impressive given the small number of prompts. Here it has rendered the correct number and type of columns. It has made “Amount” an input field, added a funnel icon next to the Status column header, both of which were requested. When you hover over the latter it shows you a popup where you select the values you want to filter by.

In the Actions column, we asked for a three dot menu, which on hover should reveal a menu with the options: View, Edit, Delete and Mark as paid. It failed to render a vertical 3 dot icon replacing it instead with an “*”. However, if you hover over this icon, you get the pop up menu as requested.

Despite requesting the table to be sortable and filterable, no such functionality was generated. This shouldn’t be too much of a problem wiring up - The documentation on the shadcn/ui <Table/> component provides sufficient details to get this working yourself. We asked for pagination, and it generated basic controls. More time could have been spent refining this component, but the generated UI was sufficient to provide us with the required information. Just like the Form component described above, v0 will generate the structure for the table. Enabling dynamic behaviours like sorting, filtering, editable inputs will require further logic that you have to wire in.

Dashboard

The final challenge was to see how well v0 performs in generating Dashboards. These are screens which can be data intensive and may contain different visualisation components.

We asked v0 to generate a Dashboard with some KPIs, a line graph and bar chart to show sales and number of visitors respectively. Additionally, it should also show a table reporting on Projects. This table should have a budget column displaying a ‘progress’ bar indicative of how much of the existing budget has been spent. Hovering over this progress bar should indicate the actual spend.

The result above was again achieved through a small number of prompts. It’s clear that v0 does not yet support the generation of charts hence the placeholders. Yet it managed the generation of the other components reasonably well. The mini progress bar for Budget functions as expected.

Adding a charting capability to v0 doesn’t seem unachievable. In a similar fashion to adopting shadcn/ui library, the AI behind v0 could be taught how to incorporate such visuals using a popular charting library. However, whether this becomes a feature, is likely to depend on market demand.

Discussion

The study far from being comprehensive provided some valuable insights into v0. Firstly, it took a small number of prompts (< 15) and less than 10 minutes to generate components for each use case, that to some extent matched the requirements. This is quite impressive. To top it up, it was a nice user experience to watch your generated responses stream into existence, a nod to the recent developments in the Next.js space.

Secondly, it helped answer the questions set out at the start of the study.

How easy/difficult is it to generate the component?

Using v0 required no special skills other than using a keyboard and being able to articulate your requirements - The subject of prompt engineering is a relatively new one and may help in utilising this tool to its maximum potential. There is however some developer expertise required to take the generated output and integrate it into your application. There are 2 things to bear in mind here:

A derived benefit from its simplicity is that it will help foster better collaboration between multiple stakeholders such as Product Owners, Designers and Developers. With this tool, it will be possible for team members to quickly iterate through designs, ideas and convert these to usable code efficiently and quickly.

What is the code quality of the generated component?

It’s pretty good. Nothing surprising here as the generated code is mostly JSX. It performs component composition by coupling regular JSX DOM elements with components from the shadcn/ui library. Styling is achieved via Tailwind, a popular CSS library commonly used in Next.js applications. Here’s a partial snippet of the generated table code:

Is the generated code free from errors?

From the small exercise that we performed, there was only one error that was generated (see Form validation above). The study isn’t large enough to conclude how susceptible v0 is to error generation. However, from the code that has been generated, there were no frequent occurrences of serious issues.

Are the generated components accessible?

Yes - the basic building blocks used by v0 are from the shadcn/ui component library, most of which are built on top of radix - a component library that has accessibility baked in.

How easy is it to customise the generated UI to match a company’s branding and style guidelines?

There is no concern here on the ability to modify the generated UI. The tool allows you to adjust layout and styling enabling users to generate components that fit their brand.

Can the generated UI be customised? Can we take what is generated and extend its functionality?

The generated code is constructed using standard DOM elements and pre-built components from the shadcn/ui library. This open-source library allows you to directly install the source code of individual components. As a result, the output from v0 encompasses the complete source code for rendering your generated component, empowering developers to refine and modify the behaviour of any of these components.

How easy/difficult is it to integrate the generated code into existing code bases ?

It’s very clear from the generated code, that v0 provides you with code to build the component. However there will still be some work required to wire this component into your applications. Consider the Form component. How is its state going to be managed? Do you use Formik, React Hook Forms, something else? The tool has done its job of generating the skeleton code, and leaves it up to consumers how it should be wired in. It should be noted that v0 is not yet capable of generating a complete application. One key missing ingredient is the ability to fetch data. This has been recognised in the v0 FAQ and there is suggestion that this may feature on the roadmap at some point. It will be interesting to see how this pans out especially given the developments around React Server Components and Server Actions.

Code generation has been an area of active research for many years, giving rise to a variety of techniques. Approximately 15 years ago, I was involved in a project that employed a Model Driven Approach, where the data model was designed using a UML drawing tool. This tool generated XML, which was then fed into an open-source library that produced Data Transfer Objects (DTOs), EJBs (Enterprise JavaBeans), and Hibernate configuration and logic (Now there’s an idea - v99: a tool to generate a full blown Next.js app using prompts).

An earlier version of this tool generated actual code instead of interfaces and DTOs. However, this approach proved problematic, as any updates to the model would overwrite code that had been manually modified. This raises an intriguing question regarding code generated by v0 and a common scenario in software development. Consider a situation where the UI design has been finalised and the corresponding code generated. What happens when requirements and, consequently, the design change in the future? How can we effectively apply these modifications to the originally generated code, which may have evolved over time? One possible solution is to limit the scope of generation to smaller sections of the screen, rather than output of entire screens - this should help simplify the complexity of evolving code through design updates. This approach appears better suited for complex UIs than for simpler screens, such as landing pages.

In its current form, v0 may encounter some barriers to entry in the Enterprise Application arena.

Firstly, large organisations tend to use Design Systems to optimise consistency, aesthetics and scaling in their product suite. As such, they tend to invest heavily in tools like Figma. This would make alternatives such as Anima and Locofy more attractive investments - tools that generate React code from designs. However, a recent announcement suggests that Vercel are adding a ‘Vision’ capability to v0 - a development which could potentially help lower the threshold to entry.

Secondly, these large organisations will have typically developed their own component libraries over some time and with considerable cost. Consequently, there may be a reluctance to introduce a new library into their eco-system. Interestingly, the v0 FAQ suggests that Vercel would look into accommodating custom libraries into the generative process given sufficient interest. These two issues raise an interesting question. The AI behind v0 will have been trained across a large number of inputs from various sources. Is it possible to tailor its generation of solutions based on individual preferences? Can it learn to generate UI that is tailored to a specific organisation?

In conclusion, v0 emerges as a valuable tool brimming with potential in the area of Generative UI, offering benefits that include:

With v0 currently in its beta phase, we eagerly anticipate the ongoing advancements and refinements that lie ahead.