The EYD2015 website: working agile at the European Commission (EuroIA 2015, Madrid)
•
3 gostaram•1,591 visualizações
In the summer of 2014, we partnered with a web integrator to design and build the website for the European Year for Development 2015 (europa.eu/eyd2015), a collaborative platform to publish stories from the field on development and announce events related to the theme year. In a first phase, we created an IA and design for the site. Then, the integrator took the lead and developed the site in agile sprints, with us in support. The website is now running successfully, with many partners publishing stories and events related to EYD2015. In this talk, I share some techniques we have used and lessons we have learned in working together with developers in an agile set-up.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a The EYD2015 website: working agile at the European Commission (EuroIA 2015, Madrid)
Semelhante a The EYD2015 website: working agile at the European Commission (EuroIA 2015, Madrid) (20)
Mais de Koen Peters
Mais de Koen Peters (10)
Último
Último (20)
The EYD2015 website: working agile at the European Commission (EuroIA 2015, Madrid)
- 1. Case: the EYD2015 website 24 September 2015 EuroIA 2015 Working agile at the European Commission @2pk_koen
- 2. Introduction
- 3. The request
- 4. “European Year for Development 2015” — “Design and build the yearly theme site for the Commission” — 2015: end of Millennium Development Goals (UN) — Collaborative platform – list of partners — Launch in 5 months 4
- 5. Basic concept — Main site hook: telling stories! Story (of the week), by DG Devco Stories by partners — Events linked to EYD 5
- 6. 6 Why present this case?
- 7. The project
- 8. Approach 8 End of June 2014 Sept.1 Early Oct. Jan.1 2015 March Framing Classification Concept. Design Visual Design Phase 1 (IA track) Contractual Negotiations Build site in 6 agile sprints Official launch europa.eu/eyd2015 Follow up/ extra features Phase 2 (Build track)
- 9. Phase 1: IA track — Rush start, early summer Framing, user interviews Classification and design workshops — Prototype, rest of the summer Wireframes, visual design HTML prototype 9 Sketchnote by Peter Decuyper (Amplexor)
- 10. Framing — Context map — Personas — User journeys 10
- 13. Cores & paths 13
- 15. ‘Wireflows’ 15
- 16. Style cards 16 “Alpha – closed fields, depth, black-and-white, friendly”
- 17. Deliver ready-to-use front-end code 17
- 18. Phase 2: development track — Developers in the lead — Agile set-up: Product backlog, user stories 6 sprints, 3 releases 18
- 19. Agile sprints 19
- 20. The challenges
- 21. Context of the Commission
- 23. IPG rules — Use of third-party tools and services No Google Maps No Facebook Comments EU tools for Twitter, Social sharing — Web Accessibility 23
- 24. Geography
- 25. Languages — 23 languages Design adapted to this! — “Show results found in other languages” 25
- 27. Have a solid concept and IA — ... have it ready before the first sprint 27
- 28. One or two sprints ahead?
- 29. Visual refinements during the sprints: In photoshop or in the front-end code?
- 30. Role of the front-end coder... — Part of Namahn team, but in close cooperation with developers — Process His work was integrated in the development environment Mix of custom templates and Drupal templates 30
- 31. What about the wireframes: Do you need to keep them up to date during the development phase?
- 32. 32
- 34. 34
- 35. 35
- 36. “what is really nice is the fact that this site was actually launched on time!” (Project sponsor)
Notas do Editor
- Namahn is a human-centred design firm based in the center Brussels, close to the European neighbourhood. I recently worked on a project for the European Commission, and I thought it would be a good idea to share with you some findings from this project.
- Let me start by telling you first what was the request by the client.
- By presenting this case, I want to - share some of the techniques we have used. - Share something Namahn has been struggling with: we are a design company, we do not develop websites ourselves. So where are the boundaries of what a design company can do, and how can designers fit in a development process.
- So how did we tackle this request? Let’s have a look at the project process first
- Here you get an overview of how we have worked together with the company Amplexor. Amplexor is an agency specialized in development of among other things Drupal sites. We took the lead in the first phase, the IA track. Amplexor took the lead in the second phase. In between the 2 phases were difficult contractual negotiations.
- Phase 1 started of in a rush. Basically we had to set out the fundamentals and decide on a basic concept for the site in less than two weeks.
- We started off with a full day framing workshop in which we tried to understand the context for this website, and what they wanted to achieve with this website, who was involved, what systems and channels were involved. We created: - a context map - Some personas - and some simple user journeys related to those personas.
- In the days after the framing we held a few classification sessions: figuring out the traditional IA stuff, a sitemap and an analysis of the important content types, with their metadata and attributes And a content model. (This was going to be a platform for partners to publish their own content (stories, opinion pieces, events...) so it was important to determine how this content was interlinked)
- Then we took first steps towards page designs, in a workshop with the client’s team: we made first sketches of the flow between the pages.
- And we did a cores and paths exercise for the 3 main content types (story, event, partner), and started drawing the first detailed wireframes based on this input. So that were the First 10 days in a nutshell. Then, the project seriously slowed down into Commission summer tempo. We used the rest of the summer to do the detailed design work
- When you look at how the design work was done, there is basically nothing out of the ordinary: We worked in iteration, from first sketches to detailed wireframes and a visual design, as you can see here for the story page There are 3 things that are worth mentioning about our design approach...
- First, we have been creating so-called ‘wireflows’ as a first step in turning your paper sketches into digital drawings. On a wireflow scheme you gather a number of high-level page structures (thumbnail versions of wireframes), and show how these pages are connected. Rather than seeing a single page at time, you can see how the site will respond to user interactions, all in a single glance Such a scheme can be created relatively quickly. You don’t need to fill the details yet. It’s a good basis for discussion with the client, and we have a template to do this quickly and in a consistent way. (A wireflow is a lovechild of wireframes and flowcharts)
- Second, for the visual design, our subcontractor worked with so-called ‘style tiles’ or ‘style cards’ as a first step: these are more like ‘mood boards’ instead of actual page designs, and they help the client choose a ‘style’ or ‘mood’ or ‘atmosphere’
- Finally, our design team delivered ready-to-use front-end code to Amplexor, not a psd! I will come back to this later on.
- After Phase 1, there were a few weeks of difficult contractual negotiations. Then, with a delay of almost a month, the development track started end of September, with Amplexor in the lead. They used an agile approach, with 6 sprints and 3 releases.
- Namahn was part of the Amplexor team and participated in the sprints Namahn’s interventions? Before the actual sprint kick off! So, doing refinements in the design, making sure all decisions are taken. So we are running one sprint ahead
- So what were some of the challenges we encountered?
- The EC is a complex context to work in or client to work for, but also fun! The EU has 28 countries and 24 official languages. Institutional complexity (who is the client): DG Devco, DG Echo (hum.aid & civil protection), EEAS, DIGIT, DG COMM...
- The INFORMATION PROVIDERS GUIDE is a guide with a number of editorial, technical and layout standards for the EUROPA site and EU websites (for web masters, developers, content providers.). Rules set in the IPG are compulsory. So in our case, we needed to work with this “interinstitutional template”
- Geography seems simple: 7 continents and an alphabetical list of countries... Not really The development community doesn’t think in continents, but in entities like “Sub-Saharan Africa” or ACP (African, Carribean and Pacific states) At the Commission geography is politics: whether an entity is a country or not, is a politicial statement. Is Palestine a country? Well, kind of – it is listed on the site, but with an asterisk. What is location? Takes place in vs. Present in vs. Working in (and what does this mean for the search?)
- Have a strong concept / solid IA ... have it ready before the first development sprint. In this case, a good content model, showing how the main content types were related, was really crucial
- Once you enter the agile sprints, you as designers are running 1 sprint ahead. But you can wonder if this is really enough. 2 to 3 weeks can be really short to do all refinements and take all decisions, when you’re dealing with a more complex functionalities. So in some cases being 2 sprints ahead is better.
- Almost all of the visual refinements during the agile sprints happened directly in front-end code, reusing or reapplying existing components, so not in photoshop anymore. The homepage was about the only exception (image wall). But you need a front-end developer who knows how to apply a visual design to new situations
- What was the role and the position of the front-end coder. Part of Namahn team, but he worked closely together with the developers. Being part of our team had the advantage that he knew the designs and the concepts behind it really well His mode of working: His work was really integrated into development environment of Amplexor, so his html, css and js work and updates could be immediately applied to the site on Amplexor’s development environment.
- What about the wireframes? Do you need to keep them up to date during the development phase? Wireframes are just a temporary deliverable, with a specific, temporary purpose, right? So, in our case, useful in phase 1, for initial scoping and page structures...
- You could say that during the agile sprints, all design changes are directly implemented in html prototype that is available and not in the wireframes anymore, but still we decided to keep them up to date, because they were a crucial communication tool! For the client, it is more comfortable to have them up-to-date – they were more complete than the html prototype As a point of reference for the developers: Amplexor worked with a sub branch in Rumania (Amplexor Rumania) and that team had not been involved at all in the workshops and discussions during phase 1. So yes, it is double work to maintain your html prototype with actual front-end code + your wireframes, but we did it anyway.
- Another lesson learned: towards the end of phase 1 and during the contractual negotiations, we found out that gathering and streamlining all comments and requests from the client without appropriate tools is very difficult. We mainly use Office tools like Excel
- But once Word gets into the picture as communication tool for feedback. You can reach whole new levels of feedback-giving: you can work with track changes, highlighting, colouring text, comments... At the start of phase 2, Amplexor introduced a number of professional tools that streamlined the functional discussions, feedback streams and the follow-up process.
- In this case, the detailed specifications in a confluence WIKI, and the development tracking in Jira (product backlog). Conclusion: You a systematic specification and follow up process, with dedicated tools. The closer we as designers get to actual development, the more we will have to get familiar and learn to work with their tools. This is inevitable.