Nutrava

Nutrition tracking and nutritionist booking app: requirements, documentation and design

Nutrava helps people log meals, follow daily nutrition targets, and book sessions with a nutritionist, all in one app.

Product name and branding changed to protect client confidentiality. Our role: discovery, requirements, documentation and design. We did not build it.

Screens designed: 199
Platform: iOS, Android and iPad
Market: Content needed: country or region
User roles: 2

Overview

Nutrava turns daily eating into clear numbers. Users log food and recipes, see carbs, protein, fat, and calories against their targets, and set goals through a guided questionnaire.

When they want expert help, they book an available slot with a nutritionist, pay in the app, and chat directly. Nutritionists manage their availability, bookings, and earnings from their side of the product.

What made it complex

Two user roles: people tracking nutrition, and nutritionists running their practice
Booking, payment, cancellation and rejection flows on both sides
Daily targets and meal analysis that update as users log food
Monthly packages alongside single consultations

Key decisions we made

Two or three decisions and whyFor example, a rule you simplified, a feature you cut from version one, or a trade-off the client accepted.

What the product does

Every feature below was specified in the requirements and shown in the designs.

Food logging. Search foods, add meals, and save recipes.
Meal analysis. A breakdown of what is in each logged meal.
Daily targets. Carbs, protein, fat, and calories against goals.
Progress tracking. Daily and meal-by-meal progress.
Guided goals. A step-by-step goal questionnaire.
Nutritionist booking. Available slots, payment, and booking details.
Cancellations and rejections. Structured reasons on both sides of a booking.
Messaging. Chat between users and nutritionists.
Nutritionist availability. Weekly slots that nutritionists set themselves.
Earnings. Earnings tracking for nutritionists.
Subscriptions. Monthly packages with unlimited consultations.
Blog. Articles on nutrition and healthy habits.

How we worked

Discovery sessions, then business, functional and technical requirements and a data model, then design and handover. Every screen traces back to a documented requirement.

The same process, as a service

What the client received

Plain names first; the short labels are what developers call each document.

BRD

Business Requirements Document

Business goals, users, scope, and success measures.

FSD

Functional Specification Document

Every feature, flow, business rule, and screen behavior.

TRD

Technical Requirements Document

Architecture, integrations, security, and performance requirements.

ERD

Entity Relationship Diagram

The data model behind the product and how its records connect.

Design

UX and UI design

199 screens, ready for development handover.

Pitch deck, if deliveredAdd as a deliverable where you prepared one for this client.

A look inside the product

8 of the 199 screens we designed. Scroll or swipe to see more.

Outcome

What happened nextOne true sentence, for example: the client selected a development partner, raised investment, or started the build. Remove this block if it cannot be shared.

199Screens designed

2User roles

Content needed: a real quote from this client, two or three sentences, in their own words

Content needed: role, company type and country (name optional)

Have a product like this in mind?

We start with discovery: requirements, documentation and design that any development team can quote and build from.

Book an intro call

Free and without obligation. Content needed: call length

Before the callWe read what you sent, so the call starts with your problem.
On the callWe ask questions, listen, and explain how we would approach it.
After the callIf we are a fit, a written proposal with a fixed scope follows. If not, we say so.