Design conversations

As a freelance designer and developer I’m often hired to work as part of a larger team. Even then I spend a lot of project time working alone and communicate via email and telephone. It’s easy to get caught up in the trap of not communicating with other team members in this scenario so here are some reminders, mainly for myself but others may find them useful.

Designing for best-case scenario

We all do it. Ideal headlines, perfect blocks of copy, images perfectly cropped to fit their containers. These look great when presenting designs to clients but in the real world they can quickly fall apart if variable content isn’t considered during the design process.

A good example of this is card components. These can look great when the content is similar across all cards in a block but that’s often not the case once real content gets added. Consider this example:

All cards are neatly aligned because they have similar length titles, the same amount of tags, the body copy is well edited to be similar lengths and the images are well chosen. However in the real world they would probably end up more like this (I’m exaggerating a bit but you get my point):

The surf card has a badly chosen image. Granted this is down to the editor choosing a better image but we’ve all seen this happen far too often. It also has a very short title and minimal body copy which creates too much white-space on the right of the card.

The mountain bike card has a lot more tags than the others which makes that section look very cramped especially when coupled with the longer title. The body copy has taken over the card and is extending it far below the baseline of its siblings making things look un-balanced.

So what do we do in this situation?

Some say that this is where cards break down as they are a little inflexible but, whilst I agree, I think we still need to consider these extremes when presenting designs to clients as we’re in the best position, at this stage in the process, to help clean things up in these cases rather than waiting until the build stage or when the site is launched.

Some solutions include; masonry layouts so that cards take up all white-space where they aren’t all the same height, sub-headings to help with longer titles, truncating body copy and slide-outs or icons with numbers for tags.

The solutions aren’t the point of this article though, the point is that teams should discuss these extremes. Designers need to consider them and talk to their developers — and if that hasn’t happened then developers need to get on the phone to the designer and have a good old chin wag — to see what solutions are available. Sometimes the solution is to choose a different design approach altogether. These are some of the benefits, to our clients, for choosing bespoke design rather than an off-the-shelf template so don’t brush this chance to make improvements aside.

If you were to sell a pair of boots then you’d find a suitable box to post them out in. You wouldn’t fold them up or cut off the toe box so that they fit the box you have — the design should suit the purpose rather than making the content fit the design.

Considering technologies as part of the design

I know, some of you will be saying “but Steve, this is the developer’s responsibility” and whilst you could be right why not involve the designer? Just throwing that out there! Consider the following:

The box contains copy and images related to the selected dropdown option, in this case it’s leisure. If someone wants to show content from a different option, perhaps sport, we have a couple of options. When we select a new option we could re-load the page and show the new content in the box. Or we could create a Vue component and have the content injected into the box without re-loading the rest of the page.

Both approaches are valid but by using JS we can not only save the over-head of re-loading everything else that might be on the page just to show a small piece of new content, but we can make the experience a lot smoother for the person using the site.

I’m not saying that designers won’t be aware of these options because many are but it’s worth having the conversation, designer and developer. Both bring different skills to the table and it’s a good idea to capitalise on them throughout all stages of the project. This technology decision really has an impact on the UX so it’s very much a part of the design process. Working this way makes the whole project a lot more agile.

Those are just a couple of examples but the main point is that it’s good to keep communication going throughout all stages of the project and just because we may be in the initial design stages of the project doesn’t mean that the developer shouldn’t get involved. An agile approach to the whole project can bring much better results.