My natural tendency is to exert the least amount of energy to get the best possible result.

If there is a more efficient way of doing something I want to know, and I want to incorporate it into my workflow.

Spending days combing over a website raising hundreds of tickets for incorrectly aligned text, unexpected colour combinations and wild grids is not a good use of anyone’s time (and eats into profit).

Thankfully by changing the way I communicate the design, QA has been reduced to 1/3 of what it was. Allowing the focus of the QA to be on fine tuning interactions rather than fundamental changes— even with front-end developers who would consider themselves ‘design blind’.

Explaining designs

I don’t believe design is something mystic, I think it can be deconstructed, analysed and learned.

Depending on who you ask there are 5–10 basic principles of design. I think the following sums it up.

Alignment. Hierarchy. Contrast. Repetition. Proximity. Balance. Colour. Space. (— Adobe Spark Blog)

In order to produce attractive and successful designs you are forced to manipulate the effects of these principles (even if you don’t identify them by name). This is a skill that requires practice and time, and sometimes has priorities which are different to developers.

We needed to find a common language that everyone could understand, to streamline production and reduce errors.

Atomic design

The single biggest change I’ve seen was introducing a shift to using parts of Brad Frost’s Atomic Design principles, after reading it.

An example of the progression from content to page.

This helped create consistent user interfaces, and using the symbols features of Sketch, rapidly modify many components at once if necessary.

Inputs

It has also simplified the process of design documentation and allowed developers to create reusable blocks of code that were easy to maintain and update. In the process empowering developers to create new components, confident that the elements and molecules have already been designed and defined.

Component system

“We’re not designing pages, we’re designing systems of components.” – Stephen Hay

Design process

There are great advantages to working at a company that has been around for 20+ years, but there are also disadvantages.

Previously the company process was completely linear, with a client sign-off and internal handover after each stage (team in brackets) with little/no overlap:

User flows, Wireframes/IA, Static Visuals (design), Front-End Prototype (front-end), Technical Integration (technical), QA and testing (testing), Support (operations)

User flows created for a complicated and multistep application process— from acquisition to completion

However, I am grateful that I have been allowed to work in a more agile way— bringing in all parts of the business at wireframes and visuals. Working with technical to ensure ease of integration within the CMS, predicting server loads and bridging the gap between how users and CMS’s operate; and designing consistent components with clear definitions allowing front-end to create reusable and easy to maintain code.

Atomic design, combined with turning the design stage into a more agile process has completely changed the way design and front-end work together here. Improving accuracy and massively reducing time spent on design QA. The positive effects seen have started to soften the old guard into considering other new and improved ways of working.

Consistency in UX

Although I introduced the Atomic design principles to my work initially to help with the ‘Miscommunication in Handover’ of the waterfall development process, it has had a profound effect on the quality of my own work.

I am now acutely aware of the UI patterns created, and it encourages deliberate and intentional consideration of interactions (and dynamic content behaves expectedly).

Deliberate design patterns tested across scales

Designs look united and cohesive, have increased usability, and are more delightful for users.

Future improvements

Looking towards the future, it seems inevitable that JavaScript frameworks like Angular, React and Vue will continue to become more widespread— there is a responsibility for designers to be aware, and think about their designs elementally to support accurate, rapid, component based development.

---

Originally posted on Medium