Beyond the Black Box: Ensuring Usability in GenAI Features with Integrated Design

Intro??

There is no shortage of perspective about the potential for Generative AI technologies to flip the world of digital product engineering on its head. From ideation to design to code to test and release, the potential application of GenAI technology is seemingly limitless. But, if you want to develop a predictable and highly usable application feature backed by Generative AI, both data and experience design disciplines must be joined at the hip.??

Product teams must create an intersection of customer-centric experience design and data led product design to create valuable GenAI features and products. It is not easy, and this article promotes a framework for GenAI feature engineering to bridge these different disciplines and keep your feature releases on the rails.??

?Hypothesis??

?-Data driven design produces products with an expert eye on how the product functions and how the data is delivered to the customer.??

-Experience or human driven design produces products that maximize usability to meet the customer’s needs and expectations.??

-You ideally activate both paradigms for teams designing and implementing GenAI enabled features?

-Otherwise, you have product teams running with one eye closed - when GenAI data teams are not seeing how data interacts with UX and UX teams are not fully aware of what is going to come out of the GenAI Blackbox – which may also be a moving target.??

-To remedy this risk, going deep on data, narrowing the exposure of GenAI application, and maintaining a linkage between data and UX will limit the risk of failure in GenAI product design. ??

Data Housekeeping + Data Deep Dives?

Nobody gets excited when you say, ‘let’s do a data deep dive’ in fact most people will just avoid it or bail out to avoid boredom and minutia. Getting the source data in order is a foregone conclusion for any data centric product. But product teams must establish an intimate understanding of data from source systems as an input to LLM (Large Language Models) type systems.??

Given we do not have full control over LLM behavior, only guardrails through curated datasets and parameter tuning options, exerting high control over inbound data at least corners one set of variables you ‘can’ control. To the contrary, putting blind faith into GenAI systems to parse through good and bad data alike is more or less setting some bets and adding a dash of hope into a backend system you don’t truly have full control over.?Trust in GenAI is necessary, so measuring this risk is best served through prototyping and ongoing refinement cycles through the course of product development. ?

To effectively design products for GenAI, you have to go far beyond establishing a clean base dataset. Here is an approach to deepen the connection between the source data and GenAI data science teams ingesting and using the data:??

Data Schema - Map out the data sources and content definitions, including flow diagrams for point-to-point data origination, transfer, and ingestion. ?

1. Structured Data - Will have a schema?

2. Semi-Structure Data – Will have a partially defined schema?

3. Unstructured Data - Will not have a defined schema, will require some structuring

Data Dictionary - Detail data fields, types, and content, noting any special conditions for data longevity, refresh, dependencies on tertiary systems, and data security/governance concerns (e.g., PII (Personal Identifiable Info), PHI, etc.) will be paramount in production. The data dictionary tends to be not that important for development teams but will be critical for data ingestion, classification, usage, etc. And can serve as a keystone for data classifiers for model training and ingest.???

Data API / Transfer Layer - This is often a starting point, but starting with API definition can jump past key data details covered through the detailed work above so ideally this comes last as you establish a final view of architecture and data pipelines.??

Lastly, do not wing it with partial / low quality training data - go for clean data whenever possible and take the traditional approach of good data first for training and testing. One of the major pitfalls is assuming LLMs (Large Language Models) have magical powers that overcome inherent gaps in data quality. The garbage in / garbage out principles of systems design still very much apply.??

Design using Narrow Exposure of GenAI outputs??

The characteristic of LLMs to handle and process large volumes of data can lead product teams to design expansive features that exceed the realistic performance of the backend systems. This raises into question: Is it better to design from a narrow or wide exposure perspective for GenAI features? Do you go big, and hedge bets the LLM will overcome variability in source data, or do you narrow the ingest scope to create more control over what goes into the GenAI environment??

Wide Exposure - Factors large scale inputs and outputs and carries a lot more risk associated with data quality, model performance, dependencies on good training data. A wide exposure approach can result in a vast and unwieldy volume of outputs. This makes it difficult and time-consuming to sift through the generated content, identify the most relevant results, and curate them for user presentation. This can lead to inefficiencies in the design process and potentially compromise the quality of the final product.?

Narrow Exposure - By limiting the range of input/output, a narrow approach allows for more curated control data of control over outputs.??

A "narrow exposure" approach, where GenAI is applied to specific feature outputs with more curated control over the data and parameters, is a more desirable approach. This approach, while potentially limiting the range of outputs, allows for greater control, predictability, and mitigation of the risks associated with a more variable and wide exposure approach to GenAI in design. In concert with guardrail LLM features, the more control the better to ensure a highly predictable result from Generative AI systems.??

A Suggested Framework for Linking Data and UX for a GenAI Product Build?

• Prototype early - ensure GenAI tools are actually fit to requirement and rule out non-contender platforms, models, and services. Keep in mind GenAI is not always the right solution and it is best to keep an open mind to which service architecture best suits the use-case before landing on a specific GenAI service and model for implementation.??

• Perform iterative reviews of GenAI system call and response, and keep these going as you build not just during prototyping??

• Actively link your data and design authorities during all phases of design and build ?

• Keep the data team wired into Design reviews??

• Perform End of Sprint Showcases for Front-End?

• Perform weekly backend showcases and keep the front-end and design people involved??

• Look for earliest opportunities to integrate functional data from GenAI into application builds - the sooner the better to get a complete picture??

• Like ML (Machine Learning) projects, keep your data team engaged on tuning, refinement, and defect identification as some churn is to be expected from GenAI systems??

Some Examples of Why an Integrated Approach is Necessary:??

Here is a notable example: In working with a product team for a recommendation's engine, we uncovered the lack of notifications for the user in the final design, while other less critical notifications were covered. It only became evident we missed this feature when discussing recommendations output frequency with the data/genAI team. The miss was simply a result of not looking at data and UX at the same time. How about notifying a user when they get new recommendations (important!)??

Another example is error state conditions: A search query could fail due to no results from the backend GenAI system. How this is handled in relation to user errors and fallback conditions must be handled. In this case design did not have insight to the data edge cases so the error state conditions were handled by changes to backend logic for fallback messaging. This approach avoided a front-end redesign and got a similar result, but ideally would have been covered in design as a core use-case.??

The Wrap?

Data and experience-led design can be integrated to create effective and valuable GenAI product features. If teams neglect this, they risk building products that don't meet user needs or use GenAI's full potential. Advocate for a shift in mindset, urging product teams to abandon siloed approaches and recognize that data and UX design are fundamentally interconnected. ?

To successfully integrate these disciplines: ?

Prioritize a thorough understanding of data?to provide the GenAI system with high-quality input.?

Carefully consider the scope of GenAI application feature: A "focused application" approach emphasizes predictability and control, while a "broad application" approach allows for greater exploration and a wider range of outputs. ?

By adopting these principles and fostering full-lifecycle collaboration between data and UX teams, we can harness the power of GenAI to create innovative, user-friendly, and transformative products and features. ?

#GenerativeAI #ProductDesign #UserExperience #AIInnovation #UXDesign

#AIProductDevelopment #DataScience #MachineLearning #DataDesign

#ProductEngineering #DesignThinking #InnovationStrategy #DataDrivenDesign