PeakLab designs and improves SaaS products, business applications and digital services from real usage. User research, UX journeys, prototypes, interfaces and design systems support a measurable decision, not an aesthetic preference.
The engagement names the decision, journey, users, available signals and what remains outside the scope.
Recruitment, discussion guide, consent, observations and sample limits are documented without presenting an opinion as fact.
Risky assumptions go through a prototype and representative scenarios before full implementation is committed.
States, responsive behavior, errors, content, components and acceptance criteria are reviewed with the team building the product.
Product Design is useful when an interface decision commits development, adoption or operations: launching a product, rebuilding a blocked journey, simplifying a business tool or aligning several teams around one system. Analytics often show where a user drops; interviews, observation and tests help explain why.
We start with the decision to make, the relevant users and the expected observable behavior. A prototype then tests comprehension, language, sequence and errors before every screen is funded. DesignGouv's user testing method recommends defining the objective, recruiting representative profiles, facilitating with as little bias as possible and turning observations into prioritized decisions.
A purely visual refresh, brand identity or isolated landing page may call for another specialist. We recommend Product Design when the uncertainty concerns usage, the journey or consistency between product and development.
“PeakLab combines Product Design, Product Management and web development in one expertise hub. Designers therefore work with the data, permission, responsive, accessibility and component constraints that shape the real product. If you only need a brand identity or campaign, we say so; if the proposition itself still needs validation, our MVP and POC agency can frame the right format before the interface is detailed.”
Six deliverables that turn an assumption into an understandable, testable and development-ready journey.
We connect business goals, roles, critical tasks, constraints and available data. The deliverable defines the problem, hypotheses, segments and indicators: task success, errors, time, activation, abandonment or support requests. A metric is retained only when its definition and collection are verifiable.
Interviews, observation, request analysis and existing data are selected to answer the question. We prepare recruitment, the guide and consent, then distinguish quotes, observations and interpretation. Roles, contexts, visible steps and backstage operations feed journeys or a service blueprint; a persona is created only when grounded in real data.
We structure navigation, business objects, content, permissions and sequences around priority tasks. Flows also cover empty, loading, error, rejection, return and interruption states. Every screen must answer an intent and prepare an action; secondary scope remains visible in the backlog instead of being designed by default.
Fidelity follows the risk being tested: paper or wireframes for structure, an interactive prototype for journeys and behavior. Participants complete scenarios without being led to the answer. We record success, hesitation, errors and comments, then classify each finding: fix, retest, retain or discard.
Hierarchy, typography, contrast, focus, keyboard use, target sizes, labels and error messages are designed with the journey. W3C encourages using WCAG 2.2, but a prototype or plugin does not prove that the delivered product conforms. Legal scope and audit level are qualified separately with the appropriate specialists.
We document components, variants, states, content rules and their code mapping. The Design Tokens Format 2025.10 has provided a stable cross-tool exchange format since October 28, 2025, without being a W3C Recommendation. We industrialize only what the team will use, then monitor adoption, errors and requests after release.
You delivered a product above what I expected. It's a finished product, not a small mockup. The exchanges with you brought so much to the project.
Modern and proven stack for high-performance apps
Define the problem, roles, critical task, constraints, baseline and what the engagement must enable the team to decide
Recruit useful profiles, run research, cross-check behavior, quotes, support and data, then state the limits explicitly
Decide information architecture, flows, content, accessibility and prototype fidelity according to the risks
Observe tasks without leading participants, analyze difficulties, prioritize changes and retest critical assumptions
Document components and behavior, support acceptance testing and compare post-release signals with the baseline
Define the problem, roles, critical task, constraints, baseline and what the engagement must enable the team to decide
Recruit useful profiles, run research, cross-check behavior, quotes, support and data, then state the limits explicitly
Decide information architecture, flows, content, accessibility and prototype fidelity according to the risks
Observe tasks without leading participants, analyze difficulties, prioritize changes and retest critical assumptions
Document components and behavior, support acceptance testing and compare post-release signals with the baseline
For Armodoc, the starting point was concrete: field technicians could not retrieve the documents they needed on site. Conversations with the founder helped prioritize QR code and NFC access, then broaden the vision with a citizen communication module for local authorities.
We retain the published approach here—immersion in context, a priority use case and field validation—and the founder's testimonial: “You delivered a product above what I expected. It's a finished product, not a small mockup.” The case study's timeline, commercial outcomes and metrics are not used as a promise for another engagement.
The same principle applies to sensitive choices. CNIL's digital innovation lab published twenty dark-pattern scenarios on January 9, 2026 to identify interfaces that steer or obstruct choices involving personal data. We include consent, refusal, deletion and exit in the journeys to test, without presenting a mockup as compliant by itself.
Let's describe the users, critical task, observed friction and decision to make. You will know which research or prototype is useful before starting a redesign.
Research, UX audits, prototypes, measurement, accessibility and developer handoff.
UX studies the experienced service: needs, context, journeys, comprehension and usability. UI covers the form and behavior of the interface: hierarchy, components, content and states. Product Design connects these disciplines to a product decision, business and technical constraints, then post-release measurement. An engagement may use all or only part of them.
It should begin with existing knowledge and the decision to make. Interviews, observation, support tickets, analytics or previous tests may already provide evidence. We run new research when uncertainty is material or the data no longer represents current usage. It is not added as a ritual: method, profiles and depth follow the risk.
There is no universal number. It depends on segments, task variety, decision risk and repetition in the observations. The proposal states target profiles, recruitment and the stopping rule. A small homogeneous usability test may identify journey problems; it does not automatically measure how frequent they are across the whole customer base.
An audit links each observation to a screen, scenario, source and potential impact. It separates the observed problem, hypothesis and recommendation, then ranks actions by value, risk and effort. The deliverable includes the available baseline, analysis limits and a validation plan; a context-free checklist of heuristics is not enough.
No. Depending on scope, we deliver the research question, synthesis, journeys, content, prototype, components, states, responsive rules and acceptance criteria. PeakLab can also implement the design through its web development agency. Files, rights, documentation and support level are stated in the proposal.
They depend on roles, journeys, recruitment, business constraints, fidelity, the existing design system and validation availability. We separate framing, research, design, testing, UI, system work and development support. A focused audit, a new product and a multi-role business tool redesign do not share one price or schedule.
Measurement is defined before the solution: task success and duration, errors, activation, abandonment, feature usage, support requests or a relevant business outcome. After release, we compare with the baseline while documenting period, population and simultaneous changes. A better signal is not automatically attributable to design if price, traffic, offer or process also changed.
When a team repeats components, maintains several products or loses time between design and code. We first audit what exists, actual usage and governance. A useful design system documents components, states, accessibility, tokens, contribution and versioning; an exhaustive library that nobody adopts only adds maintenance.
It can integrate contrast, keyboard use, focus, structure, labels, errors and assistive-technology testing from the start. But compliance applies to the implemented product, its content and operations. French consumer authorities noted on November 13, 2025 that certain services have been subject to accessibility requirements since June 28, 2025, with scopes and exemptions to assess. PeakLab does not provide legal advice or automatic certification.
We test consent, subscription, cancellation, deletion and refusal as carefully as activation. Options must not hide consequences, make exit artificially difficult or steer a default choice without justification. Legal constraints are validated by the appropriate advisers; design's role is to make choices understandable, comparable and reversible.
Copyright © PeakLab 2026. All rights reserved.
