Since the launch of Google Bard in its experimental phase, many UX professionals have been eager to try out this new tool and evaluate its ability to provide a high-quality conversational experience.

I decided to analyze the usability and user interface of Google Bard to help other UX professionals and enthusiasts better understand the potential of this new tool.

In this review, I will discuss my experience with Google Bard, evaluating its ease of use, effectiveness and efficiency, and highlighting its main features and considerations when evaluating artificial intelligence-based conversational tools.

This review is helpful for those who are looking for an unbiased evaluation of the Google Bard user experience and are interested in learning more about UX best practices for artificial intelligence-based conversational tools.

Cognitive Learning

People learn through observation, experience, and interaction with their environment. When people are exposed to familiar and predictable stimuli, such as Google's "I'm Feeling Lucky" or "Google Search" button, they tend to develop automatic expectations and behaviors, making it easier to interact with the interface. That is, one button shows the result directly, and the second a list based on the searched term.

"Google it" button from Google Bard.

It turns out that the "Google It" button in Google Bard does not do the direct Google search, even though the label suggests it.

Google it" button: instead of googling directly, it suggests topics derived from the question.

There are two clicks before the action of searching Google (the first one activates a segmented pre-search, and only after the second click is the user directed to Google). For this reason, the user's expected behaviour can be frustrating. For example, the user may expect this button to do a direct Google search but find that he has to perform two additional actions before seeing the results.

Confirmation bias

After the user clicks the "Google it" button, three options appear. Besides limiting the search context, it is unclear to the user what criteria Google uses to include related topics.

"Google it": Three options appear after the user clicks the button.

You might think that the related searches are based on semantic search, but if someone is in the USA, what interest would they have in companies from India? 🤔 Ok, Bard has included a disclaimer stating that the information might be inaccurate, but let's focus on the interface.

By using only limited topics in the search suggestion, the tool can lead to a biased selection of information and options for the user.
This is because confirmation bias is related to people's tendency to search, interpret and remember information selectively, preferring information that confirms their previous beliefs and ignoring information that contradicts them.

Interrupted task flow

Also, in this context, if the user wants to search for the exact term used in Google Bard (in my example, "Create a list of top 50 companies based on the Forbes Global 2000") as the "Google it" button suggests, he cannot do so in the tool. Instead, the user must leave the device and do it directly in Google. This encourages the user to search for external information, which is unpleasant for a tool in an experimental stage trying to maintain a smooth experience and consolidate itself in the AI industry.

Placeholder is hard for lay users to comprehend

The term "prompt" is not a standard or familiar term to all users, especially those unfamiliar with programming or computer language. This can lead to confusion or uncertainty about what is expected of the user when entering a "prompt". I was curious to figure out who are the users. 🤔

Google Bard — Search field

Using the term "Enter your prompt here" in the Google Bard search field is not ideal regarding UX best practices because it is a generic and unclear description. However, the placeholder could be better for more clarity and guidance.

Lack of clarity: The description "Enter your prompt here" is unclear as to what the user should enter in the search field. It needs to be made apparent to the user if it is a question, a keyword, a phrase, a complex question or even if the search system is like Google's (affordance problem).

Lack of guidance: The description needs to guide how the user should enter the prompt.
Google Bard uses a couple of hints on the first page to help contextualize the use, but the feature does not replace the placeholder function, which should be direct and instructive. A clearer, more user-oriented description would be more appropriate.

Inadequate response when user connectivity is lost

When a user faces connection problems, the interface is expected to provide an immediate and helpful answer to prevent frustration and potential abandonment of the platform.

When there is a connection loss using Google Bard, the interface can present a long wait time to display the error message. This can lead the user to believe that the application is stuck, is elaborating the response, or there is no response to their command. This lack of immediate response goes against the Law of Feedback, which states that the answer should be provided reasonably to keep the user informed of what is happening.

In the example below, it took almost 30 seconds to wait for a response back from the tool, which could not complete the task because there was no internet connection.

No connection: error message appeared only after 30 seconds.

Providing clear and immediate feedback to users in response to their actions is essential. When the platform does not provide an adequate response to the lack of internet connection, the user can become confused and frustrated, which can damage the user experience and affect the perception of the tool.

To solve this problem, it is possible to implement techniques such as loading indicators and customized feedback messages for different types of errors.

Sparkle Thinking vs Law of Continuity

Google Bard — Sparkle (Thinking)

One UX law that addresses the use of typing animation is the Law of Continuity. This law states that users expect the actions performed in an interface to have a logical continuity; that is, the visual changes that occur in response to the user's actions are consistent and predictable.

However, as I mentioned in the previous example about waiting time, this differs from the Sparkle icon. Therefore, it is essential to ensure that the animation works correctly across different operating systems and internet connections, with a realistic duration and consistent with the size of the text entered by the user. This will ensure that the user experience is always positive and consistent.

A typical typing animation to indicate a waiting mode in a virtual chat

The idea of using a typing animation is to ensure that the interface creates a sense of logical continuity. The typing animation gives the impression that the user interacts with the search field or form in real-time, as in the example above.

Sparkle resting vs Law of Similarity

If the indicator is resting, why is it in motion? 🤔

Google Bard — Sparkle (Resting)

Sparkle's animation may look nice, but the continuous movement of the colors may give the impression that the user is interacting with a dynamic field, despite the animated icon feature being used after the tool responds to the user (resting state).

We tend to stick to familiar patterns and forms of interaction that we already know and adapt to them quickly according to the Law of Similarity.
The fact that the animated element looks like a macOS "loading" icon can add to the confusion; some users may think that the page or chatbot is still loading rather than being in a "resting state" (an assumption that can be tested). This can create incorrect expectations.

Room for improvement: CSS property

Inappropriate use of the CSS property impacted the usability of interface elements, including the avatar and the scrollbar.

Avatar and scrollbar (highlight): elements impaired by the cut-off view within the main component.

The problem in Google Bard's scrollbar occurs due to its location within an element with the "overflow" CSS property set to "hidden". This property is used to hide content that exceeds the boundaries of the main component but also has the side effect of hiding the scrollbar when it is displayed.

Using the "overflow-x" property instead of "overflow" could solve this problem by controlling the visibility of the horizontal scrollbar separately from the vertical scrollbar to ensure that the scrollbar is displayed properly.

As for the avatar, a tweak in the CSS code ensures that the avatar is sized correctly and that there is enough space around it to ensure it is obvious.

Room for improvement: Sticky header

One of the improvements that could be made to Google Bard is implementing a fixed question at the top of the interface. This would give users a better understanding of the task and the ability to navigate the tool more efficiently, as the user's question would remain fixed at the top of the screen, even when scrolling through the page.

Continuous scrolling does not help the user to re-access or edit the question.

The navigation header or menu remains fixed at the top of the screen, even when the user scrolls down the page. This allows the user to easily access the navigation options without scrolling back to the top. In addition, the user can make faster and more effective decisions by providing a fixed question at the top of the interface, such as reading and editing it.

Room for improvement: Copy button

The fact that the user needs to access the three-dot icon to copy an answer in Google Bard can be considered a usability flaw.

Copy button: simplifying access can help reduce cognitive load.

It is crucial to reduce the cognitive load on the user whenever possible. To achieve this goal, it is recommended that essential functions are clearly visible and accessible without requiring the user to perform multiple steps or search for them.

In the case of Google Bard, the option to copy the answer is a necessary action that the user may want to perform regularly. Therefore, this option is recommended to be easily accessible via a clearly visible button.

Final thoughts

Due to the experimental phase of Google Bard, this is a valuable opportunity to provide feedback and contribute to the development of the tool.

Although I have analyzed the usability of Google Bard in its beta phase, my observations are based on my own experiences and opinions. Furthermore, usability perceptions can vary depending on the user and the conditions under which they are tested.

Finding a balance between adhering to design principles and exploring new directions that push the boundaries of what’s possible is key.

By embracing experimentation and innovation, we can create designs that meet users' needs and delight and surprise them.