In agency work, client meetings are interesting.

Generally clients aren’t wrong (however there are exceptions). They know their business better than you, and they are much more invested in the outcome.

The challenge as a designer is not only to produce an excellent product that meets the commercial goals, technical limitations, budgetary requirements and user experiences required— but also to explain how the solution fits the compromise of the above.

After weeks/months of internal process and iteration it can often be taken for granted that everyone is aware of the reasons for design decisions. Here is a simple example.

Mobile pages are often longer, and for good reason. Content that takes 5 lines in a 700px wide column could take 10 lines in a 290px wide column on an iPhone SE— even after reducing the font-size.

An example

I’m going to try and not make blanket statements… but:

If the prioritisation of content is carefully considered, an information scent is included and access to anything truly important is available without further interaction on page load, then reducing all margin-bottoms to 0 on mobile to try and decrease the page length is probably going to decrease usability rather than improve it.

In my experience scrolling is much more pleasant and natural on a mobile, and I think the use of whitespace was restrained.

But the constant feedback in client meetings when presenting flat visuals of designs was “The mobile pages are too long”.

Something needed to change.

At University one of my lecturers was an incredible calligrapher and typography expert— one of the old guard.

She refused to accept digital submissions of any work designed for print. A huge inconvenience at the time (costs + effort) but she was right.

“Its impossible to evaluate the work if it is not in the intended context.” — Ruth Dineen

Clients were viewing designs created for mobiles on desktop browsers, making it impossible to see the intended context.

It was possible that the pages were actually too long, but I wanted to test the hypothesis that their issue with the length was caused by the context.

Too long, or out of context? (Or maybe both)

Resources (and common sense) dictated we couldn’t create a visual for every possible client device, and experience from clients testing prototypes has shown that the majority would only check on their work PC even if instructed to do otherwise.

“If a problem can’t be solved within the frame it was conceived, the solution lies in reframing the problem.” — Brian McGreevy

Rather than cause inconvenience to users and actively blocking them from viewing on a desktop, I decided to try and meet the users on their terms, and provide the additional context they are missing.

Rather than trying to nest images within images and deal with an overflow hell-hole, a pure html/css seemed a simple choice. Lightweight, easily customisable and flexible. Thankfully the great people over at Marvel app had done a lot of the heavy lifting already with Devices.css.

Simply by nesting the full length image within the structure of the device provided a much closer experience to that of a mobile user— with the full length of the page hidden, only revealed in digestible chunks as the user chooses to scroll.

But while here, it seemed appropriate to see if there were other improvements to be made for clients, myself and the team.

Existing visual presentation process

The old process ‘worked’.

As far as I can tell it had been in use since 2003 (this is not a typo) with a small update to use <frame>, <frameset> and <noframes> elements in 2005.

It was simple process:

1. Transfer graphics into a folder on the visuals server
2. Create html files which reference a single graphic each
3. Create a html file for the navigation/image selector
4. Access visuals via a secure URL

But in projects with 10+ visuals, with multiple iterations and combined with some other internal issues would be pretty labour intensive for the designer.

All files that need updating…

Initially my plan was just to incorporate our Devices.css markup into each of the html files that would be showing a mobile view. But what if we could automate the creation of these html files? (or achieve the same effect)

Short story

The agency I work for uses a custom CMS built in php.

I have no idea what php is.

Developers give me blank looks when I try and explain my ideas.

Or worse just say no.

How can I create and communicate my ideas effectively with the developers if we don’t speak the same ‘language’?

Time to learn what PHP is, how it works and how the developers will be using it.

PTL for Codecademy. 🙏

Hello PHP

Using my newly acquired php understanding I built a simple array that could hold a title, path to file and if it should display within the device frame

My simple array

By having only 1 file to update and maintain instead of 10+ I’d saved myself about 15mins every time (multiple times a day).

A few tweaks later included easy switches to toggle visibility and group visuals into sections and it was all looking good.

Additional tweaks

nav.html was updated to nav.php to enable an automatic generation of the navigation <frame> based on the visibility of in the image array, resulting in only one file to maintain per project!

:)

Introducing JavaScript

<frames> were removed from the spec in HTML5 “because using them damages usability and accessibility”.

I needed a quick way of replicating the functionality while remaining on one page (to prevent having to update multiple files, or learning how to create a database).

Its hacky, and my implementation does not improve the usability and accessibility failings of frames, but it doesn’t make them worse either.

Rebuilding this now if given infinite time and resources, this would be a great candidate for a framework like Angular, React or Vue to manipulate the DOM and use components for the devices. Accessibility and usability issues could start to be addressed by incorporating something into the URL to enable link sharing of particular visuals and to allow predictable use of the browser back and forward buttons.

After breaking the process down into some logical steps I was able to write some JavaScript with the help of jQuery that would:

1. Prevent my links from navigating away to the image file
2. Collect the path of the graphic to display
3. A switch to check if it needed to insert the HTML/CSS phone around the graphic
4. Display the graphic

A little bit hacky, but gets it done 🙈

A few extra tweaks to toggle an active class in the nav to let users know where they were and to load the first image in the list by default and it was ready for testing.

Final result

Final result

Not one single comment of page too long since

Further reading

Here are some extra little things combining development languages I’ve taught myself and some design ideas.

• Late Night London Loader
• Arts and Education Loader
• The Wheels on the Bus

---

Originally posted on Medium

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