However, in many cases, the product development process chosen by your organization won’t let you do this. Also, your organization might hire a third party developer vendor or partner.

So let’s assume that there is some kind of hand-off: after creating the UI design, the designer hands it off to the developers. How can he specify the little details?

A checklist of some best practices

Here are some best practices:

1. Naming the files: use relevant, descriptive, consistent naming (not final_really_final – btw. you should apply a version control system)
2. Provide SVGs: icons, logo, favicon, custom graphics, illustrations – all these should be in SVG format
3. Imagery: this is the aspect of art direction (read more about it in my article), it is about preparing images to be displayed on different viewport sizes
4. Typography: provide all fonts, make sure that you have a proper licence that fits the project’s purposes
5. Copy and UX copy should also be provided (I believe in content first design: please never design with lorem ipsum); most probably you won’t be able to provide all the texts as part of the screens (e.g. you’ll have error and confirmation messages etc.), these should be provided in a table. There might also be translations (this it he aspect of internationalization and localization)
6. Layout
   • Clearly and consistently specify all the spacing values 
   • Specify and apply a consistent grid system
   • Determine breakpoints, provide all the different layouts for each sizes
   • Specify how things should be aligned (see my card-based layout example in this article)
7. Don’t forget the specifications of the UI Animations included (e.g. object’s position in the beginning and at the end, duration of the transition, easing, transformation type etc.) – tools like Lottie can make this easier
8. If you use a certain design system, clearly specify what elements you’ve included, what should be used and where
9. Specify hexa codes for colors, gradients
10. Provide all the assets in a consistent file structure, everything should be easily findable
11. All the different states of components should be provided (e.g. in case of a button: pressed, hover, focus, disable, default; checkbox on and off)
12. Pay attention to platform specific guidelines and principles, and communicate these to the developers

Final advice: use a checklist, so that there won’t be any missing parts

How to specify all these

You can use annotated sketches, wireframes, prototypes, and create design handoff documents (UI documentation). 

Next to these manual ways, there is an automated way. You can use design hand-off and inspection tools (e.g. Zeplin, Invision Inspect or Avocode) – in this case you need to use a consistent layer structure in your design tool of choice. These tools let developers inspect the designs, get measurements, all the assets, and these usually include collaborative features as well, e.g. you and the developers can add annotations, comments.

So to sum up, the most important thing is that you need to specify all these things so that developers can effectively implement your designs. I’d like to highlight that a heavy documentation and a highly detailed specification can generate a lot of waste in the process, but as I mentioned, in many cases, you can’t avoid creating heavy hand-offs and detailed deliverables.

The post Design handoff best practices appeared first on protostar.space.

Responsivity & Images

First let’s talk about images.

One safe solution for including images in your layouts is using a fix aspect ratio, e.g. for many years Instagram only allowed users to upload square images with a 1:1 aspect ratio (and your photo grid screen still contains square images, it crops anything that is not a square).

Now, what happens if you are not working with a 1:1 aspect ratio? In case of a fluid container, the aspect ratio might change depending on the changes of the viewport size. And if you have a fix height, and a dynamically changing, fluid width, you might end up with a distorted image.

In the following example, both of these images have a fix and identical height.

Upon changing the viewport size, the image above gets distorted. On the contrary, the image below doesn’t get distorted, the biggest possible portion of the image is displayed without any distortion:

The key takeaway here is that you, as a designer should specify what should happen with the images upon viewport size changes, how these elements are displayed on different viewport sizes.

And how can we specify what part of the image will be displayed and what part will be cropped out?

Art direction

Usually it’s handled by dynamic cropping – but what happens if the most important part of the image is off-center, e.g. if the rule of thirds was applied, and the subject of the image is placed at the intersection points nearer to the left or right side of the picture? In these cases, dynamic cropping might crop out the main subject. A possible solution is that you can identify focal points, and there are tools that include for instance face detection. So you can either address this issue by manually setting focal points, or there are solutions for automatic art direction (this is the specific term for this activity).

Btw. it is not only about keeping the important part. Let’s say you have a landscape photo with a group of people in the middle (e.g. a family or a group of friends). On larger viewport sizes, it might be easy to tell who is in the picture, you can see their faces very well. However, on smaller viewport sizes it might become hard to recognize someone on such pictures (at least without zooming in).

So another solution is that you can define different pictures for the different viewport sizes (e.g. in Bootstrap’s system, one for the small, one for the medium and so on), and these different images show different parts of the original picture, so for instance you can sort of zoom in (crop out the unnecessary parts), and only show the faces on a smaller viewport size. That way, you’ll be able to assign a good quality image to each size – e.g. your smaller picture’ll be good enough for a smaller screen, and it’ll positively impact the performance, it’ll load faster, so it’s great from a UX perspective. And at the same time, on a large screen, a big enough picture’ll be displayed.

Let’s take a look at an art direction example, as you’ll see on the landscape version of the photo, the main subject is off-center:

On smaller viewport sizes, the image is displayed in portrait mode – the person on the image is the main subject, he is the relevant part:

So until this point I talked about

• Automatically and manually defined focal points
• And using different parts, zoom-levels or orientations of the same image.

There is one more option: you can attach completely different images for the different viewport sizes (so not only different parts of the same image). For instance on a national park website you can include a detailed drone photo of the park for bigger viewport sizes, and a picture of a flower for smaller sizes.

Screen resolution and pixel density

Sn aspect I’d like to mention in connection with pixels is that there are high pixel density screens.

A screen resolution refers to the number of pixels: how many pixels are displayed horizontally and vertically. Now, pixel density [Pixels per inch (PPI)] tells you how many pixels are displayed within a given area of the screen.

For example this is one pixel on the left, and there are 4 pixels ond the right, and the size of the area is the same:

So what this means from a UX perspective is that in case of a cheaper, low-end device, it’s not a good idea to include a high resolution image, since it can’t be displayed in its original form, it must be downscaled first (and the bigger file size might also cause performance problems).

At the same time you should keep in mind that you need high resolution images to provide sharp, good-looking pictures on high-end devices. So this is another aspect you need to consider.

Raster and bitmap images

Until this point I mainly talked about raster or bitmap images. You surely know the difference between raster and vector images, to put it really simply, vector images are based on mathematical calculations, so these are infinitely scalable. On the other hand, raster images are made of pixels, and not scalable infinitely. Also, a vector file has a smaller file size, so it’s better for performance. A commonly used format is SVG, that is stands for Scalable Vector Graphics. So in case of a logo, icons, illustrations you should apply SVGs, these are great for all screen resolutions and pixel densities.

And of course you can define different SVG files for different screen sizes, e.g. a detailed infographic is not always the best solution for a smaller viewport size.

Textual content and videos

And what about textual content? It is a good practice to specify a maximum length for each textual element. Other aspects include typographic choices, like fonts, font sizes, spacing. And in many cases, the textual content itself is also different for different viewport sizes, for example you might want to display only some short paragraphs on a mobile device, while on larger viewport sizes you might want to include longer stories.

You should also discuss with developers how to add videos – e.g. a background video. And another aspect is that you should specify what should be the printable parts of a layout (so for instance you don’t want to include the menu bar or ads displayed next to the actual content).

Skeletons, lazy loading and infinite scrolling

Finally, I’d like to mention three additional techniques.

Applying skeleton contents or skeleton screens means that before the actual content, a low-fidelity mock-up or placeholder is displayed. It makes the perceived loading time shorter, so it increases the perceived performance.

The second technique is the so-called lazy loading. In this case the content is gradually loaded, and its loading is initiated by scrolling down. So the content outside of the viewport is only loaded if the user scrolls to them. 

Infinite scrolling is a similar technique. It’s used by for example Facebook, Twitter or Instagram. There is no pagination, the content is continuously loaded as the user scrolls down.

When you create layouts for websites or for applications, you should keep these techniques in mind, consider using them. Of course there are many more ways and techniques for performance optimization, you should discuss the possibilities with the developers.

Next to these already mentioned aspects, here are some more things to keep in mind.

Some more aspects

Different devices or platforms might involve…

• Using different design guidelines (e.g. Material Design, Human Interface Guidelines)
• Designing for different ways of user input, e.g. on handheld devices, you’ll design with the different gestures in mind; while on desktop, users apply cursors (e.g. you can use hover states)
• Using different UI components, UI design patterns, animations

The most important thing is that you should discuss what the available options are with the developers. For instance you should discuss what libraries, reusable components, existing solutions should be used. Creating custom solutions, for example custom UI libraries requires more development effort. Of course most of the existing libraries let you customize things to a certain extent, you should talk about these with the developers.

Let me know if you have any more tips & tricks for designing for different viewport sizes & devices!

The post Designing for Different Screen Sizes & Devices – Part 2 appeared first on protostar.space.

The basics

So let’s start with some terms:

Fixed layout means that it does not change based on the screen size or viewport size. Except for specific cases (e.g. a special medical device or a kiosk that requires designing only for that exact screen size, or designing for an Apple watch – currently there are only a small amount of screen sizes), so except for these cases, it’s better to design a layout that dynamically changes based on the screen size.

A layout is fluid when the size of the elements inside the layout is defined by percentages, so if it proportionally changes based on the viewport size. As you can image, using only this as a solution results in suboptimal experiences either on small or on large viewport sizes.

The adaptive approach means that you design a series of fixed layouts, and the one nearest in size to the given viewport size is being displayed. This is good for performance, and you can design for each and every size intentionally.

Responsivity

Responsivity means that your digital product or service is displayed in a way that it responds to the properties (e.g. viewport size, orientation) of the device it’s being viewed on.

It’s a combination of the fluid and adaptive approach: you predefine breakpoints, it let’s you design different layouts for the size bigger and smaller than the breakpoint – this is the adaptive nature, and at the same time it responds by stretching or shrinking – this is the fluidity.

As an example, the Bootstrap component library contains a responsive grid system, and defines 4 breakpoints for 5 different viewport size intervals.

There is extra small for a viewport size smaller than 576 pixels width, and there is an extra large category with viewport sizes above 1200 pixels, and 3 more sizes in between.

You might notice that I used two terms for the sizes: viewport size and screen size. The difference is the following: the viewport size might be smaller than the screen size, since for instance you can change the size of a window. So the viewport is the visible area of a website or an application from the user’s perspective.

When you for instance split your screen into two windows, the website or application’ll be displayed on half the screen. Others might use these terms differently, the important thing is that you need to think about cases when the user might want to resize the window, so an application is not always displayed on the full screen size. On smaller mobile devices, the screen size and the viewport size is usually the same, however, on larger tablets there might be split-screen use cases.

There are basically two types of containers: fixed width and fluid width containers.

A container contains elements of a website or an application (in our following examples, the cards). It defines the size of the horizontal area where these elements will be displayed. There might be multiple containers, and you can combine the container types as well, so for example you can place images inside fluid width containers, and text inside a fixed width container.

Let’s take a look at an example based on Bootstrap’s breakpoints.

Let’s say we have an 576 px viewport size. So it is small size in this system. The second row contains the width of a fixed width container, it is 540 px. What does this exactly mean? It means that from 576 px to 767 px width (so in case of a small viewport size) the size of the container is always 540 px. So for instance if you have 3-columns or a card based layout containing 3 cards in a row, the width of one column or card is always 180 px. The only thing that can change is the spacing on the left and right side of the container! Here is a demonstration for you.

Currently the viewport size is 800 pixels:

Now I resize this window, it’s new width is around 900 px. In Bootstrap’s system, both of these are medium-size, I haven’t reached any breakpoints yet. As you can see, I have 2 cards in a row, and the width of these cards haven’t changed, since I apply a fixed width container:

Now let’s go all the way up to around 1000 px. There was a breakpoint at 992 px width, 1000 pix width means that now we’re looking at a large viewport size. As you can see, the layout has changed due to passing the breakpoint, now there are 3 cards in a row:

If I increase the width to 1100 px, you can see that I use a fixed width container, since the width of the cards has remained the same (the only thing that has increased is the spacing on both sides of our container):

You might ask why there is no fix width container for extra small viewport sizes. The reason is that this viewport size is so small that it makes more sense or it’s more rational to use all the width available. 

In case of a fluid container, the container’ll use the entire width of your viewport, this is why it’s also called full-width container. In this case the width of the cards changes as I increase or decrease the width of the viewport size, since the width is specified by using percentages.

Here are examples showing this behavior. Below 768px (this is the extra small and small size in Bootstrap’s grid system) I have only one column:

On medium sized screens there are two columns:

On large screens I defined three columns:

And on the extra large screens there are six columns:

Since I use fluid containers for this example, cards always take up the entire available viewport size. This is why the third row (fluid width container) of Bootstrap’s breakpoints table contains that in case of a fluid width container, the width of the container is the same as the width of the viewport.

Here is a good practice for designing a responsive layout: you should always check how the application or website looks like on the sort of two sides of a breakpoint, so for instance you should test it with 575 and 576 px width (the extra small and the small). Currently the smallest mobile device’s screen size is 320 px, you should check that out, too. And it’s also worth taking a look at the design on a larger viewport that’s width is more than 1920 px.

I’d like to mention that using Bootstarp’s 4-breakpoint grid system is only one solution, you can define your own system. And of course you can design a different layout for each possible viewport size, e.g. one for 600, one for 601, one for 602 pixel width and so on, but it wouldn’t be a rational thing to do. 🙂

When you design for instance a card-based layout, it’s also important that you specify for the developer what elements should always be aligned horizontally. As you will see in the following example, at 1200 px width a long card title will break the layout, the texts and buttons will no longer be aligned horizontally. So here everything looks fine:

When I change the viewport size to 1200 px, and the layout breaks:

After fixing this issue, I increase the viewport size to 1200 px again, and it still looks good:

And btw. this is why it’s important to specify a maximum length for each textual element displayed on a layout. The other interesting aspect here is creating translations – what happens with the layout in case you translate textual content to a language that contains longer words than English? Finally, one more thing I would like to mention here is that this is why you should always design with real content. If possible, avoid using lorem ipsum.

You might ask what happens if you have an odd number of elements, e.g. a consultancy provides 5 different types of services. How can you display 5 items on a smaller viewport size when you can no longer display them next to each other? It’s entirely possible that there will be rows that doesn’t contain the maximum number of elements, e.g. you’ll have 2 rows, one with 3, one with two elements. It’s a design decision, the important thing is that your developer team member should know about it.

In the 2nd part of this article series, I explain how you can include images in your design and some more aspects of designing for different screen sizes and devices.

Written & illustrated by Krisztina Szerovay / www.sketchingforux.com

The post Designing for Different Screen Sizes & Devices – Part 1 appeared first on protostar.space.