Open Corporate Website Project

Written by Sitra.fi development team: Ylva Fredriksson (Fröjd), Mikko Kiviniemi (Deasign), Jonas Lundqvist (Fröjd), Karoliina Luoto (Sitra), Patric Nordmark (Fröjd), Mårten Norén (Fröjd), Janne Toivola (Sininen meteoriitti) and Kerkko Ulmanen (Deasign).

What Sitra.fi project has been about. We have been trying to do a to-the-point website in a sustainable, non-crappy way. This has meant

1. having a capable team whose every member is aware of the project vision and objectives and is allowed to think of the best possible solutions for the objectives 
2. having the possibility to gradually understand more of the project and the outcome and utilize that growing understanding in the development work (scrum)
3. taking care of instant and genuine use feedback for concept and development work
4. sharing the outcomes and learnings so that other organizations and projects could also utilize them

The project is now at the point where the 1.0 toolset starts to be ready and is now published to beta.sitra.fi. The emphasis will now turn from the development team to the content producers in Sitra end for content development before the actual launch of the site in December.

What we think we have accomplished in the development project. Now when the Sitra.fi toolset starts to be ready, it feels like a genuinely coherent website. The site is all about summarizing information and gathering together the collaboration around it, and it feels like we have gotten together a unified-visioned toolset for that.

We have gotten in user feedback throughout the project. The first beta version was published just after a month of development work, and we have all the time gotten feedback from teams actual working with the site tools with their networks. Other sources of feedback have been user surveys, a named user panel and Sitra empolyees generally. It has been hugely useful feedback, and it has made as think again several different features. This feedback has gotten the 1.0 site much nearer to the actual user needs than usually is the case in our experience.

A couple of things we were emphasizing in the development work:

• HTML5
• Responsive design for genuine mobility
• Quality for code for longer-term developability

Stuff that were needed in order for the project to work. This project could not have worked without:

• An experienced team that are confident about their professional skills
• A procurement that concentrates on people and their skills
• Everyone’s 100 % dedication to the project, in terms of time and spirit
• Product owner (customer side representative) that is well attached to web business and also has time to work as a part of the development eam on daily basis
• A bigger budget than in an ordinary website project, because the idea is to revisit stuff along the growing understanding and to also share knowledge and these both take time
• Ongoing communication between all team members to keep everyone up to date and focused, both virtual and IRL meetings

Tools. Mail as a way of communicating within the project was banned early. Instead we decided to use Basecamp, a web group working tool. For the daily scrums and day to day communication we used Skype.

In the beginning we also used Pivotal tracker, a web tool where you can keep your backlog and manage your sprints. We only used for the initial spints but felt it didn't work for us. The main reason for this was not the tool in itself but more of the way we used scrum. Back then we kept the design and developer user stories in the same sprints which didn't work that well. Most of the design tasks were simultaneously macro and micro perspective so the Scrum idea of taking these apart into mandatory small chunks seemed unnecessary. We decided to separate design and developer tasks. Developer tasks were time estimated and added to every sprint following the normal scrum rules. Design tasks were also added to the sprint, but were not time estimated. These design tasks were added as todo lists in basecamp. To avoid having information divided in two different systems we decided to also move the developer tasks to Basecamp.

Basecamp has been a most valuable tool used for all project related work, such as the scrum backlog, sprint lists, design, wireframes and general discussions. Basecamp may not be the best tool for everything, but the advantage of having one single source of information is worth the disadvantages. During the project we have had members coming and going. For them it has been easy to get into the project and find the resources they need. Since everything beeing decided and done has been added to basecamp it will also be an invalueble source for the future where you can find information about almost all features of the web site. Why and on what grounds some decisions were made, how design and wireframes developed throughout the project.

Stuff that felt tricky. A couple of project areas have not been easy.

• The budgeting. Budgeting was done well before the project was started, and it did not well enough have the ideas of iterative development (=revisiting stuff) and the work for sharing learnings within. So we ended up revisiting the budget during the project.
• The developer - designer co-work. Even though we aimed at one unified team, the design and development parts of the team have not worked together as seamlessly as they could have. We tried to solve this by focusing on having three different timelines for design work: future (long-time vision), next sprint (design for the actual solutions agreed on by the team) and ongoing sprint (making the small stuff needed ad hoc and testing and editing the developed features). Despite of the try, we did not get the flow totally working.
• The steering group work. It felt like in a multi-objective project like this, the steering group work is exceptionally demanding. It requires high involvment from the steering group members to stay up-to-date even about the major decision points of the project. In busy everyday working life this seemed quite hard to be arranged. The nearly-working practices we ended up with were a weekly project digest (numeral data of the scope - budget progress and top 3 project issue list) combined with a monthly meeting added with needed one-to-one discussions.  

Procedural lessons from the project. This is stuff that the Sitra.fi project members will definitely do in the future too:

• Constant and integrated feasibility and feedback loop between design and tech. Saves a lot of time and money, keeps the team more unified and creates clear goals for everyone to achieve.
• Bootcamps. If the project team is spread over different towns or countries, it really seems to speed things up to have some mutual working days on testing stuff together and finding mutual solutions.
• Goals. Vision of course frames the overall goals for the project, which splits into sprint goals (the amount and scope of backlog items to be implemented inside the sprint). In addition to that, the team has had quality objectives, in our case have been: use help, try instead of speculate and contribute to the web community.
• Rewards. Having a team reward for accomplished goals (mutual experiences instead of money) felt beneficial for the project.

Conclusions. Based on the team wrapping-up discussions of the project phase, the gains from using scrum and user-centered methods had generally felt better than the usual project methods the team members had used. Main reasons for this seemed to be the possibility to combine the team members’ skills for better results and the chance to contribute to different project aspects. Also it felt that the explicit aim for sustainable, easy-to-further-develop site increased motivation in the development work. However, it felt like the methods we used are not for every project, since they require much commitment and investment from all the stakeholders.

PS. If you want to get a headache, look at the wonderful gif animation of the project team members :)

About the writer: Kerkko Ulmanen has worked as a graphic designer - or art director - in the Sitra.fi project. He has been working tightly together with Jonas Lundqvist, the front end developer, and Mikko Kiviniemi, the concept designer.

Art Director (definition):
Person with superior vision of design and complete, undisputed understanding and opinions of everything design-related.
(Source: Art Directors)

In reality, carrying out the approach of sending “finished” designs over to Technical Company X™ and simply crossing your fingers, usually gets you an end result of a whirlwind of compromises and trade-offs that neither part of the process can endorse.

This is a practice I learned to ax off during the Sitra.fi project. Taking feedback - especially on an early design - can at first feel unfamiliar and uncomfortable, but looking at the end product this was definitely the way to go. There is no doubt in my mind that the site we are about to launch is - although different from the initial sketches - a much more well-thought and functioning entirety because of the close teamwork with our developing magicians at Fröjd. 

It was crucial for me to follow-up on the implementation work, both for understanding the reasons some features were eliminated due to technical purposes, and to be able to suggest new solutions when problems arose. In 2011, it isn’t enough that a design looks good, it needs to adapt to needs of the development. Building a sustainable design means not falling into the potholes of latest gradient direction or corner-roundness. It means co-operated visual guidelines that offer the end user stability - a trust that the sites design will work consistently. 

One of the first decisions I made for the design of the new Sitra.fi was that content would be king. The framework around it would mostly serve a guiding, info-driven purpose. This kind of streamlined simplicity - especially when working on a multi-platform user base (we also went responsive with this one) - makes the need for sticking with a few set of strict rules even more important. 

After this project, my three rules of design to follow would be:

1. Set up guidelines - and follow them.
2. Get feedback from people you respect, and respect the people who give you feedback.
3. Don’t settle. Compromise is the death of innovation, so find solutions.

Thank you to everyone who shared my vision on the design during this project, and an even more special thanks to those who initially didn’t.

 - Kerkko 

About the writer: Janne Toivola has worked as a co product owner in the Sitra end in Sitra.fi project. In practice he has been the client together with Karoliina Luoto, concentrating especially on the team-end co-work and testing, webdesign and analytics questions.

I didn't really understand what I was getting into a year and a half ago when I was writing an offer for the project management consultant's job for Sitra.fi website renewal project. A lot has happened since and now that things are closing to an end, it's a good time to evaluate how it turned out to be.

It's been an exceptional project for me in many ways. I have never been to an agile project of this size, and I've since got to appreciate the many good effects agility can bring. It's not a silver bullet by any means, or without problems, but done right agility can have a huge positive effect on the end results and especially on the mental health of the team members.

The philosophy of the project from day one was that web site projects don't have to suck. The project proved us that that it is possible to honestly enjoy working hard in a project and get good results. Doing the project at times didn't feel like working at all, which is quite remarkable considering the amount of hard work that's been put into it. I guess it just feels more meaningful, motivating and rewarding to put your effort into a project when the aim is all the time to build value, not code.

One of the challenges in the project has been that the team was divided into two countries and multiple locations. We realized early on that this is something we need to actively fight against and try to ensure good communication in other ways than physical presence. Despite the distance, we still managed to have (almost) daily scum meetings with the whole team via Skype video conferencing and we also sticked with the plan of having the review/planning/retrospective meetings with the whole team in the same physical place. We were also using Basecamp heavily throughout the project for all project documentation which worked great. Still it would have been so much better to be able to work more in the same physical space, but it wasn't a huge problem for us after all.

The biggest difference for me in this project compared to a more traditional fixed scope+budget project was that when all the things that the customer asks the team to build actually generate costs right away, you are forced to think of the value of all the tasks more carefully. It's still difficult to pick the most valuable tasks, but the conversation starts rolling around the right questions - instead of arguing about whether this or that is part of the deal or not, you actually find yourself thinking how much value this brings, is it worth the investment or is it more important than some other thing on the list.

The project really taught me a lesson on how little the customer really knows in the beginning of the project. If we'd have been forced to make all the decisions in the beginning of the project the end result would have been something totally different. Many of the things that seemed important in the beginning turned out not to be and in turn there were tons of other stuff added to the list that we only begun to understand after seeing the feedback from the end users and Sitra personnel and after starting to understand the potential of the CMS etc.

A lot of the project was put into making the site update process as smooth for the Sitra employees. That makes sense, as the site is only as good as its content which in turn will never be good if the users don't feel comfortable updating the site. I'm really proud on what we accomplished there, and hopefully the investment turns out to be a good one and the contents are going to shine.

Good atmosphere we had throughout the project was of course also due to the great people in the project that I've had the pleasure of getting to know and be friends with. Going to miss you all!

About the writer: Patric Nordmark is one of Sitra.fi developers. He has been doing development together with Jonas Lundqvist and Mårten Norén. Patric joined the team during spring 2011.

I would love to tell you about all the things I learned from this project.
Unfortunately I can't right now, because I don't know about all of them until I get some more perspective.
However I do know that I have learned A LOT and will tell you about the ones I managed to figure out so far.

For me this project method has been something quite new,
I have never worked this close with the Product Owners in an agile project before.
To me this was an eye opener that the key to a successful scrum/agile project is to have a tight unit working together.
And also that the borders of Scandinavia should be no hurdle for doing so.

The team didn't have any loose ends. Everyone involved in the team,
from Product Owner to Project Manager to Developers and Designers has all been attending the daily scrum meeting every morning, creating this tight unit.

Drupal, the technical framework, I feel like we all have learned a lot about from working together and sharing
our experience about the dos and the don'ts, the limits and the possibilities.

The agile method some times adds development time.
But not only in a bad way, It does so because it enables you to revisit and revisit parts again until it is perfect.
When working with bigger projects like this, I am sure that this yields a much better quality, more thought through and more tested end product.

To sum it up, this project overall has been a really good experience for me.
I gained knowledge on what I want future projects to look like,
created a great website using new techniques,
and made some good new friends along the way.

- Patric Nordmark, UI Developer at Fröjd

Here are my thoughts on the project so far!
 
Value (customer, companies involved, web community, end users)? — One of the key benefits has been the transparency, as we have shared so many learnings and results to the web community at large. I think that both the customer and vendor (what we combine as “us”) have proven that the symbiotic and agile method for reaching results is really superior to the more traditional client/agency method (of course taking into consideration the level of web know-how from the client). The added emphasis on the administrative side is also unique in this day of readymade CMS deliveries.

What do we tell others? — About the benefits of quick prototyping in a project involving a lot of actual interactions (more than just browsing flows on a marketing site).
How to work virtually with members scattered around to acheive the best results.
Be transparent to help out the bettering of the web community as a whole.

What feedback have we gotten? — From the get go the concept presentation received a considerable amount of attention within the digital scene, even leading to meetings with traditional agencies in cooperation possibilities.
Also, the agile work we've done has been referenced in meetings with possible clients with very good feedback.

Personal wins? — Steering the design in a fairly early phase into the mobile first/responsive design discipline. As it was done in such an early phase we didn't really have redesign anything or change code, saving time and money.
Very thoroughly tested and quite advanced, intuitive admin UI for future development.
Seamless workflow throughout creative team and combined whole team.

Top 3 personal learnings? — Cater to the future of device agnosticism with responsive design.
Creating prototypes of working interaction models that are thoroughly user tested before any design is done.
Constant technical feasibility feedback loop during interaction design to reduce redundant work.

What are you taking to future projects? — The personal learnings have already been put to use in all larger projects I will be working on. Right now, we're going to work with these learnings in the TallinkSilja website renewal project that has started.

Learnings on cooperation (cross discipline, cross country, cross tool)? — Proof that cross country, virtual, remote collaboration does work and is efficient. Inthegrating design and tech with constsnt feasibility and feedback loop. Proving the worth of a tool as Basecamp to collect ideas and materials in one place.

Thanks for one year of brilliant work!
-Mikko

Actually, this is a co-posting by Marjut Mutanen (user research findings) and Karoliina Luoto (answers).

Throughout the sitra.fi project there has been a user panel helping us along the way, giving comments and critique, and participating in usability and concept testing. That has been great!

The latest usability effort took place this summer, when we made a questionnaire asking feedback on the current beta.sitra.fi site in order to use the finishing project-stage development work in August - September wiser. We also got some help from User Intelligence in form of a usability review. Results rarely are a surprise, and that was not the case this time either.

According to the users, there are three major areas which we still need to improve:

1. Layout. Some might say that the layout is merely a matter of taste, but it does in fact have an effect on usability, too. Aesthetics is a big factor when considering how pleasant it is to use a website, or a product. In Sitra's case the layout did still feel unfinished and not as "wow" as the users had expected.

   A: We are hoping that this is mostly due to the fact that we are still in beta and visuality needs lots of finishing touches before it feels ready even for the team members. After we get the first full site out, the survey will be redone and then we see if we need more vast revisions.

2. Content. The pages are too long, the users complained, there is too much text. Some of the content is still missing, too, and some is difficult to find.

   A: Here the users pointed at a central and difficult thing. Expert organizations' content is easily text (long difficult text) centered. The change towards more summarized, easy-to-understand and even visual content is a long path and we are just taking the first steps. But not giving up, hopefully.

   Obviously there is content missing in beta, and we'll add it up during the autumn before replacing the old site with the new one. However users not finding content is a more severe thing. We are hoping that it gets solved when we add a content archive, search and two-level navigation. After 1.0 release we'll need to ask the users again whether they still bump into findability problems.

3. Navigation. Navigation could easily be the most critical thing on a website, and thus any negative feedback on it must be taken seriously. If the user can not move around the site without feeling lost, and not find his way back or forward, the site is pretty useless.

   A: Touché. We certainly hope that adding two-level navigation (as planned) and breadcrumbs (new thing based on the feedback) to the full version solves this problem. If not, we'll need to do some serious re-thinking.

Sitra.fi project has been a wonderful trip so far. Devotion, ambition and playfulness have been its top qualities by which we have in many aspects obtained even more than we wished for. Recently the course took an interesting turn when after the intensive beta launch work phase (for results see http://beta.sitra.fi/) it was noticed that budget situation is pretty problematic before the 1.0 launch.

Here’s what I would next time do differently throughout the project:

• In an agile project budgeting should be iterative too. If a preliminary analysis is done in the beginning of year 2010 and the budget is sketched then, it’s bold to assume that the guess would still be accurate in mid 2011. Many of the project aspects have gained resolution and some work phases have lasted longer than originally thought, and so the budget should be genuinely revisited too.
• Budget follow-ups should be a fixed part of steering group work. If there are almost 10 people working for a project, even monthly reviews on the budget realization can be too slow.

After thorough discussions the steering group of Sitra.fi project decided that the project will be still taken to the 1.0 phase without radical changes to the existing agreement (time and materials agreement). The following changes were however planned together with the development team and agreed on:

• The budget visibility and responsibility is shared between Sitra and the Fröjd/Deasign development team. The time usage per person per sprint is agreed on before the start of the sprint and it is reported weekly against the product burn down chart.  
• Good enough quality for durable further development. So far we have been pretty ambitious on finding the state-of-the art solutions e.g. for genuinely mobile accessibility. As there are now only a couple of months until the 1.0 launch, we will build on the found solutions for a moment and just focus on getting things done.
• Answering feedback – the most important one. Roughly 1/3-1/2 of the overall workload in the project has been about answering user feedback, and this has been really important for getting the right and sustainable product. In the next couple of months we will however prioritize the feedback heavily and focus on the conceptually essential notices and severe usability issues. Also part of this is that we are merging the product owner feedback. Instead of having two PO-persons in dialogue (which has in the other hand added quality), now all the acceptance testing and product backlog management goes through one person.
• Taking the steering group work to more concrete level. So far the role of the steering group has been quite distant and philosophical in the project. Now the group will be used for weekly surveillance and all trickier decision making.
• Size of the backlog is locked. We trust that during the last 6 months we have got a good understanding on what the 1.0 launch should include. However, because thoughts do develop and we need the ability to response essential feedback, every sprint will contain 10 percent of flexible workload that can be addressed to whatever decided in the sprint planning.
• All user stories have specified requirements and definition of done defined to them and every started sprint is locked. This may seem self-evident but has not been that in the hectic everyday life of the project. Also sometimes the need of answering some user need immediately on the beta site has felt unavoidable even during a development sprint.

• Finding the witty alternatives together instead of working more. When the responsibility for the outcome is emphasized, it could be easy to slip into trying to work harder. Instead, we need to still think co-configuratively and find the witty, economical solutions.

 As the result of the intensive thinking work I think we obtained a new phase in the project, and this could all even lead to a more streamlined website if we use the opportunity wisely.

Media query

The number of different devices people use other than the computer to browse the web increase every day. It was clear from the start of the Sitra-site-project that mobile users where an importent target group. Most of these users would expect a mobile version of the site. Creating a mobile versions is tricky because there is a tremendus amount of resolutions to handle. It has also become a standard to provide landscape/portrait mode for mobile phones. Ipad, Google tablet, future devices not yet available on the market etc - also point in the direction that there is no dynamic or safe way to display a site depending on the device currently in use.

Instead of aiming at the device, we have chosen to adapt the page depending on screen resolution. Detecting screen resolution can be tricky as well because the resolution might change without the page being reloaded – if the user tilts the phone or resize the browser etc. According to many discussions - some listed below - the ”Media query” is suggested as best practice to deal with these issues. Media query provides us with the perfect tools to handle screen resolutions and does not have any dependencies on JavaScript nor back end processing – pure css.

The downside of Media query is that it's only available for modern browsers. Basicly all smartphones support media query though, and for those who doesn't the default – desktop - site will still be provided.

How does it work?

Media query may apply different css styles if screen resolution arguments (max/min resolution) has come true. The changes are instant and a user will notice the switch while resizing the browser window. Any Css can be added or changed but most common is to chang the layout of the page. Html pages are typicly divided into regions (in the sitra project we use drupal panels to divide the pages). These regions can be rearanged and adopted to the current screen. The left sidebar typically moved below the main-content region for users with narrow resolutions.

When regions is moved around it usually means that they also are rizesed as well. For pixel prefect design this can be a challenge. Providing flexible design that is dimension independent has become even more relavant with the Media query approach.

Some links that can be of interest

http://www.alistapart.com/articles/responsive-web-design/

http://mediaqueri.es/

http://www.w3.org/TR/css3-mediaqueries/