Figma-Praxisbeispiel digitales Fotobuch: Integration, Logik und Feinschliff

Im ersten Praxisteil wurde aus einer einfachen App-Idee mit  ein klickbarer Prototyp für ein digitales Fotobuch erzeugt. Der KI-generierte Prototyp zeigt in erster Linie, wie sich die Anwendung anfühlen soll. Nutzer sehen eine Galerie, wählen ein Foto aus, öffnen eine Detailansicht und bearbeiten Informationen. Für Entwickler beginnt an dieser Stelle die eigentliche Arbeit. Die sichtbaren Elemente müssen in Datenmodelle, Komponenten, Zustände und Aktionen überführt werden.

Im Beispiel des digitalen Fotobuchs lassen sich mehrere Grundelemente ableiten. Es gibt eine Liste von Fotos, jedes Foto besitzt ein Bild, eine Ortsangabe und eine persönliche Notiz. Zusätzlich benötigt die Anwendung einen Zustand für das aktuell ausgewählte Foto und einen Zustand, der angibt, ob die Detailansicht gerade angezeigt oder bearbeitet wird. Was im Prototyp wie eine einfache Kartenansicht aussieht, wird in der technischen Umsetzung zu einer Kombination aus Datenmodell, UI-Bindung und Interaktionslogik. Eine mögliche Modellklasse in C# könnte so aussehen:

public class PhotoEntry
{
    public string Id { get; set; } = Guid.NewGuid().ToString();
    public string ImagePath { get; set; } = string.Empty;
    public string Location { get; set; } = string.Empty;
    public string Note { get; set; } = string.Empty;
}

Diese Klasse bildet die fachliche Grundlage der App. Die Galerie zeigt eine Sammlung von PhotoEntry-Objekten an. Die Detailansicht arbeitet mit einem ausgewählten Objekt. Der Bearbeitungsmodus verändert nicht direkt die Oberfläche, sondern die Werte dieses Modells beziehungsweise eine bearbeitbare Kopie davon.

Für eine Uno-App kann diese Struktur in ein ViewModel eingebettet werden. Uno nutzt XAML für die Beschreibung der Oberfläche und C# für Logik, Datenbindung und Zustand. Dadurch entsteht ein Entwicklungsmodell, das .NET-Entwicklern vertraut ist und gleichzeitig plattformübergreifend eingesetzt werden kann.

using System.Collections.ObjectModel;
using System.ComponentModel;
using System.Runtime.CompilerServices;
public class PhotoBookViewModel : INotifyPropertyChanged
{
    public ObservableCollection<PhotoEntry> Photos { get; } = new();
    private PhotoEntry? selectedPhoto;
    public PhotoEntry? SelectedPhoto
    {
        get => selectedPhoto;
        set
        {
            selectedPhoto = value;
            OnPropertyChanged();
            OnPropertyChanged(nameof(IsDetailVisible));
        }
    }
    private bool isEditing;
    public bool IsEditing
    {
        get => isEditing;
        set
        {
            isEditing = value;
            OnPropertyChanged();
        }
    }
    public bool IsDetailVisible => SelectedPhoto != null;
    public PhotoBookViewModel()
    {
        Photos.Add(new PhotoEntry
        {
            ImagePath = "Assets/paris.jpg",
            Location = "Paris, Frankreich",
            Note = "Ein sonniger Nachmittag am Eiffelturm."
        });
        Photos.Add(new PhotoEntry
        {
            ImagePath = "Assets/tokyo.jpg",
            Location = "Tokio, Japan",
            Note = "Leuchtende Straßen und viele Eindrücke."
        });
    }
    public void SelectPhoto(PhotoEntry photo)
    {
        SelectedPhoto = photo;
        IsEditing = false;
    }
    public void StartEditing()
    {
        IsEditing = true;
    }
    public void SaveChanges()
    {
        IsEditing = false;
    }
    public void CloseDetail()
    {
        SelectedPhoto = null;
        IsEditing = false;
    }
    public event PropertyChangedEventHandler? PropertyChanged;
    private void OnPropertyChanged([CallerMemberName] string? propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

Dieses ViewModel zeigt den Übergang vom Prototyp zur Anwendung. Das UI besteht nicht mehr nur aus sichtbaren Elementen, sondern reagiert auf den Zustand des ViewModels. Wird ein Foto ausgewählt, erscheint die Detailansicht. Wird der Bearbeitungsmodus aktiviert, verändert sich die Darstellung. Wird die Detailansicht geschlossen, kehrt die Anwendung zur Galerie zurück (Bild 1).

Galerie und Detailansicht in XAML

Die Oberfläche der Anwendung kann in Uno mit XAML beschrieben werden. Das passt gut zum Ausgangspunkt in Figma, da viele Designstrukturen ebenfalls aus Containern, Abständen, Karten und wiederverwendbaren Komponenten bestehen. Eine Galerie lässt sich beispielsweise mit einer GridView aufbauen. Jede Fotokarte wird über ein DataTemplate beschrieben.

<Page
    x:Class="PhotoBookApp.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:PhotoBookApp">
    <Page.DataContext>
        <local:PhotoBookViewModel />
    </Page.DataContext>
    <Grid Padding="24" RowSpacing="20">
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto" />
            <RowDefinition Height="*" />
        </Grid.RowDefinitions>
        <TextBlock
            Text="Mein Fotobuch"
            FontSize="28"
            FontWeight="SemiBold" />
        <GridView
            Grid.Row="1"
            ItemsSource="{Binding Photos}"
            IsItemClickEnabled="True"
            ItemClick="OnPhotoClicked">
            <GridView.ItemTemplate>
                <DataTemplate x:DataType="local:PhotoEntry">
                    <Border
                        Width="260"
                        Margin="8"
                        Padding="12"
                        CornerRadius="16"
                        Background="#FFFFFFFF">
                        <StackPanel Spacing="10">
                            <Image
                                Source="{x:Bind ImagePath}"
                                Height="220"
                                Stretch="UniformToFill" />
                            <TextBlock
                                Text="{x:Bind Location}"
                                FontWeight="SemiBold"
                                FontSize="16" />
                            <TextBlock
                                Text="{x:Bind Note}"
                                TextWrapping="Wrap"
                                MaxLines="2"
                                Opacity="0.75" />
                        </StackPanel>
                    </Border>
                </DataTemplate>
            </GridView.ItemTemplate>
        </GridView>
    </Grid>
</Page>

Diese XAML-Struktur bildet die Galerie des Prototyps nach. Die einzelnen Fotos erscheinen als Karten mit Bild, Ort und Notiz. Im Vergleich zu einer rein visuellen Darstellung ist jedoch entscheidend, dass die Inhalte über Datenbindung kommen. Das UI ist damit nicht statisch, sondern an die Sammlung Photos gebunden. Der Klick auf ein Foto kann im Code-behind an das ViewModel weitergegeben werden:

private void OnPhotoClicked(object sender, ItemClickEventArgs e)
{
    if (e.ClickedItem is PhotoEntry photo &&
        DataContext is PhotoBookViewModel viewModel)
    {
        viewModel.SelectPhoto(photo);
    }
}

In einem größeren Projekt würde man hierfür eher Commands verwenden, um Logik und UI noch klarer zu trennen. Für einen kompakten Praxisprototyp ist die gezeigte Variante jedoch gut nachvollziehbar. Wichtig ist: Der Klick auf ein UI-Element verändert nicht direkt beliebige Controls, sondern setzt den Anwendungszustand. Die Detailansicht kann zunächst als Bereich rechts neben oder oberhalb der Galerie ergänzt werden. Auf größeren Displays lässt sich eine zweispaltige Darstellung verwenden. Auf mobilen Geräten wird dieselbe Struktur später responsiv angepasst.

<Grid Padding="24" ColumnSpacing="24">
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="2*" />
        <ColumnDefinition Width="*" />
    </Grid.ColumnDefinitions>
    <!-- Galerie -->
    <GridView
        ItemsSource="{Binding Photos}"
        IsItemClickEnabled="True"
        ItemClick="OnPhotoClicked" />
    <!-- Detailansicht -->
    <Border
        Grid.Column="1"
        Padding="20"
        CornerRadius="20"
        Background="#FFF7F7F7"
        Visibility="{Binding IsDetailVisible}">
        <StackPanel Spacing="16">
            <Image
                Source="{Binding SelectedPhoto.ImagePath}"
                Height="260"
                Stretch="UniformToFill" />
            <TextBlock
                Text="{Binding SelectedPhoto.Location}"
                FontSize="20"
                FontWeight="SemiBold" />
            <TextBlock
                Text="{Binding SelectedPhoto.Note}"
                TextWrapping="Wrap" />
            <StackPanel Orientation="Horizontal" Spacing="8">
                <Button
                    Content="Bearbeiten"
                    Click="OnEditClicked" />
                <Button
                    Content="Schließen"
                    Click="OnCloseClicked" />
            </StackPanel>
        </StackPanel>
    </Border>
</Grid>

Dieses Beispiel zeigt aber die zentrale Idee: Die Detailansicht ist an SelectedPhoto gebunden. Wird ein Foto ausgewählt, ändern sich Bild, Ort und Notiz automatisch. Genau solche Zusammenhänge sind für Entwickler wichtiger als die reine optische Übereinstimmung mit dem Figma-Entwurf.

Zustände: Anzeigen, Bearbeiten, Speichern

Ein guter Prototyp zeigt nicht nur Screens, sondern Zustände. Im Fotobuch-Beispiel gibt es mindestens drei wichtige Zustände: Galerieansicht, Detailansicht und Bearbeitungsmodus. Für die Benutzerführung ist entscheidend, dass diese Zustände klar unterscheidbar sind. Der Nutzer muss erkennen, ob er Informationen nur betrachtet oder gerade verändert. In XAML lässt sich dies über gebundene Eigenschaften und unterschiedliche UI-Bereiche abbilden. Eine einfache Variante besteht darin, Textfelder nur im Bearbeitungsmodus anzuzeigen. Im Anzeigemodus werden stattdessen TextBlock-Elemente verwendet.

<StackPanel Spacing="12">
    <!-- Anzeigemodus -->
    <StackPanel Visibility="{Binding IsEditing, Converter={StaticResource InverseBoolToVisibilityConverter}}">
        <TextBlock
            Text="{Binding SelectedPhoto.Location}"
            FontSize="20"
            FontWeight="SemiBold" />
        <TextBlock
            Text="{Binding SelectedPhoto.Note}"
            TextWrapping="Wrap" />
    </StackPanel>
    <!-- Bearbeitungsmodus -->
    <StackPanel Spacing="8"
                Visibility="{Binding IsEditing, Converter={StaticResource BoolToVisibilityConverter}}">
        <TextBox
            Header="Ort"
            Text="{Binding SelectedPhoto.Location, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />
        <TextBox
            Header="Notiz"
            Text="{Binding SelectedPhoto.Note, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}"
            AcceptsReturn="True"
            MinHeight="120" />
    </StackPanel>
</StackPanel>

Dieses Beispiel verwendet Converter, um abhängig vom Bearbeitungszustand unterschiedliche Bereiche ein- oder auszublenden. In produktiven Anwendungen würde man prüfen, ob direkte Bearbeitung am ausgewählten Objekt sinnvoll ist. Häufig ist es besser, beim Start der Bearbeitung eine Kopie der Daten anzulegen. Dann kann der Nutzer Änderungen mit Abbrechen verwerfen, ohne dass das Originalobjekt bereits verändert wurde.

Komponenten und Wiederverwendung

Figma Make erzeugt oft eine funktionierende Oberfläche, aber nicht automatisch die ideale Komponentenstruktur. Für Entwickler ist daher die Frage entscheidend, wie sich wiederkehrende Teile des UI sauber kapseln lassen. Im Fotobuch-Beispiel bietet sich eine eigene Komponente für die Fotokarte an. Diese Karte enthält Bild, Ort und kurze Notiz. Sie wird in der Galerie mehrfach verwendet. In XAML kann daraus ein UserControl entstehen.

Feinschliff: Layout, Responsivität und Designnähe

Nach der technischen Grundstruktur folgt der Feinschliff. Dabei geht es nicht nur um Ästhetik, sondern um Nutzbarkeit und Konsistenz. Das Fotobuch lebt von großen Bildern, ruhigen Flächen und klaren Aktionen. Ort und Notiz sollen sichtbar sein, aber das Bild nicht verdrängen. Buttons sollen eindeutig beschriftet und logisch gruppiert werden. In XAML lassen sich Abstände, Farben und Typografie über Ressourcen zentral definieren:

<Page.Resources>
    <SolidColorBrush x:Key="CardBackgroundBrush" Color="White" />
    <SolidColorBrush x:Key="PageBackgroundBrush" Color="#FFF5F5F5" />
    <Style x:Key="HeadlineTextStyle" TargetType="TextBlock">
        <Setter Property="FontSize" Value="28" />
        <Setter Property="FontWeight" Value="SemiBold" />
    </Style>
    <Style x:Key="CardTitleTextStyle" TargetType="TextBlock">
        <Setter Property="FontSize" Value="16" />
        <Setter Property="FontWeight" Value="SemiBold" />
    </Style>
</Page.Resources>

Diese Ressourcen entsprechen der Idee von Design Tokens. Werte aus Figma, etwa Farben, Schriftgrößen oder Abstände, werden nicht an beliebigen Stellen im Code wiederholt, sondern zentral definiert. Dadurch bleibt die Oberfläche konsistent und lässt sich später einfacher anpassen. Auch Responsivität sollte früh bedacht werden. Eine Fotobuch-App kann auf Smartphone, Tablet und Desktop genutzt werden. Uno ermöglicht plattformübergreifende Oberflächen, dennoch muss das Layout auf unterschiedliche Bildschirmgrößen reagieren. Eine einfache Strategie besteht darin, auf großen Displays Galerie und Detailansicht nebeneinander darzustellen. Auf kleinen Displays wird die Detailansicht als eigene Ansicht oder als überlagerter Bereich angezeigt. Konzeptionell lässt sich das so beschreiben:

<VisualStateManager.VisualStateGroups>
    <VisualStateGroup>
        <VisualState x:Name="Narrow">
            <VisualState.StateTriggers>
                <AdaptiveTrigger MinWindowWidth="0" />
            </VisualState.StateTriggers>
            <!-- Mobile Darstellung: Detail unter oder über der Galerie -->
        </VisualState>
        <VisualState x:Name="Wide">
            <VisualState.StateTriggers>
                <AdaptiveTrigger MinWindowWidth="900" />
            </VisualState.StateTriggers>
            <!-- Desktop/Tablet: Galerie links, Detail rechts -->
        </VisualState>
    </VisualStateGroup>
</VisualStateManager.VisualStateGroups>

Der genaue Aufbau hängt vom Projekt ab. Entscheidend ist, dass Responsivität nicht erst am Ende betrachtet wird. Bereits der Figma-Prototyp sollte Hinweise darauf geben, wie sich die Anwendung auf verschiedenen Bildschirmgrößen verhält. Die technische Umsetzung greift diese Entscheidungen auf und übersetzt sie in Layoutregeln.

Uno, MAUI und andere Microsoft-UI-Systeme

Uno ist nicht das einzige UI-System im Microsoft-Umfeld. Es wurde genutzt, da der direkte Export aus Figma über ein Plug-in unterstützt wird. Viele konzeptionelle Entscheidungen aus dem Fotobuch-Beispiel lassen sich daher auf MAUI übertragen. Auch WPF oder WinUI folgen ähnlichen Mustern.

Grenzen des generierten Codes

Figma Make und Export-Plug-ins können den Übergang vom Design zur Implementierung stark beschleunigen. Dennoch sollte generierter Code nicht mit Produktionscode gleichgesetzt werden. Ein Export nach XAML kann eine hilfreiche Grundlage liefern, vor allem für Layout, Abstände, visuelle Struktur und erste Controls. Die eigentliche Anwendungslogik entsteht jedoch erst durch die Arbeit der Entwickler. Typische Grenzen zeigen sich bei Datenbindung, Navigation, State-Management, Persistenz und Fehlerbehandlung. Ein generierter Screen kann gut aussehen, aber noch keine saubere Trennung zwischen View und Logik besitzen. Ebenso kann ein Layout aus vielen verschachtelten Containern bestehen, obwohl eine einfachere Struktur im Zielsystem besser wäre. Entwickler sollten exportierten Code daher als Vorschlag betrachten, nicht als fertiges Ergebnis.

Fazit

Der zweite Teil des Praxisprojekts zeigt, dass der eigentliche Wert eines KI-generierten Prototyps nicht nur im schnellen visuellen Ergebnis liegt. Entscheidend ist, was daraus abgeleitet werden kann: Datenmodelle, Zustände, Komponenten, Speicherlogik und eine tragfähige UI-Struktur.

Figma Make, Figma Dev Mode und XAML-Export können den Weg vom Entwurf zur Anwendung deutlich verkürzen. Sie ersetzen aber nicht die technische Bewertung. Entwickler müssen generierten Code prüfen, Komponenten sinnvoll schneiden, Zustände sauber modellieren und die Zielplattform berücksichtigen. Damit wird aus einem schnellen Prototyp eine belastbare Grundlage für die weitere Entwicklung.