Flutter App: PotatoVerse — Wireframes

Picking up from where we left off with our PotatoVerse application, this article will be diving into the next phase of development — Wireframes. This will be our part 6, so if you missed part 5 (or need a quick refresher), read that article on sitemaps here.

Image Source

A wireframe is a low-fidelity representation of a product’s user interface. It is a rough schematic which is created in the early stages of a digital product design to help visualise and communicate the structure of a product, mobile application or website.

Wireframes help teams align on requirements, keeping UX design conversations focused and constructive. Think of your wireframe as the skeleton of your final product.

Low fidelity vs high fidelity wireframes
In UX design, fidelity refers to how much a design closely matches the look, feel, and functionality of a final product. The structure of the design and the content included determine the wireframe’s level of fidelity.

A low fidelity wireframe will present a basic illustration of a product’s intended layout and user journeys while a higher fidelity wireframe will look as close to the finished product as possible.

Both types of wireframes are essential in the design process, but they serve different purposes and are used at different stages of development. Here’s a quick comparison of both.

Low fidelity

• Purpose: Lo-fi wireframes are quick and easy to create making them perfect for early stage design ideation and concept sharing. They communicate the basic structure and layout of the design. Therefore, if time is a concern, they’re perfect for coming up with the most viable solution which can then be iterated.
• Time taken: They are faster to create because they are less detailed.
• Learning curve: They have an extremely low barrier to entry when it comes, meaning almost anyone can do it.
• Focus: Low fidelity wireframes mainly focus on functionality and user flow rather than visual design.
• Key characteristics: Lo-fi wireframes are simple, sketch-like and often black and white. There are placeholders to represent content (e.g., boxes for images, lines for text, simple icons etc). They are generally static but can sometimes be clickable to show basic navigation.
• Tools: These wireframes can be done using paper and pencil, whiteboards, or simple, easy-to-use digital tools like Balsamiq.

High fidelity

• Purpose: High fidelity wireframes are used to provide a detailed and realistic representation of the final product. They include all the content, stylistic elements and branding that the finished product will include to convey what the product will really look like.
  Since they represent something close to the finished product, it makes them great for early-stage testing, conducting usability test and guiding developers in the implementation phase.
• Time taken: Due to the level of detail, they take more time to create as compared to the low fidelity wireframes.
• Learning curve: Advanced tools are used for higher fidelity wireframes which adds a layer of complexity for a beginner to grasp.
• Focus: They focus on design elements like color, typography, and interactions. With added user journeys and clickable areas, these wireframes become a functional prototype.
• Key characteristics: Hi-fi wireframes appear very polished and professional, resembling the final product. They include actual content, themes/colours, images, text and detailed UI components. They are also often clickable, simulating real interactions and navigation.
• Tools: These wireframes are created using advanced design tools e.g., Figma, Sketch, or Adobe XD.

Part 6— Wireframes

With our sitemap in place, let’s go ahead and create our low fidelity wireframes for the app.

Step 1
Identify the key screens you need to create e.g., home page, search page etc. Luckily, with the sitemap we created, we already have the screens for our application laid out and the key elements.

Step 2
Conceptualise the page layout and and overall structure for each screen. Again, we already have this high level outlook on what each screen will contain but let’s fine tune the essential elements and widgets for each screen such as navigation bars, buttons, text, images etc.

Home page

1. Header section
   App bar — Notification bell icon (fixed on top right)
   Salutation or tag line — To introduce the user to the app.
2. Featured recipes/ “Just For You”
   A mid section with a card/banner containing 2–3 high quality recipe images as a carousel. This could auto-scroll or the users could swipe manually.
3. Categories section
   Quick access buttons directly under the featured section as a horizontal scrollable row (if there are more categories than the width allows).
   Displayed as circular or rounded rectangular buttons/icons to represent the main categories such as “Method,” “Meal,” “Diet,” etc.
4. Popular/trending recipes
   Horizontal scrollable recipe cards below the categories section.
   Each card will show a recipe image, the recipe name, and a brief tag.
   Users can swipe left or right to view multiple recipes.
5. Latest potato news
   The most recent story on potatoes. A quick excerpt with a prompt to read more when clicked. PS — This is a could-have feature. So we might not have it in our first launch.
6. Footer
   A fixed/persistent navigation bar at the bottom of the screen. With a minimalist design containing 4–5 icons for the key sections as follows.

• Home (icon: house)
• Search (icon: magnifying glass)
• Profile (icon: user)
• Shopping list (icon: shopping cart/basket or list)

Search page

1. Header section
   Search bar — Fixed at the top. Simple and rounded that spans most of the width of the screen. With placeholder text to prompt the user search. To include a search and filter icon.
   Could-have: As the user types, display a dynamic suggestion dropdown list with matching recipe names or categories.
2. Main body
   A vertical scrollable list of recipes as cards. Load more results as the user scrolls down (infinite scroll) or use a “load more” button. Initial list to contain all the recipes. List to reduce when a search name or filter matches a recipe in the DB.
   Example Card Layout: High-res recipe image (thumbnail), recipe title e.g., “Crispy Baked Potato Wedges”, tag e.g., “Vegetarian, rating as stars or number of reviews (could-have).
3. Footer
   Persistent bottom nav bar, allowing users to jump to other sections of the app. (As noted above)

Profile page

The profile page for this app will serve as a centralised hub for users to manage their personal information which includes preferences, saved recipes, app settings, gamification etc. At the moment we aren’t having an auth service so there’s no password management etc. We can however have some avatars and user names for the user to personalise their app.

1. User information section
   This will be positioned at the top of the page containing: the avatar selected, the user name displayed in bold, a quirky subtitle or tagline e.g., “Potato Enthusiast” or “Chief of Chips”
   A small “Edit” or pencil icon for users to update their profile information (user name, tag, avatar, etc.)
2. Favourites/Saved recipes
   A scrollable or grid layout showcasing a few of the recipes the user has bookmarked positioned directly after the user info section. Each saved recipe is displayed as a card with an image and title. Call to action button/link to view all the saved recipes — on click it will direct the user to a dedicated page for their full collection of saved recipes.
3. My recipes
   Because we are supporting user generated content, this section will be right after the saved recipes section. Containing a grid or list of a few of the recipes the user has submitted to the app (recipe image, title etc.) Call to action to view all the submitted recipes in a dedicated page. A status will be included for each recipe (e.g., Approved, Pending, or Featured). Have an action buttons to allow the user to edit a particular recipe (And a prominent button or FAB (floating action button) in the main ‘my recipes’ page for the user to add a new recipe. This FAB will redirect to a recipe submission page/dialog box.
4. Preferences
   This is a section for the user to personalise the app. They can update their diet preferences like Vegetarian, Vegan, Gluten-Free, Keto — This will infer what featured for the user. Toggle notifications (could-have) for new recipes added, recipe submission status update, potato news etc. Another could-have, set preferred units of measurements (Metric or Imperial)
5. Achievements/Gamification
   This is a could-have feature to be positioned near the bottom of the page containing badges or awards for milestones reached like recipes saved, recipes submitted. Each badge could be a fun potato icon. To also include personalised stats for the user e.g., Number of saved recipes, number of submitted recipes, if their submitted recipe has been approved and added to the DB, if their recipe has been featured or saved by another user etc.
6. Settings
   Section to manage the app settings e.g., appearance or theme — dark/light mode, and language (could-have).
7. About the app
   Information about the app e.g., the version, developer, and attributions.
8. Contact & support
   Located at the bottom of the page. Button to send an email or reach customer support and a feedback form or button to submit feedback or suggestions about the app.
9. Footer
   Persistent bottom nav bar, allowing users to jump to other sections of the app.

Shopping list page

The fourth page as directed by the bottom navigation bar is a shopping list page. It is a simple page to help the user organise and manage the ingredients they need to cook their preferred potato dishes.

1. Header
   Prominent app bar action button to clear all items from the list (e.g., a trash can icon).
2. Shopping list items
   This is the main section of the page that contains a list of all ingredients added to then list. Displayed as a row with the following details: ingredient name, quantity/units (e.g., “2 kg” or “3 cups”), a checkbox to mark an item as “purchased/acquired.” When checked, the item gets greyed out and/or have a strike through.
   Each item should also have an edit icon (pencil) to update details or a delete icon (trash can) to remove it.
3. Add new item
   A collapsible section at the bottom of the page to add items to the shopping list. The section will expand to an input area with: a text input field to enter the ingredient name, a quantity field to capture the quantity needed as grams, cups or pieces etc and an add button to save the item to the shopping list.
4. Share list
   A could-have feature positioned at the bottom as a FAB to share the shopping list with friends, family, or others via: Messaging apps e.g., WhatsApp, email or a copy to clipboard. The shared list should include all items, categories, and quantities in a clean, readable format.
5. Footer
   Persistent bottom nav bar, allowing users to jump to other sections of the app.
6. Empty State
   This is the main view when the shopping list is empty containing an animation and a message like “Your shopping list is empty. Start adding ingredients!”. The bottom “add new item” is still visible.

Recipe-to-List integration (could-have) functionality at the end of a recipe that will allow the user to auto-populate the shopping list with its ingredients. Users can still manually modify/remove auto-added ingredients in the list

These are the four main screens for our application. There are quite a number of pages to consider but we won’t be getting into them at this juncture.

Step 3
Using your preferred tool, set up your canvas and start adding the UI components. Remember to keep it simple. The purpose of this is to provide a rough idea of the app’s structure and not to create a visually pleasing design. So it is better to stick to simple shapes to represent content, buttons, and other elements to represent the layout and navigation.

Using Balsamiq, I was able to come up with the below screens as detailed above. Again, wireframes are meant to be a rough sketch so don’t stress too much with trying to fit all the details and perfecting the UI.

Wireframes shouldn’t cause distraction or confusion. Similar components should look the same across all wireframes, so they’re easy to grasp, iterate on, and code. Aim to maintain consistency.

The user flows should be fluid and intuitive. If users have to consult a sitemap, then your navigation and information architecture could use some improvements.

If you have followed closely, you might have noticed some differences between the wireframes created here and the sitemap we created earlier. This is because as we move along the process, we should be having discussions with stakeholders and users. These conversations, more often than not, lead to refinements of the requirements and perhaps changes to the designs or app structure. It’s expected. So between me of now and me of last month, there are some tweaks here and there. (But I haven’t updated my sitemap as would be the case in a real world scenario). Also, the wireframes could still differ from the high fidelity prototypes but between the prototypes and the final products, there shouldn’t be stark differences.

Step 4
Test and refine. Once you have created your wireframe, test it with your potential users and stakeholders. Gather the feedback and use that feedback to refine your wireframe and make necessary changes.

Creating a wireframe is an important step in the design process of your mobile application or any other digital product. They will help to ensure that everyone is on the same page and speaking the same language before the actual implementation or development.

In our next article in the series, we’ll be converting our wireframes to a prototype (High fidelity wireframes). We have already introduced the concept of prototypes in this article, so that concept won’t foreign.

“What a superbly featured room and what excellent boiled potatoes! Many years since I’ve had such an exemplary vegetable. To which of my fair cousins should I compliment the excellence of the cooking?”
— Pride and Prejudice, Jane Austen

Wishing you an amazing 2025. Thank you for reading ❤

Check out the previous articles on this project.

PotatoVerse - Ideation

Flutter App: PotatoVerse - Personas

Flutter App: PotatoVerse - Scenarios

Flutter App: PotatoVerse — Requirements Prioritisation

Flutter App: PotatoVerse — Sitemap

References
1. https://balsamiq.com/learn/articles/what-are-wireframes
2. https://www.figma.com/resource-library/what-is-wireframing/
3. https://uizard.io/blog/low-fidelity-vs-high-fidelity-wireframes