Navigation path


Table of content

1. Plan

The purpose of this phase is to prepare for an upcoming project, including the establishment of the definition and initial planning for new project. The project definition includes definition of the scope and outlines of the requirements for a project; these may include the timetable, as well as the limits with regard to budget and resources. This phase may be preceded by the “Go-ahead decision" phase, where applicable.


This section describes the activities involved in gathering all the relevant detailed inputs and information needed during the conception, structure and development phases of the website, as well as inputs for making the key decisions during those phases.
The main steps/activities during this phase include:

  • defining what type of website
  • documenting the purpose/objectives of the site
  • the mission and target audience (including their expectations, etc.)
  • preliminary definition of resources for project execution
  • identification of constraints such as special standards
  • establishing work plan and calendar
  • defining and describing in detail the subject of the website, etc.


  • Appoint the site coordinator (DG concerned).
  • Recruit the personnel.
  • Fix responsibilities for all tasks involved.
  • Inform DG COMM of new site creation project.
  • Establish calendar and work plan.
  • Define and describe in detail the subject of the website.
  • For dynamic applications introduce the detailed hosting request (THM form: Transfer-Hosting-Modification) via MIRELLA) Restricted area: This link points to internal pages and may not work if you are browsing as an external user. – IRM responsible + corresponding DIGIT-DC Account manager (DIGIT ISHS account management).
  • Appoint DIGIT-DC Technical Project Leader (coordinates the implementation of every request change).
  • Prepare a capacity plan (DIGIT-DC).
  • Analyse the request and its impact on DC infrastructure >>> CAB approval for starting change implementation.
  • Set-up site environment for static site (site URL allocation, access to the Staging Manager, CIRCA environment if needed, etc.) & dynamic sites (site URL allocation, access to the development and test environments, etc.)
  • Submit requests (security convention) for relevant accesses (possible also for contractors).
  • Define the core e-services to be integrated within the site (Core e-services catalogue: Mailform, Mailmas, generic mailbox for contact, Forum, etc.)
  • Plan and contact the DGT (upstream linguistic advice and editing needs, translation volume, deadlines, budget, etc.)
  • Define promotion and communication strategy (define who will be informed about the new site, when and how).
    N.B. Site forms part of a larger communication strategy
  • Define the tracking and evaluation elements (send the request to set-up and generate the statistics report).
  • Launch the copyrights procedures.
  • Launch the data protection procedures.

Quality Assurance/ Evaluation criteria


Administrative actions:

  • Decision to create the site
  • Resources/ Budget allocated/ Contracts organised/launched
  • Document management procedures defined
  • Project definition
  • Creative brief (Project definition, including: stakeholders, project sponsor, overall conceptual and visual aims of the site, information on target group(s), how users will experience the site, communication strategy, risks)
  • Architectural requirements: application schema (application architectural requirements, the software components, data access path), the evolution of disk usage and workload, criticality of the application (availability, fail over, contingency), potential security issues (external accesses.
  • Basic concept plan
  • Preliminary risk list


  • Project Description and planning instruments (calendar and detailed work breakdown plan, resources allocation, including costs list (figures), etc.)
  • Site specification
  • Capacity plan (DIGIT-DC)
  • Site production checklist
  • Promotion and communication plan
  • CAB approval for starting change implementation (based on received request for change)


  • Framework contract available (OP)
  • DIGIT (Mirella)
  • DGT-D.2
  • Data Protection Officer
  • Legal service (copyrights)
  • CIRCA support
  • DG’s IRM
  • DIGIT-DC Technical project leader

1.1. Creating a new site

Since the beginning of 2013, the European Commission has embarked on a comprehensive web rationalisation project. It aims to make the institution’s online communication more coherent, relevant and cost-effective. This transformation project encompasses two overlapping phases: the first phase focuses on radical website reduction, the second phase aims to restructure the Commission’s online presence according to user needs.

With this in mind, new websites, by default, must not be created (see note Ares(2013)372665pdf). By way of exception, the creation of a new website can be authorised under certain circumstances (i.e. creation of a website whose life span is strictly limited in time or development of a site that gathers in one single website the content of several other websites whereby the latter can be closed).

The creation of a new website must be part of the communication plan of the information unit of a DG as well as of the global communication plan of the Commission. The goals of the website must be well defined in close consultation with DG Communication’s EUROPA team and all Internet editors concerned by the subject of the site. The construction of the website must be well planned and respect the IPG rules and procedures. Several services of the Commission (DG Communication, DG Informatics, DG Translation, Publications Office) are at your disposal for making your website a success.

A website is just one of the tools that are available to information and communication units to achieve the goals set forward in their communication plan. Its final purpose is to serve its target users well, so that they can perform the tasks for which they visit the site in the most efficient way.

A number of basic questions need to be answered before actually starting the development of a site:

  • Why is the site needed?
  • Who is the site for?
  • What are the main tasks?
  • What will the site contain?
  • How and when will the site be constructed and launched?

To assess that your website will be focused on its users, you can apply this checklist for building successful websitespdf(145 kB) Choose translations of the previous link .

To ensure that your site fits into the Commission’s web presence on EUROPA, that development goes smoothly and that last-minute surprises are avoided, it is essential to consult upfront all relevant stakeholders in the Commission, in particular the EUROPA team in DG Communication and the Internet editors of the DGs that could be interested in the subject of the site. The word “upfront” means that the EUROPA team in DG Communication must be contacted – and a site creation request submitted – before the requesting service commits any budget, enters into any contract and before any development work starts.

Before sending the site creation request to the EUROPA team the endorsement of the Head of the Communication Unit of the requesting DG must be obtained. 

Under certain circumstances, it may be necessary to set up an ad hoc editorial board to accompany the set up of the site. In any case, the EUROPA team must be informed at the very start of the project following the site creation procedures.

If you need an external contractor to develop your site, the Publication Office can offer a large set of services to facilitate electronic publication.

The Informatics DG can give you all the information on the available software tools that you can use for constructing your site.

The standard template must be used for all EUROPA websites.

Last but not least, DG Translation will help you, not only only to translate your web pages, but also to check their editorial quality. DG Translation also advises on the most suitable language policy for your site considering the type of content published as well as the target audience(s).

The following chapters will go into more detail on the:


1.1.1. Guidelines for defining and measuring websites

This page presents definitions, methods and concepts for the tracking, measuring and evaluating of the Europa online web presence to guide services using the platform. They cover both websites and other web assets.

How to define a website?

To help webmasters decide whether a set of web pages shall be considered as one single website or not, all of the following criteria should be applicable.

To be considered a website, a set of web pages must:

  • Thematic criterion: be thematically related (reflected in the same visual site name).
  • Navigation criterion: have a common integrated navigation system.
  • Visual criterion: have the same look and feel.

If the 3 above criteria apply simultaneously, the considered set of web pages is a single coherent website and should be reported as such. Under this new clarification, the notion of sub-site is no longer relevant.

  • A site name is the common most prominent title available on each page of the set of web pages.
  • A common integrated navigation system is the main navigation available on each page of the set of web pages.

Guideline 1: If a set of web pages matches all of the criteria above, it shall be reported as a website.

What is a web asset?

Content encoded in a machine-readable format and made available over the Internet. Such as HTML files, images, css files, javascript files, etc.

What is a web page?

A webpage is defined as content encoded in a hypertext formatted document (e.g. HTML). A web page regroups web assets needed to convey an editorial message and the means to display it correctly. A web page is either static or dynamic:

  • A static web page is one where the HTML code is stored on the server in the form that it is delivered to the user. It may however be generated from a different format before it is uploaded to the server. Static web pages typically have a unique URL for each page.
  • A dynamic web page is created at the time it is requested. The same URL may have different content depending on the user, time, location, etc.

Guideline 2:  A determination of the size of a static website (or the static part of a dynamic website) should include the number of static web pages as well as the number of other web assets (images, PDF, etc.). As a result, each static web page shall be reported as a separate web page.

Guideline 3: A determination of the size of a dynamic website (or the dynamic parts of a static website) should include the number and size of records or items stored in the databases on which the dynamic website is based. As a result, dynamically created web pages are not a pertinent indicator but rather the number of editorial content items stored in the underlying database(s).

Website purpose and target audience

Websites can only be effectively monitored and analysed if there is a clearly defined purpose and target audience(s). These definitions will help you choose which metrics are the most suitable.

Guideline 4: Define from the outset the purpose of your website and its target audience(s) as a precondition for effectively evaluating your digital presence.

How to calculate the costs of a website?

When calculating the costs of a website, you should take into account both quantitative and qualitative elements, such as:

  1. The Total Cost of Ownership (TCO) = (price for editorial content creation and regular updates/ revamp/translation) + (price per site creation/ development/maintenance/ IT updates) + (price for transferring /archiving or site deletion).
  2. Amount of user-generated traffic is a key indicator to justify the existence, the updates costs and the regular IT maintenance of a site.
  3. The costs of a website is proportional to its size and functionalities. It is therefore important to have a clear idea of the contents size and associated IT resources. For static and dynamically  generated pages, these can be found in different ways:
    • For static platforms: through reports on pages views, number of visits over time, site size, number of documents per types (PDF/ videos/ppt).
    • For dynamic platforms: through reports on contents consultation, number of visits over time, size of the database, number of registered users, number of services subscribers (e.g. newsletters).
    • If a site uses a mixed set of technologies, both must be reported and taken into account, because the extra complexity can introduce substantial costs at development time and certainly if an archiving mechanism is needed.
    • Post site activity costs like hosting, IT maintenance, and operating systems upgrades are costs which should also be taken into account when deciding between deleting or archiving a website.

The average price for dynamic webpages archive hosting is 7 times more expensive than those for static websites. A site with a global size less than 2GB and whose content represents a clearly identified interest can be archived following the current archiving procedure.

A website which uses dynamic components requiring possible maintenance, future updates or security maintenance (e.g. databases server updates, security patches, operating systems updates and evolution catch-up) needs to be analysed and converted to static before being archived. This is why dynamic sites must be engineered at the conception phase in such a way that information which does not serve a purpose over an extended period of time can be easily discarded when the archiving phase in its lifecycle is due.


1.1.2. Objectives and Planning

Before a site project is launched, it is essential to thoroughly verify whether the plan is mature. This concerns mainly the content of the site and the human as well as financial resources. The plans must be made known to and approved by the hierarchy.

A number of elements must be established, to make sure that the site is developed in a consistent way and that it is well integrated in the existing set of Commission sites. For the successful creation and exploitation of a site, there must be well-formulated goals in the context of the overall Information & Communication strategy, knowledge of the preferences and behaviour of the target audiences, understanding of the media, and a sustainable method for regularly updating the site’s contents and operating its services.

Five basic questions must be answered:

Why?   Who?   What?   How?   When?

1. Why? - Type, purpose and mission

A site is created to answer the needs of its future users/readers. Knowing their expectations and needs provides for the foundations of your project. On that basis, you should set the overall goal or the mission of the site and relate it to the relevant EU‑policies and activities. At that stage, it is important to verify if the needs are maybe already covered by other sites and to possibly re-orient the project towards the improvement of the existing site. This may require close consultation with other internet editors and possibly the creation of a joint editorial board.

If it is clear that a new site is needed, decsions must be taken about the main message or messages that you want to get across by means of the site. This will determine the orientation and the type of site that you want to create.

2. Who? - Target audience

A site can be used to address many audiences, from the general public, to the interested stakeholders or specialists.

Identify the category of users you want to reach. Try to define the goals for each type of user. Several different categories of users may be chosen, provided that the content is organised accordingly. Moreover, each particular audience must be able to see clearly from the outset where to go for the desired kind of information. Be aware that the wider the audience, the more need there will be for the rewriting of existing ‘bureaucratic’ texts and for additional languages. Please see the chapter on Editorial style and policy.

There are statistics available on information needs of citizens and enterprises from several different DGs and sectors. EURES network with the EuroAdviser network and EUROPE DIRECT could provide you these kinds of statistics as well.

Several methodspdf(21 kB) Choose translations of the previous link  exist for identifying your target audience.

3. What? - Subject

You must now decide on the main themes and the sub-themes (sections and subsections) of your site. For more details on this task, please see the chapter on Content.

To make sure that the subject is appropriately covered, you may gather information by a number of means:

  • thorough analysis of current information related to your theme(s) already available or dispersed through EUROPA sites, resulting in a content mapping
  • internal survey among the current publishers in all DGs
  • external survey among information specialists

The EUROPA team, who has a fairly good overview on the information available on EUROPA, can be of help during this stage.

4. How & When? - Calendar and work plan

You should set up a clear action plan for creating and maintaining the site. Make sure that the action plan is in proportion to the human and financial resources you have at your disposal, and that you and the other content providers have the same level of commitment to your end-users. The action plan should cover all the phases of the creation of a site (strategy, content/services identification, design/presentation, choice of technology, content creation and/or migration, launching, etc). Any aims for further development of the site should be mentioned in this plan as well.

The basic steps in the creation and management of your site:

  • approval by hierarchy
  • definition of key messages
  • analysis of audience and their expectations
  • Definition of risks
  • task definition and timing (identification of the content, inventory of the existing content and new content, content supply, proposals for navigation and content projects, services and tools devices, testing stages, post-launch monitoring, etc.)
  • site conception: workflow, content, design, navigation and multilingualism
  • technical decisions: which technology, what tools to use
  • planning of resources - decision on whether or not to use outsourcing (e.g. through the Publications Office for tasks like planning, re-purposing of content, implementation and proofreading). Please see the examplepdf(18 kB) Choose translations of the previous link  of resources needed for the creation of a small site.
  • development and/or adaptation of technical platform
  • testing and launching
  • training of staff

1.1.3. Organisational aspects

The first step in creating a site is to organise a team whose key role is to contribute and edit its overall content and structure. The size of the site and the number of DGs involved will determine the complexity of the organisation to be set up. Such organisation will inevitably cross the administrative boundaries that exist within a DG and sometimes also those existing between DGs. In the case of a site involving several DGs, one DG should take the leadership as DG “chef de file” and should be entrusted with the necessary authority to carry out its role. This has to be acknowledged from the early phases of the project and the existence of an autonomous, dedicated organisational structure, the site's Editorial Board, must be approved by the hierarchy.

Once the site team is formed a charter should be drafted that addresses the vision for the site as well as its users and target group. The charter should also contain approval processes, content management, funding, project management and technology management. Please see point IV in the enclosed Questionnaire.

The organisation that needs to be put in place for a site can vary widely depending on the size and the scope of the site. The description giving hereafter is a comprehensive overview of the organisation that would be needed to manage the policy sites and the main priority sites on EUROPA. Smaller sites will not necessarily need this complete organisational structure. In any case, it is necessary to have a complete understanding about the resources and organisation that will be needed for successful completion of the project.


Without the necessary resources a project is deemed to fail. Before the final green light can be given, it is necessary to have a complete understanding about the resources and organisation that will be needed for successful completion of the project and a formal commitment from the hierarchy that these resources will indeed be available. For important projects, it may be necessary to foresee different scenarios that contain the scope of the project within the limits of the available resources.

Following elements must be taken into consideration:

  • staff to be dedicated fully or partially to the project
  • available budget
  • requirements for the technical environment
  • time deadlines

Key actors

It is important to clearly assign operational responsibilities of the actors, in order to ensure smooth running of the project. A job description should be provided for each profile outlining the corresponding responsibilities, co-operation patterns, specific tasks, the desirable qualifications and required infrastructure.

Content provider (Authors)

Content providers are responsible for supplying material in the form of articles. These articles fulfil the requirements set by the editorial policy in its entirety. Content providers answer directly to their respective editor.


The editor’s role is to validate, upload and approve new content and to manage the translation process for the entire content. Their tasks involve also proofreading (spelling, syntax, missing pages, misprints and misplaced content). Editors are directly responsible to their chief editor for their respective theme/information group. If necessary the editor’s task and responsibility can be further split into sub-profiles.

Chief editor

Chief editors are responsible for their respective content area or theme (main-theme). They sit in the Editorial Board and answer directly to the Board itself and its President.

Chief editors review content to be published and give final approval prior to publication. This implies having a good overview of what is available as well as of what is to be published. It also implies making sure that articles comply with the editorial policy on the one hand and with the political priorities of the Commission on the other.

In some cases the thematic approach may show gaps in the information available or, worse still, may pose the dilemma of what to publish in the presence of controversial or even clashing policies between DGs. In such cases, chief editors have the task of finding compromises and creating a consensus across the administrative boundaries of DGs. It is therefore essential that chief editors have the appropriate degree of authority and that a proper share of their time resources is allocated to the task.

Chief editors also report to the Editorial Board about any problems encountered or suggestions put forward by their editors and content providers.

Site editor

The site editor is ultimately responsible for the site, belonging to the leading DG and chairing the Editorial Board.

Audiovisual editor

The person responsible for acquiring, editing and managing audiovisual material.

Editorial Board


The Editorial Board shapes the editorial policy and thematic approach, manages their implementation and monitors the operation of the content/services supply chain.

The Editorial Board also reviews the structure of the site, notably with respect to the main themes, sub-themes and newsletters and approves (or rejects) amendments to such structure.

The Editorial Board will analyse the results of feedback tools and make decisions regarding the reorientation of the content and service requirements if needed. He/she will also co-ordinate with the horizontal services (Publications Office, DI, etc.) in order to make best use of common methodologies and e-services support functions.


Even if the editorial policy could expand with the experience of all actors involved in the site, final decisions should lie with the Editorial Board. New themes or audience sites should be suggested and approved at the meetings of the Editorial Board. The organisational model, however, should not be too rigid in order to provide for smooth operation across implicated services.



The Editorial Board is chaired by the site editor from the DG “chef de file”, who takes ultimate responsibility for the site.

Chief editors

The core of the Editorial Board is made up by all the chief editors, who are empowered to decide what the site should contain and what should or should not be published.

Senior management delegate

A senior management member (Commissioners’ staff for instance) should be on the Editorial Board. This person would provide input as to the political message and politically sensitive areas of information.

EUROPA representation

A member of the EUROPA team should be included to ensure co-ordination with existing or new horizontal developments within EUROPA.


A member of the web translation unit from DG Translation should be part of the Editorial Board to give advice on editorial and multilingual issues.

Technical managers

The technical departments of DG Informatics offering the services for content production and dissemination should also be represented within in the Editorial Board. They can advice the board on technical issues or features and their compatibility with technical/operational environment of the portal.


In case use is made of an external contractor, the external project manager should also be allowed to assist to the meetings of the editorial board. When use is made of one of the framework contracts offered by the Publications Office, they should be represented as well.

Approval procedures

In parallel with the assignment of responsibilities to the different key actors, a comprehensive overview of the content management workflowpdf(22 kB) and its associated approval procedures must be established.


1.1.4. Project Workflow

The construction of a site goes through several phases:

  • During the preparatory phase, the site's objectives are defined and agreement is reached between the various stakeholders. This results in a detailed site specifications concept plan for briefing the web designers.
  • Follows an iterative phase of prototypes production, resulting in a final design of the website.
  • Next the site will be filled with its initial content.
  • Before launch, a final quality control is done on the site.
  • Once operational, the site must continuously be updated and improved in order to keep the interest of its visitors alive.

First step: definition of the project

As explained in the chapter 'Objectives and planning', during the preparatory phase the various stakeholders will have reached agreement on the site's objectives and on the resources that will be allocated to the project.

This agreement must now be detailed and must result in a brief to the web designers, a document including:

  • the aims and objectives of the site
  • the audience/s it is to address
  • the criteria on which their design will be judged
  • timetable for site design
  • navigation, content hierarchy and content structure
  • alternative navigation systems and transaction services such as search facility, site map, FAQs, feedback, automatic notifications, etc.
  • wire-frames
  • the EUROPA templates
  • the existing presentation style guidelines for EUROPA
  • the legal requirements such as legal notices, data protection and accessibility
  • the technical requirements
    • Where the site will be hosted (see Infrastructure)?
    • Which technology and what tools will be used?
    • What kind of database will be used if any?
    • Specifications of user platforms (browsers environment, connection speed optimisation, etc.)

Second step: site design

1. Rough structure of the site

2. “Storyboard” of the site (i.e. interaction of the potential user with your site)

3. Graphical mock-ups of the Homepage and other representative pages

4. Creation of an interactive prototype (where some relevant links and buttons work) if needed.

Web designers should develop a few ‘look and feel’ ideas to consider. These can be wire-frames, storyboards or mock-ups underlying the information design of the Homepage and the various page types. Once the logical approach has been approved, then web designers will create a few graphical prototypes either as images or as HTML pages. All stakeholders should evaluate these proposals. Getting user feedback will be also very useful in order to assess the efficacy of a particular web design.

Validation by ALL the members concerned (also and especially at political level) of the prototype after the necessary feedback and eventual modifications.

5. Creation of the site’s own graphical chart and set of HTML templates. Creation of images or illustrations.

Prototype designs should evolve until a final decision has been made on one specific design. Web designers should provide then a complete site graphic design specifications for all page types. Finished HTML templates, examples of key pages and illustrations, photography or other audiovisual material will also be provided.

At the end of this step, the resulting design must be submitted to the EUROPA team for validation.

Third step: initial load

The workload associated with this step will vary widely according to the nature and type of site. In some cases only minimal content must be loaded (e.g. a news site). Sometimes a complete set of new content will have to be created and loaded, resulting in a very long initial load phase. In case of redesign of a site, migration of existing content will be necessary, in which case an in depth 'cleaning up' exercise should be envisaged.

Fourth step: check and quality control

Before launch, you should perform a final check of the site. Make sure that all remarks put forward during quality control by the EUROPA team have been taken into account. Use the checklist and add your own specific controls to it so that it can be used for controlling new additions.

Fifth step: Maintenance

1. Update your website regularly in order to ensure that content is always up to date and remains attractive. Don’t change the essential parts of the design; let the user become familiar with the look, navigation, interface of your site.

2. Collect effective images to illustrate the themes, especially in the portal pages. (While being aware of copyright issues, of course).

3. Adapt the graphical style of the interface to meet changes in the structure (i.e. making new buttons or icons matching the existing).

4. Encourage people who supply written content to include illustrations in their manuscripts. Don’t allow ad hoc changes to essential parts of the site (navigation, interface, typography …). Fix a graphical charter for your site and stick to it - until you decide to change it.

5. If the structure of information of the site changes substantially, then a complete renovation is needed, and you should return to the first step.


  • Site specification/Concept paper/ Project description
    • target audience
    • subject of the website
    • navigation/organizational structure of the site
  • Relevant standards (IPG, technical standards)
  • Relevant contraints (Data Centre, DIGIT, etc.)
  • EUROPA templates
  • Illustrations, photography, audiovisual content
  • Copyrights
  • Standard central images


  • Interface design and master pages
  • Graphic charter: graphic design specifications for all page types and levels
  • Illustrations, Photography, other A/V, etc.
  • Finished HTML template pages

1.1.5. Resources

DGs can get support for their site projects from four services: DG Communication, DG Translation, DG Informatics and the Publications Office.

  • The EUROPA team in DG Communication gives editorial advice during the entire period of site creation. It also performs the quality check of the site prior to publication.
  • The web translation unit can help you, not only for translating the web pages, but also for checking the language quality of your original texts.  
  • DG Informatics together with the technical team in DG Communication advises on technical implications. It checks with the originating department whether the techniques envisaged for implementing the project on EUROPA are compatible with the Commission’s general informatics architecture and that of the EUROPA server in particular. DG Informatics provides the necessary infrastructure core e-services to implement the project. (e.g. Authoring or Interactive services).
  • The Publications Office gives advice during the planning period. It can also help you with implementing your outsourcing scenario for all processes through its framework contracts (see Publications Office website on MyIntracomm and its website on EUROPA).

Apart from the information contained in the IPG, the major other information sources in this context are: 

  • The Interinstitutional Style Guide defines the standard drafting conventions for all the institutions in all the official languages (e.g. official names for countries, institutions, currencies, etc.).

1.1.6. Services

A site must integrate all services that are relevant for the theme being dealt with or the audience being targeted. The services offered range from basic ones that must be available on all sites to sophisticated transaction services that are tailored to the specific needs of the site's users. A whole spectrum of technical tools and e-services is available to implement these services.

Services can be broken down into the following categories:

General ‘first help’ horizontal services

Contact, FAQ, About, Site map, Search, A-Z Index

These services help the users get to know the site, either through immediate information or via a contact point. They are basic services that must be offered on each page of the site at the mandatory place on the screen.

More specific or contextual information services

What’s new, Reference library, Glossary, Key Issues, Information bulletin, Who’s who in the DG or the theme area, related events…

These services help the users to find information, news, subjects, and documents on the site. It is important that these services cover the complete set of information that the site wishes to provide. The glossary, for example, should contain all terms, i.e. those present in the site pages themselves as well as those present in the pages the site links to.

Interactive services

Blogs, Vlogs, Discussion forums, Chats, Social networks, Subscriptions, Surveys, Feedback, e-voting, Site rating, Information sharing, Syndication, Interactive maps

These services establish a direct interaction with the citizens, media, business, opinion leaders or decision makers. Their set-up should be carefully planned and cannot take place without provision for the proper back office facilities to support and manage them.

The "Flexible Platform" environment offers plenty of interactive services.

Transaction services

Ordering, Application, Calls for tender, Project management, Events registration

For online transactions a secure connection and online credit card verification should be established. The transaction for the payment should be safe. The Publications Office offers the features for online payments of publications (EU Bookshop).

  • The privacy statement must be clearly stated.
  • The return policy must be clearly stated.
  • Delivery methods and timing must be described.
  • The order page must be secure.


One of the possible assets of a site is its ability to be personalised. Although it is by no means required, it adds greatly to the usefulness and overall site experience if the users can choose the elements on display on the site. Furthermore, personalisation is something users have come to expect; failing to offer it might lead to disappointment.

There are several ways of implementing a personalised site:

Personal profiles

This form of personalisation requires the users to be 'known' to the site (through either direct or indirect sign-on), so that the site's content can be dynamically generated in function of the users' needs. This calls for the putting in place of a sign-on mechanism and policy. Sign-on policies can be based on Roles (e.g. lawyers, business me, etc.) A main problem with Roles springs from the underlying assumption that users can only take one role, which is not necessarily the case. An alternative to the Roles approach consists of using Rules instead of Roles. Rules are policies or conventions that are set up to achieve efficiencies and that are independent of the specific role of the users in question. (e.g. geographic location of the users, current time and date ...) An advantage of a rule-based policy is the flexibility it provides. In addition, it is much easier to use this approach if users access changes frequently. The main disadvantage comes to the fore on times when users require specific information due to his or her role, that they are not able to access because a more general rule keeps them from doing so. In an attempt to get the best from both worlds, most organisations prefer to run a Role-Rule "hybrid" that best fits their needs.

Pre-defined user classes

This technique is entirely based on the definition of Roles. Instead of having the user log on to the site, this approach considers a role as a pre-defined ‘user class’, the features and characteristics of which are discovered when defining the site’s target audience. The site’s Editorial Board plans for a separate section for each of the identified user classes, in which information access is structured to suit their specific needs. This approach is less demanding on the technology side and may also be perceived as less intrusive by the user (no need to login), yet it calls for a great deal of careful on-beforehand planning.


1.1.7. Quality requirements

Sites on EUROPA must satisfy the quality requirements described in this guide. DG Communication offers a quality control service that checks the editorial as well as the technical quality of the site.

The quality control, which is carried out both for the technical as well as the editorial aspect of the site, aims to help DGs to improve the quality of their websites by identifying shortcomings and errors as far as the IPG is concerned and by making suggestions on how to improve their site. The chapter on quality assurance gives a complete overview of the work involved and contains checklists that can be used during construction of the site in order to ensure that the final product complies to the IPG requirements.

Whenever site construction is outsourced, the contract must contain the necessary clauses to ensure the site quality according to the IPG rules. For all contracts concluded via the Publications Office, the conformity to quality criteria (e.g. IPG) is included.


1.2. Types of websites

Official websites of the EU must always be part of the domain. Sites managed by the Commission can belong to:

  • the institution-independent domain: sites which mission and content go beyond the activities of one single EU institution, or covers a policy, activity or campaign which is common to the different EU institutions and bodies.
  • the Commission domain sites which provide information or services related to the activities of the Commission's Directorates-General.

The inventory of EUROPA websites lists all the sites managed by the Commission specifying the URL, the manager and much other information for each site.

These websites can be divided into several categories:

  1. Generic sites
  2. Organisation oriented sites

All websites on EUROPA must follow the rules described in this Information Providers Guide (IPG). Particular attention should be given to the following basic rules:

  • Sites have to use the standard templates, either the Interinstitutional template or the  Commission's template.
  • Certain elements concerning legislation, statistics, press releases, publications, relevant Directorate(s)-General, policies, etc. should be present:
    • For "legislation", link to EUR-Lex
    • For "press releases", link to RAPID
    • For "statistics" link to EUROSTAT
    • For "publications", link to OP
    • For "DG" site, link to the sites of the DG(s) managing the thematic site (<dg_name>/index_xx.htm)
    • For general EU information on the policy, link to interinstitutional page (<policy>/index_en.htm)
  • Its content has to be available in all official languages or as many of the official languages as possible; if not, the reason(s) why should be clearly explained somewhere in the site.
  • The purpose and the target audience(s) of the site have to be specified on the home page or on a page at the highest/entry level of the site.
  • The site has to be structured by subject in an intuitive and user-friendly way.
  • All names of folders and files have to be in English and in lower case.
  • The language of each page has to be indicated as per relevant template.

1.2.1. Generic

The purpose of generic sites is to provide information and ensure communication in the relevant field within a coherent and stable framework independent of the Commission's administrative structure.


Generic sites are created to offer the visitor a user and task oriented view on the activities of EU in general and the Commission in particular. Every generic site is managed by a leader who is responsible for designing the contents of the site in accordance with the rules laid down in the IPG, and for ensuring that information is regularly updated. The leader has overall responsibility for editorial quality (updating, coherence, multilingualism, graphics, etc.) and the technical aspects of the site. He ensures that the site is easily accessible on EUROPA.

Generic sites are directly accessible from the following pages:

If information on the generic site emanates from several DGs, the leader coordinates design and updating through a steering committee which he convenes as often as required. All the originating DGs take an active part in the committee's work. The committee also comprises a member of the EUROPA team in DG Communication. The members of the steering committee are appointed by their own DG.

The EUROPA Editorial Committee (EEC) grants every generic site leader the necessary powers vis-à-vis the other participating DGs. Each leader regularly reports back to the EEC on the current state of its site. Leaders are free to decide whether site management will be centralised (which ensures better coherence but involves a considerable workload for the leader) or decentralised (requiring close coordination by the leader between the various units involved).

The  list of current generic sites specifies the URL, the leader and the DGs associated with each site. At a  DG's request, additions may be made to the list.

Types of Generic sites

'Generic' sites include:

Top Policy site

Site giving information on a specific policy for which the Commission is responsible (e.g. environment, health, agriculture ...)


A "Policy" site deals with a specific area of activity for which the Commission is responsible (e.g. environment, health, agriculture ...).  Policy sites constitute the core of the Commission site. They are managed in a decentralised way by the web teams in the DGs. Policy sites present all the information on the given policy independent from the internal organisation of the Commission.



Policy site: Energy



Recommended Technology

"Policy" sites should be constructed and maintained using the Commission's Corporate Web Content Management System.


A "Policy" site should attach particular importance to the following criteria:

  • Although a policy site is always administered by the web team of one single DG, it must not be confused with a DG site. Even if one DG is clearly the leader, most of the Commission policies need close collaboration between several DGs and in some cases a particular policy can be co-managed by several DGs on an equal basis. Whatever the situation, a policy site should present all the information on the given policy independent from the internal organisation of the Commission. It should behave as a portal and contain all the links to the relevant subchapters on other policy sites. A policy site must present all the information. 
  • The latest information on the policy must be promoted prominently. Special attention must thus be given to the "Press releases" section. This is the minimum to be included on a policy site but it is advisable to go further and create a "News" page to provide the media with additional topical information (e.g. specialised newsletters, calendar of events, photos, videos, speeches and other multimedia material). 
Top Priority site

Site dealing with a subject that has a high priority within the EU context


A "Priority" site deals with a subject that was given high priority in the yearly work program on inter-institutional or Commission level or that is getting much attention in the public sphere, possibly for a limited period (a "hot topic"). 

If the subject is formally recognised as having high priority, it is justified to dedicate a complete separate site to it. If the subject is no longer a priority, the site may disappear and be archived or integrated within a policy site.

If the subject is not formally identified as having high priority, but still important enough to get special treatment, no separate site should be created. Instead, one should create a section in the relevant policy site that is completely integrated in it. In that case a short URL-alias can be allocated to give the priority site a specific name.

The purpose of the site should be clearly specified.


Priority site:


The URL will depend on the level of priority. If the priority is formally recognised as having high priority, it is justified to dedicate a complete separate site to it, that has an URL on its own. If it concerns an important topic that has not formally high priority, the site should be integrated in the relevant policy site. For the purpose of promotion and visibility, it may then have a short alias, redirecting to the real address of the site:

  • priority at EU level:<priority>
  • priority at Commission level:<priority>
  •  important topic:<priority redirecting to<policy>/…/<priority> 

Recommended technology

"Priority" sites should be constructed and maintained using the Commission's Corporate Web Content Management System.


A "Priority" site should attach particular importance to the same criteria as a "Policy" site.

Top Programme site

Site offering direct services to users in the context of a programme managed by the Commission


A "Programme" site is created to support a particular programme managed by the Commission. It offers information about the programme and provides services to participants of the programme. Programme sites may consist of a closed and an open part: the closed part being only accessible to a closed group of registered users, the open part offering information to everybody.


Programme siteMarie Curie Actions


  • Main URL of the site giving access to the public information<programme>/index_xx.htm, redirecting to<policy>/.../<programme>/index_xx.htm

  • URL of the closed part

The closed part, for technical and/or security reasons, should use an URL in the 'webgate' domain<programme>/index_xx.htm

Recommended Technology

"Programme" sites should be constructed and maintained using the Commission's Corporate Web Content Management System. In order to offer the interactive services needed to support the programme, parts of the site may use other technology (JSP, Drupal ...).


A "Programme" site should attach particular importance to the following criteria:

  • The site should focus only on the programme itself and must refer to the relevant policy site for background information.
  • The number of languages in which a programme site is offered will depend mainly on the audience targeted. Programmes targeting a very specialised audience (e.g. research programs) may have been limited in terms of multilingualism. Programmes targeting a very wide audience should be available in all official languages or as many of the official languages as possible; if not, the reason(s) why should be clearly explained somewhere in the site.
  • The purpose and the target audience(s)  of the site have to be specified on the home page or on a page at the highest/entry level of the site.
  • Whenever links are made to the closed part of the site, the user must be warned that he will enter a restricted area of the site and he must be informed about the conditions required to apply to the group of users that can have access to it.
  • The closed part of the site must implement the necessary security measure for protecting the restricted area in the most appropriate way.
Top Campaign site

Highly interactive site in support of a specific communication campaign


A "Campaign" site is created to support a specific communication campaign with interactive events on the Internet. It will thus generally contain highly interactive elements that require specific technology. The site should focus purely on communication and should refer to the relevant policy site for background information.



"Campaign" sites are always targeting the general public and should thus be part of the institution-independent domain. The recommendation is to define the site as a subsite of<campaign>/index_xx.htm

Given its short lifetime (in general less than a year), use of a top level name such as http://<campaign> should be avoided.

Recommended technology

"Campaign" site should use the technology that is most appropriate to deliver the functionality required by it. Several options are open: Flash, JSP, ColdFusion, Drupal, Documentum ...

The choice should be made in consultation with DG COMM and DIGIT.


 A "Campaign" site should attach particular importance to the following criteria:

  • The site should focus purely on communication and should refer to the relevant policy site for background information.
  • The graphical presentation of the site and the language used must be adapted to the purpose of the site, i.e. 'communication'. Nevertheless, given that a campaign site is still an official EU site, the basic rules about presentation should still be respected, in particular with respect to the use of the template: the EUROPA template must be used. 
  • The number of languages in which a campaign site is offered will depend mainly on the audience targeted. In general, campaigns will target the widest audience possible and the supporting site should thus be available in all official languages. 
  • It must be very clear on the home page which audience is targeted.
  • The site must be taken off line at the end of the campaign.
Top Event site

Site created in the context of a particular event. Aimed at promoting the event and supporting its organisation.


An "Event" site is created in the context of a particular event (e.g. Green Week). Its main purpose is to promote the event and to provide electronic services to support its organisation (e.g. subscription forms). An event site always fits within a particular policy site, but can be promoted separately to improve its visibility to the outside world. It should focus only on the event itself and not repeat the background information that can be found through links on the relevant policy site.


One can distinguish several types of event sites, depending on the nature and lifetime of an event:

Important recurring event: European week of Regions and cities

One-off specialised event: European Future Technologies Conference and Exhibition


The URL to be used for an event site will depend on the nature of the event.

For important EU events targeting the general public, an URL in the domain should be used. Preference should be given to sub-URLs, possibly supplemented by top-level aliases for very important public events.<event>/index_xx.htm

For more specialised events of conferences organised by individual DGs, an URL in the domain must be used. An alias can be created that redirects to a section within the parent policy site.<event>/index_xx.htm, redirecting to<policy>/.../<event>/index_xx.htm.

Recommended technology

The "Event" site should use the technology that is most appropriate to deliver the functionality required by it. Several options are open:

Flash, JSP, ColdFusion, Drupal, Documentum ...

In the framework of the "Flexible Platform", a standard "event site" was created. This environment can be used to generate a new event site in very short time by means of simple customisation rules. This solution should be adopted whenever possible. In any case, the choice of technical solution should always be made in consultation with DG COMM and DIGIT.


An "Event" site should attach particular importance to the following criteria:

  • The site should focus only on the event itself and must refer to the relevant policy site for background information.
  • The number of languages in which en event site is offered will depend mainly on the audience targeted. If a very specialised audience is targeted the site could be be limited in terms of multilingualism. However, sites targeting a very wide audience should be available in all official languages or as many of the official languages as possible; if not, the reason(s) why should be clearly explained somewhere in the site. 
  • It must be very clear on the home page which audience is targeted.
Top Service site

Site offering a specific service to the visitor (e.g. electronic bookshop, translations, customized consultancy for specific queries, etc.)


A "Service" site focuses on offering a well-defined specific service to the visitor. Electronic services can be offered in multiple contexts, either as part of a general site or as a stand-alone service. This sheet talks about stand-alone service sites that have no other means than offering the service concerned. "Service" sites can address a general audience or can focus on a particular group of stakeholders.


Service sites:

  • EU bookshop: central site managed by the Publications Office where visitors can find information on publications of all EU institutions and possibly order them. The EU Bookshop targets a general audience.
  • EU Press Room: portal grouping all the services that the EU is offering to journalists: press releases, media libraries, broadcasting, etc. 
  • EU law in force: central database of all official EU legislation.
  • Researches in Motion: a one-stop shop for researchers seeking to advance their careers and personal development by moving to other countries.


  •<service_name> for services offered by the Commission
  •<service_name> or http://<service> for services offered by an interinstitutional organism


A "Service" site should attach particular importance to the following criteria:

  • A "Service" site should focus on the service itself and must refer to the relevant policy site for background information.
  • A "Service" site must be completely task-oriented: when entering the site, it must be immediately clear for the visitor what he can do and what is the most efficient way to do it.
  • The number of languages in which a service site is offered will depend mainly on the audience targeted. If a very specialised audience is targeted the site could be limited in terms of multilingualism. However, sites targeting a very wide audience should be available in all official languages or as many of the official languages as possible; if not, the reason(s) why should be clearly explained somewhere in the site.
Top Audience site

Portal offering specific services to a particular audience and providing the gateway to all relevant sites within EUROPA that are of interest for this audience


An "Audience" site is targeted on a particular section of the public to offer direct access to selected information of specific interest to this audience (e.g. senior citizens, the scientific community, the media). Users should be able to find the information they are looking for without having to be familiar with the internal organisational complexities of the Commission.  


Audience site: Researches in Motion


Depending on the audience addressed, the site should be hosted in the EUROPA or the Commission domain:

  •<audience>/index_xx.htm or


Recommended Technology

The core of an "Audience" site should be constructed and maintained using the Commission's Corporate Web Content Management System. In order to offer the interactive services needed, parts of the site may use other technology (JSP, Drupal ...)

Specific Criteria

An "Audience" site should attach particular importance to the following criteria:

  • An "Audience" site should behave as a portal, offering all relevant services to the audience concerned and providing a gateway to all relevant sites within EUROPA that can interest the audience.
  • The number of languages in which an "Audience" site is offered will depend mainly on the audience targeted. If a very specialised audience is targeted the site could be limited in terms of multilingualism. However, sites targeting a very wide audience should be available in all official languages or as many of the official languages as possible; if not, the reason(s) why should be clearly explained somewhere in the site.
  • It must be very clear on the home page which audience is targeted.
  • The graphical presentation of the site and the language used must be adapted to the audience targeted.

1.2.2. Organisational sites

The purpose of organisational sites is to provide information about the Commission's organisation.


An organisational site provides information about the internal organisation of the Commission or is a "Service" site that is used to organise and support the collaboration with external partners. There are 2 types of organisation sites:

Top Functional sites of the Directorates-General

A DG site provides information on the mission of a Directorate General and on its internal organisation.


Each Directorate-General provides the following information on its functional site:

  • the DG's mission
  • organisation chart (a simple link to "EU Whoiswho", the official directory of the European Union - instead of including the chart - avoids duplication and the risk of differences in updating)
  • link to their Commissioner's site
  • link to the "Policy" site or sites which wholly or partly come under the DG's responsibilities



Recommended technology

DG sites should be constructed and maintained using the Commission's Corporate Web Content Management System.


A DG site should attach particular importance to the following criteria:

  • The information given must be very factual and minimalistic: only some minimum content regarding the mission, organisation chart, the relevant Commissioner and link(s)to relevant  thematic site(s) should be present.
  • For a detailed organisation chart, the site should link to the Commission Directory.

Top Commissioners' sites

Each Commissioner has their own site on which they present their views and responsibilities. The sites are managed by their private offices (Cabinets) or by DG COMM (at the Cabinet's request).

The Commissioners' web presence is currently under review as part of the Digital Transformation project.

Commissioners' sites generally include the following content:

  • summary of responsibilities
  • short biography
  • link to the site(s) of the DGs for which the Commissioner is responsible
  • declaration of interest
  • Commissioner's team
  • agenda
  • contact information
  • latest news and speeches from RAPID



Commissioners sites should be constructed and maintained using the Commission's Corporate Web Content Management System.

URL structure<commissioner>_xx

Top Collaborative site

A collaborative site offers collaborative services to a group of users that share a common interest. Services include document sharing, work planning, contact management, collaborative workspaces, discussions, wikis, personal profiling, etc. Most collaborative sites are restricted to a closed user population and thus belong to a different family than the 'normal' information and communication sites on EUROPA.


A collaborative site is a specific case of a service site that focuses on establishing a virtual environment to enhance collaboration between the members of a working group. Most collaborative sites are thus not really part of the normal EUROPA family, but in many cases the results produced by the collaboration are published on a 'normal' EUROPA site. It is important to separate the closed collaborative part from the open dissemination site. Whenever possible the two environments must be well separated and accessed via different addresses. Only when the collaborative section of the site is small and open to everybody can the site be presented under one access point.

A collaborative site can offer a large range of services:

Documents sharing 

A common repository of documents that constitute the knowledge base of the working group. A sophisticated document access management is part of the service.


Tools for work planning, task management, contact management, integrated mail and conferencing tools.


Integrated threaded discussions, blogs, and wikis with related content and federated search.

People management

Facebook-like user profiles, friends, message boards.


Internal Market Information System IMI


Closed collaborative sites cannot be integrated in normal Europa sites. They must be integrated in the 'webgate' family of web applications and use the secure 'http' protocol. Their URL will thus have the following format:<service-name>

Recommended technology

Given the wide diversity of collaborative services, it is not possible to recommend one particular technical tool to implement a particular collaborative site. Several approaches are possible:

  • CIRCABC is a generic tool for collaborative sites that was created in the context of the IDABC program. 
  • Sharepoint, the internal collaborative tool is also a potential candidate for creating collaborative sites.  
  • The Flexible Platform offers a set of interactive tools (blogs, forums, wikis ...) that can be used to create the services of a collaborative site.
  • In some cases, it may be necessary to create a specific environment using one of the generic application technologies.

Specific criteria

Collaborative sites are usually closed sites and are thus not really part of the normal EUROPA family. When such a site is referenced from a 'normal' EUROPA page, the corresponding link should be accompanied by a warning message explaining to the visitor that he will be directed to a closed site requiring a login/password in order to be accessed. The visitor should also be informed about the nature of the site and its target audience. The same information must be provided on the home page (login page) of the collaborative site together with and explanation of the procedure for obtaining a user account.


1.3. Mobile

More and more users access content using mobile devices, such as a smartphone or tablet. It is therefore important that the European Commission's websites and related tools are optimised for viewing on mobile devices.

The Europa team at DG COMM provides support for two of the most popular options for mobile web projects: responsive web design and mobile apps.


1.3.1. Website or mobile app?

Given a choice, it is almost always better to offer digital services via a website instead of a mobile application (app). A website is cheaper and easier to maintain, and a lot more people will see the content.

If you build your site according to the principles of responsive design, that one site can be served to desktop screens, tablets and smartphones – with the layout automatically optimized for the screen size of the device it is being viewed on.

Thanks to this one‑website‑fits‑all approach, your content can be accessed by the widest audience possible no matter what device they are using.

Why a website is better:

  • Cheaper: Only one site needs to be developed. Developing an app is more expensive, because you need a different app for each mobile platform (Apple, Android, etc.).
  • Easier to maintain: A website in a responsive design can be easily maintained in-house with standard web publishing tools. Updates to content can be made immediately. Updating an app requires additional development by a contractor. Then the app must be re‑validated by the app store, which can take weeks. An app needs to be tested every time there is a change to a mobile operating system (which happens at least once a year).
  • Easier to find: The entire content of a website is indexed directly by search engines so it can all be easily found. An app is more difficult to find, and only its app store page is indexed by search engines.
  • Less competition: A mobile app is in constant competition with other apps for a user's attention. The average smartphone user has 41 apps installed on their phone, but 51% of them only use 1 to 5 apps per week. One quarter of downloaded apps are opened once and then never again.
  • Easier to monitor: Website analytics provide many metrics indicating how visitors use a site. It is more difficult to measure app usage apart from the number of downloads.

1.3.2. Web apps

A web app is an app that is based on the latest web technologies such as HTML5, CSS3 and JavaScript. It can have the look and feel of a native app, but it does not have the same level of access to hardware features as a native app.

In more detail

Whereas a responsive website can be used by the majority of modern and not so modern browsers, a web app can only be used by modern browsers due to the implementation of state-of-the-art web technologies.

This use of state-of-the-art web technologies is also a major drawback as web apps are not accessible either to users using older browsers or to users not using main-stream browsers. This is not in-line with the WCAG 2.0 level AA, and therefore should be considered cautiously. Conclusively, in general, a responsive website should be the first choice.

A web app should be seen as a progressive enhancement to an existing responsive website. An exception to this rule might be a game realised as a web app, where the user interacts in a different way with the website and where the access to information or the processing of content is not the primary goal.

To be in-line with the WCAG 2.0, Level AA, a non-compliant web app can only offer access to information, if alternative, compliant ways are available. An example could be an interactive map that offers access to country-specific information. In this case, an alternative way to access this information has to be available.

Website or web app

A web app runs in a browser and is based on HTML5, CSS3 and JavaScript. It can have the look and feel of a native app, but it can't use all hardware features of a phone like a native app.

Web apps are not supported by older browsers and so they are not in line with accessibility standards. Therefore, a web app can only be considered if there is another way to access the information it provides.

Mobile app or web app

Comparing web apps to mobile apps is very much like comparing responsive websites to mobile apps, because the same principles apply. This means that a web app is cheaper, easier to maintain, easier to find and easier to monitor.

As web apps use the latest web technologies, such as HTML5, CSS3 and JavaScript, they look and feel a lot like native mobile apps. One difference between web apps and mobile apps is that web apps cannot use all hardware features of a phone. This means that in the majority of cases web apps are the better choice. Only in those cases where the use of hardware features is needed – e.g. the camera for barcode scanning – the development of a mobile app might be justified.


As a conclusion, a website using responsive webdesign is in the majority of cases the preferred choice. If more modern features have to be used, web apps are an alternative.

Guidelines for webapps

  • The visual identity of the European Commission has to be ensured in such a way that it is clear at any stage that the webapp is owned by the European Commission;
  • The latest versions of all major browsers have to be supported; - In case the content provided by a webapp is unique, it has to be ensured that it is available in an alternative way – an example would be a map displaying youth unemployment in Europe. In this case a table has to be provided to give access to the data in a WCAG 2.0, Level AA compliant way;
  • If the webapp is not compliant with the WCAG 2.0, Level AA, then the content has to be made available in a compliant way – for instance via the website hosting the webapp. - A link to the WCAG 2.0, Level AA compliant content has to be provided at all times;
  • The only exception is non-unique content realised as gamified webapp (e.g. games, quizzes). These webapps don't have to be WCAG 2.0 level AA compliant. Yet, any restrictions, such as limited browser support or limited accessibility have to be indicated when linking to a game.

1.3.3. Responsive web design

In responsive web design, the same website is served to desktop screens, tablets and smartphones but the layout changes and adapts to the screen size. One website fits all. It allows content to be accessed by the widest audience possible no matter what device they are using.  Responsive web design has grown in popularity since 2011 and is considered a good approach to manage a website as the variety in screen sizes continues to increase.

The first Europa website to become responsive was Your Europe Citizens.

Standard templates in responsive design

The inter-institutional and European Commission templates are available in a responsive design.

Think "mobile first"

You should think of mobile visitors first when planning your content and layout. Give priority to tasks and content that are most important for them. Then, for each breakpoint of the template, arrange content and features according to the different screen sizes.

Implications for your content

In responsive web design, a page of text that is completely visible on a desktop screen will require some scrolling on a smartphone screen. This is unavoidable but you can provide a better browsing experience by ensuring that your texts are easy to read and easy to scan.

Much of the advice in the 'Writing for the Web' pages is even more important to consider when managing a responsive website: the 'bite, snack, meal' structure, short paragraphs, concise texts and meaningful headings.

If you are moving a website to the new template then you should take the opportunity to review your existing content and simplify it and reduce it.


1.3.4. Mobile apps

Mandatory requirement Single corporate European Union accounts have to be used for all of the major app stores.
You must submit a request to create an app to DG Communication. 

View all IPG Rules

A mobile application (or 'app') is a dedicated software application built specifically for smartphone or tablet operating systems (Apple, Android, Windows, BlackBerry, etc.).

Apps are useful for performing frequent tasks on a regular basis and are good for addressing specific audiences and activities.

However, if what you want your app to do can be done by a website, it is best to do it with a website with responsive design. This is a cheaper and easier‑to‑maintain solution, and more people will see the content. See choosing the best option.

Request the app

To ensure that your app fits with the Commission’s mobile strategy, that development goes smoothly and that last-minute surprises are avoided, you must consult upfront all relevant stakeholders in the Commission, in particular the EUROPA team in DG Communication and the Internet editors of the DGs that could be interested in the subject of the app.

You must submit a formal request to create an app to the EUROPA team in DG Communication before the requesting service commits any budget, enters into any contract and before any development work starts.

Before sending the app/content creation request to the Europa team, the endorsement of the Head of the Communication Unit of the requesting DG must be obtained.

Plan the app

It is highly recommended to carry out a feasibility study to determine whether there is a real need for the app for your content.

  • Define what you want to achieve.
  • Define your audience - does it use mobile apps?.
  • Be clear about what your app will do. Apps are for simple tasks, don't add unnecessary features.
  • Decide how you will measure performance. For example:
    • increase in visits to website
    • increase in queries to support helpdesk etc.
  • Decide on the platforms that you will develop the app for. As a public service, the Commission cannot favour one platform over another, but app development is expensive and so cost versus reach has to be considered.
  • Decide on the languages in which that the app will be available.

Terms of reference

When drafting your terms of reference, consider the following:

  • Provide formaintenance for bug fixes and possible modifications. The app must also work with subsequent new versions of mobile operating systems.
  • Professionally written app‑store descriptions.
  • App icons (in line with the visual identity) and screenshots for the app store pages.
  • Commission access to test versions (using products such as TestFlight for iOS).

Design and user interface

The Commission's visual identity graphic charter has mandatory design requirements for the app icon and the splash screen.

In addition, operating systems have written extensive user interface guidelines. You should design your app with these in mind.

App store accounts

Do not create an individual account in the app stores. You must use the corporate European Union accounts in the major app stores managed by the Publications Office:

  • Apple iOS App Store
  • Google Play
  • Windows Phone Store
  • BlackBerry App World

The final build or signature of the app must be done by the Publications Office, because an app must be electronically signed with the Publication Office's app store private keys. The only exceptions are Windows Phone apps.

To use the European Union accounts, you must contact the Publications Office at the start of your project and provide details, planned launch dates and a contact person. Plan ahead: Apple, for example, takes around two weeks to approve apps.

Transferring an existing app to the corporate accounts

  • Apps can be transferred from another account to the European Union account. Contact the Publications Office for more information.

List of EU apps

A list of all EU mobile apps can be found at the Publications Office.


1.4. Information Architecture

Information architecture (IA) is the combination of organization, labelling, and navigation schemes on websites to assist people to achieve their information needs.

IA is the foundation of good website and design. It is about planning where information and services will be located on the website in the most convenient and logical way for users.

Effective IA helps users to meet their business needs.

Identifying business goals, target audience...

Before designing or redesigning a website, you have to consider the business goals of the website.

A good IA can address both business goals and user needs. User needs include both the activities users will want to undertake on the website and the information they want.

Different groups of users may have different needs or expectations of the website. Audience groups for a website may be farmers, students, researchers, citizens, business people, etc.

Consider listing what each user group may wish to achieve on the website - the information they may be looking for and the tasks they may like to undertake on the website.

A number of techniques can be used to assist in understanding users' needs. These include:

  • user surveys, focus groups
  • analysis of usage statistics
  • analysis of feedback

Consider what services, functionality or information can be provided on the website to meet identified needs and goals.

For each of the user needs identified, consider an example of how a user may meet these needs on the website and what activities they may undertake on the website. Where the need is to find information, the example may include a list of information the user requires. Where the need is to conduct an activity on the website (for example completing a form), the example may include the steps in the process that the user would undertake.

There are a number of different website structures which may be appropriate for different target groups and purposes.

Defining the content

Once the information needs of users and the required functions have been identified, you have to create a list of the content or content types that are needed on the website. Read more in the Content chapter.

Grouping and labelling the content

Once the content and services to be provided have been identified, they can be sorted into logical groups. Understanding the users' needs and identifying the content to meet their needs may provide some guidance regarding how to group the content.

It may also be useful to gain input from focus groups to help ensure that their needs are met.

A number of methods can be used to sort content. These include:

  • Card sorting

This involves writing each element of content or content type on a separate index card, sorting them into groups of related content and describing the groups. The results of the grouping can be analysed as another input to the IA of the website.

  • Written outlines 

Try to organize and number your content:

1 Category1
    1.1 SubCat1
    1.2 SubCat2
        1.2.1 SubSubCat1
        1.2.2 SubSubCat2
        1.2.3 SubSubCat3
    2 Category 2
        2.1 SubCat1
        2.2 SubCat2

For example for sorting "Books"


  • Mind mapping

When you mind map, you start with a blank piece of paper and several coloured pens. Draw a small circle in the centre and label it "Home". Each time a new subject comes up, take one of the pens and draw a line out from the circle using a new color for each subject. Give each branch an appropriate name. When a topic relates to one of these main subject branches, draw a smaller branch out of main branch and label it accordingly. The colours help you visualize information that is related, plus any links you need to add from one branch to another.

Determine a logical content hierarchy

Websites structured around a logical hierarchy can make it easier to decide on a navigation system and to design page layouts. Consider the hierarchy that will be most appropriate for the information and services to be provided on the website and that meets the needs of users.

Hierarchies can be narrow and deep, or broad and shallow:

  • Narrow hierarchies

In these there are few main menu choices and many lower levels of the hierarchy. The disadvantage is that the choices may be not be specific enough, so users may need to click through a number of levels to find the information they require. The advantage is that front pages may be simpler and users less confused about the most appropriate menu choice.

  • Broad hierarchies

In these there are a large number of main menu choices but fewer lower levels of the hierarchy. The disadvantage is that, if there are many main menu choices, the page may be cluttered and choices too specific. The advantage is that the information required by users may be only a few 'clicks' away.

Other grouping methods

Not all parts of the website may be hierarchical. Other ways of grouping information include:

  • task-based: ask for a grant, to register
  • audience: individuals, businesses
  • alphabetical: A-Z index
  • chronological:  by date released, date updated …

These methods may be used to group a particular part of the website or as an addition to the main hierarchy.

Create labels to represent information on the website

Once the hierarchy has been developed, all parts of it can be assigned labels, which will eventually be used in navigation and links.

Labels that are accurate and informative are more easily understood by users. Labels based on language used by users and not language used by the Directorates-General (jargon and acronyms).

Map content to the IA

When the grouping and labelling have been developed, the content that will be included in the website can be fitted into the structure of the website.

Reviewing and implementing the IA

Before developing the actual website, it may be useful to review the proposed structure. Ask yourself these questions:

  • Are the business goals of the website met by the structure?
  • Does the structure meet users' goals?
  • Do users understand the labels and language?
  • Is there a place for every piece of information?
  • Does content fit together logically?
  • Is the structure too wide - menus not specific enough?
  • Is the structure too narrow - menus too specific?
  • Does the structure easily allow for growth and change?

At this point it is very useful to test a prototype with a group of users. Do usability testing.

Monitoring and evaluation of the use of the website (statistics) can help judge whether they are meeting their outputs and outcomes, whether the structure is meeting the needs of users and how the structure can be improved.

A structure is never really finished. Changes will continue to take place. Keep the structure of the website and sitemap up to date.

Changes give you opportunity to do things even better.

Documents I need

  • Project Description and planning instruments (calendar and detailed work breakdown plan, resources allocation, including costs list (figures), etc.)
  • Site specifications
  • Existing content, if available
  • Site "storyboard" , diagrams (site maps, outlines, tables of contents)
  • Content plan/schedule: detailed description of site contents
    (hierarchical list of all content (texts, picture material) by page; for each element identify who is responsible for supplying the content; deadlines)
  • Prototype(s)
  • Schedule for site design and construction

Who can help

Work Guidelines and References


1.5. Web usability

Web usability is an approach to make websites easy to use for an end-user, without requiring her (or him) to undergo any specialized training. The user should be able to intuitively relate the actions he needs to perform on the web page with other interactions he sees in the general domain of life, e.g. press of a button leads to some action. The broad goal of usability can be:

  • Present the information to the user in a clear and concise way.
  • Give the correct choices to the users in a very obvious way.
  • Remove any ambiguity regarding the consequences of an action, e.g. clicking on delete/remove/purchase.
  • Put the most important thing in the right place on a web page or a web application.

What to do

It is important to understand:

  • Why you are developing a site.
  • Who should come to your site.
  • When and why those people might come.

Usability aspects, therefore, should be in mind during the whole process of creating and producing a site:

At the definition phase:

  • during the concept definition and planning of a new site
  • during the content definition and structural organisation of a new site

At the development/production of a prototype phase:

  • during the final decision of the final look and the “feel” of the new site
  • during the production of content and the technical elements involved
  • during the (internal/external) testing of the new site

At the quality control phase:

  • during the site quality control/quality assurance (internal or external) testing phase

At the publishing/distribution phase:

  • during the official launch of the new site
  • during the publicising of the new site

At the maintenance/evaluation phase

  • during the editorial maintenance and updates of a site
  • during the technical maintenance and updates of a site


When evaluating the usability of a site, ask these questions:

  • Can the user easily find the information he is looking for?
  • Are the services offered easy to access and are the features offered easy to understand?
  • Is the content of the site presented in a consistent manner?
  • Has the site a logical and comprehensive structure and efficient navigation?
  • Are explanations provided on how the site has been organised or how navigation works?
  • Is it possible for the user to interact with the site and provide feedback? Does he get a quick and satisfactory reply?
  • Are search features offered?
  • etc.

As for the methods of evaluating those criterias, the famous online survey which gathers the general user satisfaction rate about a website is not sufficient. There are a variety of approaches to usability evaluation that you may choose to take.




  • Project report
  • Project quality plan report
  • Project testing report
  • Project quality control report
  • Site evaluation report

Guidelines and references

  •  On 20 April 2004, the European Commission has published its Communication from the Commission to the Council, the European Parliament, the Economic and Social Committee and the Committee of the Regions on implementing the information and communication strategy for the European Unionpdf [298 KB] where one of the main objectives is “to use the Internet  to associate the public in European decision making and to listen to the public and their concerns in order to improve the perception of the EU and its institutions and their legitimacy”.
  • On 2 October 2002, the European Commission has published its Communication from the Commission to the Council, the European Parliament, the Economic and Social Committee and the Committee of the Regions on an information and communication Strategy for the European Unionpdf [149 KB] where it is stressed that “the EUROPA site remains an essential instrument  for bringing the institutions closer to ordinary people and facilitating  contact between Europeans and should be geared more to meeting information requirements of the general public, facilitating access to information sources directly linked to selected priority issues”.
  • On 25 July 2001, in its White Paper on European Governancepdf [179 KB], the European Commission acknowledged that genuine and coherent information and communications policy with the appropriate instruments to carry such policy were the main prerequisites for the development of better European governance.
  • On 6 July 2001, the European Commission has published its Communication by the President to the Commission in Agreement with Vice-President Neil Kinnock and Mr. Erkki Liikanen "Towards the e-Commission - EUROPA 2nd Generationpdf Choose translations of the previous link " [95 KB] where the roadmap is set for the implementation of 2nd generation  websites, reaffirming that EUROPA should offer “information services providing easy access for all to updated, user-friendly and multilingual information tailored to users’ needs”.
  • On 27 June 2001, the European Commission has published its Communication from the Commission to the Council, European Parliament  Economic and Social Committee, the Committee of the Regions on a new framework for cooperation  on an information and Communication strategy of the European Unionpdf [194 KB] where it is reaffirmed that “the main features of the new EUROPA sites should be interactivity, rapid and authentic consultations, research into support by public opinion and a simplified administrative practice for everyone”.
  • On December 1999, the eEurope - an Information Society for All initiative was launched by the European Commission to bring the benefits of the Information Society to all Europeans and to improve productivity and their quality of life by stimulating, among others, interactive public services, accessible to all and offered on multiple platforms.

External sources


The task of evaluating and improving the usability of websites can be daunting given the quantity of sites being produced, the frequency of updates, and the sheer size of many sites. As a result, some automated support for web designers and usability specialists will become an increasing necessity within the overall usability process. Automated usability tools can help save time and money in design and user testing improve consistency and quality of site design, and improve the systematic application of usability standards. Here are some examples of usability tools available in the market:

  • Web Link Validator , or W3C Link Checker , is a site management and link checker tools that help webmasters automate the process of web site testing: finds broken links (including those using JavaScript and Flash), orphaned files, slow-loading, deep, outdated and small-sized pages.
  • Web Static Analyzer Tool (WebSAT) - checks web pages HTML against typical usability guidelines.
  • Web Category Analysis Tool (WebCAT) - lets the usability engineer construct and conduct a web category analysis.
  • Web Variable Instrumenter Program (WebVIP) - instruments a website to capture a log of user interaction.
  • Framework for Logging Usability Data (FLUD) - a file format and parser for representation of user interaction logs.
  • FLUDViz Tool - produces a 2D visualization of a single user session.
  • VisVIP Tool - produces a 3D visualization of user navigation paths through a website.
  • TreeDec - adds navigation aids to the pages of a website.


For further information on usability issues, please contact the EUROPA team.

Workflow Details

  • Defining and planning a new site (i.e. type of site, possible definition and structure).
  • Content analysis, identification and organisation of information to be published (i.e. site content and functionality, content plan, tools and services for the site, WAI elements, metadata, etc.)
  • Defining the prototype.
  • Internal testing of the new site prior to the official launch.
  • External testing of the site prior to the official launch.
  • Regular and constant maintenance and evaluation in order to achieve optimal performance of the site.

1.6. Web Accessibility

Mandatory requirementAs from January 2010, all new EUROPA websites have to be created in compliancy with the Web Content Accessibility Guidelines 2.0, level AA.

Advice on how to meet the standard is detailed in these pages.


View all IPG Rules

Web accessibility aims at enabling all users to have equal access to information and functionalities on the web. More specifically, Web accessibility means that people with all abilities and disabilities can perceive, understand, navigate, and interact with the Web.

According to the UN Convention on the Rights of Persons with Disabilities that has been signed by the European Union, persons with disabilities include those who have long-term physical, mental, intellectual or sensory impairments which in interaction with various barriers may hinder their full and effective participation in society on an equal basis with others.

Internet users can experience problems when using the web because of different kinds of disabilities, functional limitations, environmental factors or technology matters:

  • persons with disabilities: visual, auditory, physical, cognitive
  • older persons, low literacy, others
  • technology-related limitations or incompatibility: browsers, platforms, devices, mobile web
  • environmental factors: place, illumination, noise, slow connection

Persons with disability in Europe are a significant group:

  • 10% to 15% of the total population
  • 50 to 75 million people in EU27
  • There is a strong correlation between disability and ageing => numbers increase with demographic change.

Source: Labour Force Survey (European Commission-Eurostat, 2002)

Why Web Accessibility is important

The Web is an increasingly important resource in many aspects of life: education, employment, government, commerce, health care, recreation, access to information and more. It is essential that the Web is accessible in order to provide equal access and equal opportunity to persons with disabilities. An accessible Web can also help people with disabilities more actively participate in society.

The Commission is committed to make Websites as accessible as possible to the largest possible number of users including those with visual, auditory, cognitive or physical disabilities, and those not having the latest technologies. The Commission must take a lead in providing an example of good practice in Web accessibility and accomplish its legal obligations.

As a public service, EUROPA is addressed to all citizens of the European Union. It is important to ensure that it is accessible to all audiences and complies with the standards for accessible web design.

In addition to making information easier to access and thereby increasing the site’s potential customer/client base, benefits of Accessible Web design include:

  • Improved usability for all visitors. Consistent navigation makes it easier to find desired content quickly.
  • Clear navigation and clear content supports people with and "without" disabilities: older, low literacy levels, low bandwidth, etc.
  • Providing text equivalents (e.g., ALT attributes and captioning), table summaries, structured mark-ups and metadata improves search engine optimisation (SEO).

Use on EUROPA websites

  • In case of justified technical or practical reasons for not complying with WCAG 2.0, level AA guidelines, the exceptions should be explained in an accessibility page.
  • Existing sites could gradually be improved to conform with the new guidelines if resources are available.
  • EUROPA pages should be designed to work with a wide variety of browsers, devices, operating systems and monitor colour-depths and resolutions.
  • Websites should be developed according to the standards set down by the World Wide Web Consortium and be compliant with HTML 4.01 Transitional and Cascading Style Sheets CSS2.1.
  • When creating a new website:
    • During the content definition phase of the site and the creation of the prototype phase, the WCAG 2.0 AA must be taken into account.
    • During the life of the website, on each update, ensure that web accessibility rules are followed.
  • When updating existing content, ensure that as far as possible it conforms to the guidelines. If this is not possible, explain why in an accessibility page.
  • Websites that comply with 2.0, level AA guidelines, can insert the compliance logo

The Commission has adopted the Web Content Accessibility Guidelines (WCAG) 2.0, compliance level AA, as objective to attain for websites published on EUROPA from January 2010 on.

Until 2009, the standard followed for web accessibility of EUROPA websites has been the Web Content Accessibility Guidelines 1.0 (WCAG), level A (priority 1). Most websites that conform to WCAG 1.0 will not require significant changes in order to conform to WCAG 2.0, and some may not need any changes.

Some top level EUROPA sites already meet the terms of WCAG 2.0 AA level of compliance, and the European Commission continues to move forward achieving conformity for a great deal of its existing sites.

However, in spite of continuous efforts to monitor accessibility, full "level AA" compliance cannot be guaranteed at all times. In case of justified technical or practical reasons for not complying with these guidelines, the Commission will explain the exceptions in an accessibility page.


1.7. Framework contracts

Commission services have concluded a number of framework contracts with external organisations for specific services regularly required. Before launching a procurement procedure, you should check whether a framework contract already in force could be used to make the purchases you need.

Services provided by DG COMM

DG Communication (DG COMM) offers a number of framework contracts and AMI list:

  • DG COMM multiple framework contract
  • DG COMM framework contracts for activities in the Communication fields
  • AMI list for specialised web services

DG COMM maintains also a list of all DGs' framework contracts in the Communication fields.

For further information, see DG COMM intranet for the framework contracts possibilities.

Services provided by DG DIGIT

The framework contracts from DIGIT can offer you the necessary expertise for constructing complex dynamic sites using ColdFusion or Weblogic.
The IRMs (Information Resources Managers) of each DG and their teams are the key contact people from DIGIT in this field. Contact them first if you want to make use of these contracts. For further information, please consult the Framework Contracts page of DIGIT on MyIntracomm. Public information about DIGIT's framework contracts is available on EUROPA.

Services provided by the Publications Office

The Publications Office (OP) know–how is available to anyone requiring help and advice with publications projects (electronic and paper). OP uses framework contracts to produce publications together with external contractors. Directorates-General and institutions can submit a request for a publication which will be produced in-house or with the help of an external contractor. OP advises on technical specifications, helps plan, prepare and manage projects and ensure quality of the finished product, and ensures conformity with the rules governing the use of framework contracts and house style guides. OP has a number of such contracts which can be used to carry out multimedia and print publications projects.

For further information, see PubliCare (services offered by the Publications Office) and the Publications Office internal site.


1.8. Project Templates

The templates and examples presented on this page are a collection of documents which can be helpful in the process of creation and planning a successful website. The examples can be customised according to the specific project's needs.

  • Request form for the creation or revamp of a site DOCmsw8(380 kB)
    This form is required at the very start of the website creation or revamp planning process and must be submitted to DG COMM before publication or signature of any contract. 
  • Concept paper DOCmsw8(211 kB)PDFpdf(128 kB)
    Example of an integral concept paper, defining all aspects and requirements to create a website.
  • Timeline XLSexcel8book(88 kB) Choose translations of the previous link 
    Example of a website creation timeline. The first two parts "Roles, budget, schedule" and "Goals, scope, indicators" are fundamental and preliminary for all the rest - their outcome has an impact on the entire project. The timeline is based on the ideal hypothesis that all the necessary resources will be available at the right moment.
  • Wireframes DOCmsw8(198 kB) Choose translations of the previous link  PDFpdf(98 kB) Choose translations of the previous link  
    Examples of different page level design.
  • Methods to define the target audience DOCmsw8(48 kB) Choose translations of the previous link PDFpdf(21 kB) Choose translations of the previous link 
    Help to find what the main audience of your website will be, based on defining types of user and specific goals for each type of user. 
  • Example of the resources needed for the creation of a small site DOCmsw8(43 kB) Choose translations of the previous link PDFpdf(18 kB) Choose translations of the previous link 
    Example of how to estimate the resources needed for the creation of a small-scale website.
  • Content workflow management PDFpdf(22 kB)
    Comprehensive overview of the content management workflow and its associated approval procedures.
  • Standard templates
    The graphical foundations on which you must base your project. 
  • Quality Control check list
    Help to measure how well a website meets IPG requirements and best practices.