WEB DESIGN & DIGITAL PRODUCTS

Architecture begins with the questions each audience needs answered and the actions the organization must support. We organise content, navigation, and hierarchy before adding visual complexity, giving every screen a clear purpose.

Flows and prototypes test journeys, states, and decisions before every screen is produced. The interface then translates the identity into a responsive, accessible system designed to work with real content.

Components, variants, and behaviours are documented so design and engineering share the same contracts. During implementation we can review fidelity, accessibility, and performance so the final experience preserves validated decisions.

We do not assume that a fully custom website is always the right answer. We compare content, functionality, publishing frequency, and team capabilities with the constraints of a template or an existing content system. Custom work is used when it creates a meaningful difference in architecture, brand expression, accessibility, or operations; a proven foundation is retained when it serves time and budget better.

For multilingual websites, we define from the outset which content exists in Catalan, Spanish, and English, how navigation changes, and which URLs should be indexed. Canonicals, hreflang, redirects, and hierarchy are treated as one architecture, particularly during redesigns or migrations where valuable URLs and SEO signals need to be preserved.

Website budgets depend on architecture, the amount and readiness of content, the level of customization, languages, integrations, and who owns development. A landing page, corporate site, and digital product are not equivalent packages. We first define objectives, functionality, responsibilities, and launch criteria, then propose comparable phases and deliverables.

1. 01 / Objectives and architecture
2. 02 / Flows and prototype
3. 03 / Interface direction
4. 04 / Component system and handoff

We begin with objectives, audiences, content, and the actions the product must support. That foundation informs information architecture, user flows, and prototypes before visual direction or the component system is finalised.

The scope is defined in each proposal. We can deliver UX/UI, prototypes, specifications, and implementation direction, or collaborate with the responsible engineering team. Responsibilities and deliverables are agreed before work begins.

We work with components, states, responsive rules, and reusable patterns. Accessibility, content hierarchy, and performance criteria are considered so new screens can extend the system instead of rebuilding it.

There is no single price because a landing page, a multilingual corporate site, and a product with integrations have different scopes. The budget is calculated after defining architecture, content, functionality, development, and responsibilities. The proposal separates phases and deliverables so it is clear what is included, what is excluded, and what can be postponed. This makes the scope measurable before visual production begins and prevents ambiguous comparisons between proposals.

We decide from the problem rather than a technology preference. A template can be appropriate when the structure is conventional and fits the content. A custom solution makes sense when brand expression, user flows, integrations, or maintenance require greater control. We explain constraints, future costs, and dependencies before selecting the foundation.

We can work with copy and images supplied by the client, help structure them, or coordinate a dedicated content phase. Before design begins, we agree who writes, translates, reviews, and uploads each asset. This avoids approving screens with placeholder content and discovering too late that the real hierarchy, languages, or volume require a different structure.

Yes. We plan multilingual architecture, navigation equivalents, and metadata for each language from the outset. Canonicals and hreflang are defined so search engines understand the correct versions. Translation and review can be included or handled by the client's team, but ownership is agreed before production begins.

We first inventory URLs, content, metadata, and links that already carry value. Redirect mappings are prepared before the change, useful pages are retained, and the sitemap, canonicals, hreflang, and crawlability are checked at launch. A specific ranking cannot be guaranteed, but losses caused by moving or deleting content without a plan can be avoided.

The proposal identifies what is delivered, which third-party licences or services are used, and who administers the domain, hosting, analytics, and repositories. We recommend keeping essential assets in accounts controlled by the client. When development is included, access to source code, documentation, and maintenance terms are specified before work starts.