Designing Well for The Web in 2017
Indigo Tree are keen to make sure we integrate well with our design teams. We’ve been working with some of you for many years, so we know the pitfalls that can arise for designers as well as developers working together on web projects. To reduce these issues, we have produced a resource that we hope will help us communicate better with our esteemed colleagues.
Are you a designer or developer? The way you answer that question comes loaded with perceptions of the way someone views colour and shapes, or how someone has ideas about data and mathematics. But in reality, we’re all human. We’re all creative in our own ways, and we all (to some degree or other) like to categorise and structure information.
At Indigo Tree, we like to reduce distinctions between these two disciplines where possible so that we communicate better. If we work to achieve this, projects should run smoother and more cost effective, without designers feeling let-down over misunderstood expectations, or developers feeling frustrated over a (real or perceived) lack of understanding.
Bringing it Together
Has a developer ever built something on a site that you didn’t get to see until the project was live? Did you feel frustrated or let down because this wasn’t communicated at the outset?
I’m guessing that there will be distinct reasons why the developer would have built that piece of work. However, was that communicated to you as a requirement before that project started? That would’ve helped you to think about how it should look, wouldn’t it?
When we’re working together on a project, the worst thing that can happen is that ambiguities creep in, mount up, thoughts aren’t communicated, and so opportunities for closer collaboration are missed.
“Hell is other people’s undocumented assumptions”
Often, there are certain pieces of functionality that a website has by default. For example, if there’s a blog section on a site, then it’s essential that users can find older posts easily. So we build into projects a way that users can access this what could be critical information in a way that is familiar.
But what if the project budget doesn’t allow you to spend time designing out a unique archive page, or whatever has been made that you didn’t know about before? How can developers not betray the trust designers put in them, and yet not let essential user goals go un-designed?
Enter the style guide.
Style Guides – Design Everything
Style guides are a great solution to this problem. They allow you to stipulate some key elements like colours, typography list styles, buttons, tables and pagination. This way, when the developer knows he must build some piece of functionality, he can refer to this page, and make an informed decision, instead of a wild guess.
Above：An excerpt from an example style guide that you might include as part of your design
Once they’ve been designed, these elements can then be re-used across the site in different contexts, bringing great design to all aspects of a project without leaving developers guessing and designers in the dark.
Designing With Elements
The style guide approach does mean a bit of a mental shift: it means we’re primarily designing elements instead of pages. But as designers, we’re already doing that.
What, you didn’t notice that you already were?
Certain elements we design are already re-used everywhere on a site. A good example of this is the main header and navigation bar: users expect this to be the same on every page. So this is a good example of a reusable element that we would only need to design once, and yet it appears on every page.
Other elements only appear in certain contexts: For example, we mentioned that blogs should have easily-accessible archives. This can be displayed most easily in a list format. So the developer can look at the provided style guide and use that to format the list.
Once they’ve been designed, these elements can then be re-used across the site in different contexts, bringing great design to all aspects of a project without leaving developers guessing — and designers in the dark.
Later on, a user might want to include a list in a blog post. The same design element can now be used for the blog content area.
A Foundation for Better Collaboration
The web is no longer what it was. It can now be accessed by mobile phones, tablets, TVs and game consoles. By providing a style guide and trying to think in terms of elements, we’re bringing our design skills to the whole project, not just to part of it.
We’re working faster and smarter, in a more collaborative way. In a way that will reduce frustration and friction, and bring better results for our clients and end users.
We look forward to collaborating more closely in the future.
