I think we all agree, styleguide driven design with front-end development is a great idea to overcome complexity and reduce the (highly artificial) barriers between design and development teams within agencies.
There is however, a small problem. Although most people can see the benefits, it seems that others only see barriers. Either to good design or how they are used to working.
(It’s important to note that Alla Kholmatova gave a fantastic talk at Responsive Day Out 3 which got me thinking about this in more detail and some of the solutions to the problems come directly from Anna. Thanks Anna.)
Over recent months I’ve tried to look at the main objections I’ve come across from other people’s perspective and they mainly fall into three areas:
- Chicken or the egg – Or where do I start?
- The joint hardest thing in computing – Naming things
- So now what? – What do we use our styleguide for?
I’m hoping that after covering each of these hurdles we can move towards a process that, at the very least, feels comfortable for most people on the team.
The chicken or the egg? – Or where do I start with styleguides?
The current situation
One thing I’ve come across in a variety of teams is this scenario:
- A developer comes across this process and sees that we should be focusing on creating a (relatively) predictable UI primarily based on smaller units than the mighty page
- They then take away that designing whole pages is futile
- They get other developers on board and they see the benefits the approach could bring
- They take it to the design folks (where they are a separate team)
- They discuss the benefits
- It ends there
What I mean here is that by going to sell this to designers whilst focussing on ditching page based design we developers are attacking the current way of working as backward. Now regardless of whether this is right or wrong, how can we persuade others to go along with something new and exciting if we focus on ditching how they currently work.
More importantly, they could see it as an attack on good design. Why? Because how can a designer truly judge whether their typography, buttons, colour scheme amongst other things are actually working well together if they have to start by focusing on the small details? Unless they are genius, they probably can’t. Some knowledge and creation of the big picture is actually necessary to come out the other end with a good end product.
So, although this seems backward, some work on large chunks of pages actually needs to happen first. Before the opportunity to spot potential patterns to be reused can happen. The alternative is that the finished product is sub-par and the styleguide is blamed, never to be used again.
The way I see it, the signs that a design is styleguide based should not be that it looks disjointed or doesn’t look visually appealing. Instead the best indicator should be the consistency of design. Surely that’s what both designers and developers want?
The joint hardest thing in computing – Naming things
So we all know that naming things in computing is generally quite difficult. It could be argued that in UI development naming things may actually be the single most difficult thing.
As ridiculous as this sounds, it takes more effort than feel right to find a name for a component which won’t become obsolete within weeks and yet also makes sense to someone using it.
What most people do
The simple solution which most people reach for, is to name the component after the content it’s holding. So if it holds a special offer .special-offer, if it holds a promoted product or item .promo.
Where that leads
It has to be said, this method wins hands down when it comes to speed. You’ll have added classes to the necessary markup within a minute or two. However the biggest drawback to using it is that the current designs may well only show it being used one way, however there’s no guarantee that it won’t be used for totally unrelated content in future.
An example. Let’s take that .promo component we mentioned earlier and presume that a new design shows it being used for something not specifically promotional. The person who has to implement this new usage sees what they need to create already exists and so go to use similar markup with the key classes to pick up the styles. But they see that the class is named .promo. Now they have a choice to make.
- They can just carry on and use the .promo class
- They can create a near duplicate of .promo and name it (this is the worst of the three)
- They have to refactor .promo to make its name more generic whilst not causing problems where it’s already been used.
Now, option one is clearly the easy option. But we already took that in the first place and it’s what’s led us to this awkward situation. Let’s discard it. Option two is bad on a few levels, particularly the duplication and inevitable pain that will bring in the future. The third isn’t too attractive on first site, but it’s probably the least bad option, bit the bullet and put a little bit of work into avoiding further trouble in future.
How to avoid all of that to begin with
The reason we got into the that situation was a lack of time spent up front in naming our components. I’ll cut to the chase with the solution. Get as many people as is reasonable (I’ll leave that to your discretion, but try not to do it alone) together and look over the visual designs (this presumes you have already marked out potential components).
Now talk about the component and try to come up with a name that works for you as a group. Think carefully, as the name should ideally be used by anyone who works on that project from now on. When you agree on a name that is generic enough to withstand different uses, yet has enough meaning to all of you, you’ve hit on the right name.
One small note here. Within an agency environment, you will likely come across similar looking components from project to project and so you will find yourself having to come up with entirely new names for components less and less as time goes on. By the way, this is a comment that of course the same influences are going to effect projects which are created in a similar timeframe, not that agencies all churn out similar looking websites.
So now what? – What do we use our styleguide for?
Earlier on, I mentioned that when naming your components you should try to come up with a name which anyone who is going to work on the project can use. Why? Well, without a clear and common name for the components you’ll run into long winded descriptions when a colleague wants to discuss the component in question e.g. “The thing on the left above the heading” as opposed to the “feature element”.
One of the unexpected benefits of putting effort into using a styleguide is that it enables everyone to communicate using a common language. All stakeholders will know enough about the components to be able to discuss ideas with each other. Why would we want to stand in the way of clearer communication?
To improve the UI
The true reason why so many people are keen to use styleguides in their workflow (apart from them being shiny and new) is to help designers and developers spot where highly similar components are being used and then discuss if that is necessary, if it is we simply define the modifications to a core style that should be implemented. If it isn’t then we’ve just saved ourselves time working on something that wasn’t going to add any value allowing us to spend time on the things that matter.