Ever wonder how websites go from initial design to code? What steps and tools are involved? What are the common pitfalls and how can you avoid them? In this blog post, I will recap the process our designers and front-end developers take to when creating a new website design for our clients. Hopefully, this will give you a little more insight into Mediacurrent’s methodology and in turn help you develop a more robust workflow of your own.
Build the Foundation
Before design even begins, there are a few key items to set the project up for success:
- Track tasks
- File sharing
- Establish common nomenclature
Track Tasks
Choose tools to track progress on tasks. This is generally a task for the Project Manager, but it is important to set up a place for the whole team to track progress, share notes and alert other team members of potential issues. We primarily use JIRA for tracking progress on tasks.
File Sharing
Start a shared space where designers, front-end developers, and project managers can see the design, assets and updates. There are a number of tools like Dropbox or Google Drive that are ideal for this.
File structure is also important. In the shared space it might make sense to have subfolders for things like:
- Sketches
- Wireframes
- Presentation docs
- Design
Establish Common Nomenclature
Discovery is a great time to name things. A key part of communicating effectively as a team is to use the same terminology. Use agreed upon nomenclature the team and client can reference. The earlier in the process the better, especially when you are in discussions with the client.
Initial Design Phase
Effective design workflow during the initial design phase includes:
- Open communication
- Create component lists
- Component breakpoints
Open Communication
It is important to name pages and components as early as possible, ideally during the wireframing stage - but often designs change, even after client approval. Be sure to have a way for everyone to know of the changes. We often use dates or version numbers on our files, to indicate which files are the most recent.
Create Component Lists
Keep a running list of assets and sizes for each component. It is easier to make this list during the design phase, then to have to go back and try and remember it all. Provide detailed specifications to the front-end developer up-front, so that they have something to work off of from day one.
Component Breakpoints
Wireframes can be an essential tool to further discussion about the behavior of each component at the different breakpoints you are targeting. If you have the time/budget, be sure to include designs not just wires. Even doing this for one or two pages can help the front-end developer tremendously.
Design Handoff
While working on the design there are a few things every designer needs to keep in mind:
- Design specifications
- Component features
- Know your assignments
Design Specifications
Provide specifications that the front-end developer can use to build components. The more detail you provide to the front-end developer early on, the smoother the process will go and the fewer questions you will get later on. One thing to keep in mind is that your specifications may need to change at different breakpoints. Providing structure is great, but you need to be flexible as the design is translated into code.
Component Features
Communicate about the component features. One thing to consider when handing off design is that flat design files do not address everything. Be prepared to do a write-up or have a meeting to discuss the features of each component that might not be obvious from just the design files (ex. fixed site header section).
Know your Assignments
Know your assignments when it comes to asset creation. Who is responsible for creating the visual assets for the site? It could be the front-end developer or the designer. In some cases, especially with branded assets, the client may be responsible for deliverables. The important thing is to assign responsibility for these tasks up front.
Component Driven Development
Some key advantages of using a style guide as a design tool include:
- Manageable components
- Less development time
- Easy to share
Manageable Components
Much like building a house out of legos, where you build the foundation first, then add walls, windows, and a roof, you use a style guide to build a website piece by piece. By thinking of the design as components (or pieces) it is less overwhelming when you are developing. With a style guide, you are essentially reverse engineering the design.
Less Development Time
Another great thing about style guides is they make the development process faster and easier. You can even recycle pieces of old components to help build new components.
As a bonus, when we build style guides for Drupal 8, the Twig templates can be used directly on the theme layer. The style guide markup essentially becomes a single source of truth for the final theme.
Easy to share
Clients love style guides because they get to see the design in action, not just theory. The style guide can be a useful tool for finding design issues, testing the responsiveness of a component, and identifying how all the components work together on the site.
Design Adjustments
While the initial design phase is complete, the job of a designer is not. This might mean reviewing the style guide build, answering a front-end developer’s questions as they arise or even identifying components that were not addressed in the design phase. Style guides are useful for design, in that they can be used for:
- Quick changes
- Testing responsive designs
- Adding new features
Quick Changes
In website design, the designer cannot anticipate how a component or page will look in all scenarios on all devices. The more visibility the designer has into the components as they are being built, the better. There are always going to be gaps. Coding a design out in a style guide allows for quicker changes than on a live website.
Test Responsive Designs
In addition, responsive designs need to be tested in the real world. Since a style guide is actual code, the components can be tested in different browsers and across different devices before the website goes live.
Adding New Features
Further down the road, the client may request new features. Again, the style guide could prove handy to identify the building blocks that are needed to create the new feature, without disrupting the live version of the website.
Summary
- Build a Foundation - based on communication using tools like JIRA and google docs
- Initial Design Phase - Share designs and assets early and often, making sure all team members are on the same page. Try to predict development issues that may come up
- Design handoff - Establish rules, be flexible and communicate the design functionality
- Use Style Guides - break your design into manageable pieces that are flexible, reusable, and client friendly
- Design Adjustments - there will always be change! Changes happen as a site grows, so be flexible