Constantly changing web
Last week Adam and I went to the web is… conference in Cardiff. I would like to share my notes from Nathan Ford who was one of the many speakers.
We are constantly online, the web is constantly changing. We are surrounded by constant changes. In his talk, Nathan Ford tried to answer his own question: “How to design for constant change …and not go mad”.
Nathan compared the web to a monster [more precisely - a cookie monster]… So, this is a summary of what works for Nathan Ford [and his team?].
There are three structures:
Team (the resources) - we need to work together. Collaboration is vital.
Project (how to run a project, embrace changes)
Design (at first - it’s all dark - it is quite hard to define what the design should be)
Teams. Quite often teams look like the following:
Make the client the rest of the team. Make the client involved. You can find the “champion” at the client’s side - it would often be the person you are in touch with… If not, it would be the person in charge of the project, someone who knows a lot about it.
Involve stakeholders - this way they are aware of what is happening throughout the whole life of the project. This means that they will no longer come to see the project in 6 months and want to change everything… you’re protected from blame and the client is happy.
No surprises. No blame…
Embedded teams, shown in the image below mean that the client is closer, they are involved at all the stages (especially the “champion”).
Project management for constant change
There are these wicked problems - problems that are almost impossible to solve/fix. Treat projects like wicked problems.
Not done, better (never finished) [not sure what that meant?]
If unsure - try everything, try out a lot to see what works
If something doesn’t work, don’t force it (reject it), but try to explore an alternative (move on)
If it does, explore it further
It is OK to fail, but one must learn as a result. Failure is not the objective, it’s not good, but when it happens, learn from it and move on.
Do the projects the agile way not Agile [“agile” is not scary while “Agile” is].
Work in sprints… Start with sprint 0 - that’s where you bring the client in, involve them from the beginning, gather all the required information, etc. You then keep the client involved at all the stages of the project.
Also a good point was made - doing agile doesn’t mean you cannot adapt it to suit your company’s needs. I agree that we should do what works for us and not follow some rules to the letter.
Embedded teams mean that communication is easy - ask the client for feedback (it is easier to do if they are a part of your team).
User stories - these should be written by the client not by you - organise workshops to educate the client, for example.
Prototype early (as soon as possible) and give the client access - so that they can give you feedback.
Use style tiles and let the client know if these change, too. Also, make them aware that they are likely to change in due course; they’re not set in stone.
Sprints structure (doesn’t need to happen in this order, but should contain these elements):
The above might not be easy/desirable for you to do, because you will be sharing unfinished work with the client. Still, it is better as they will be more involved from the beginning of the process and can provide feedback early.
RWD (responsive web design) process
Start with content
Work with the constraints (not against them)
Use a grid system - define the grid for the given content. There are many grid systems, for example Gridset or font based grid systems. For more information about using gridsets)
Finally, a suggestion for the CSS units which work well for Nathan and what they are used for:
Percentages - for most of the things
VW, VH - for the headlines (better control over the type size relative to viewport size)
PX for media queries
- Em, ex for type and max-width