Whether or not you’re a seasoned designer, choosing a UI font can be a daunting task. As of writing this, Google Fonts alone has 997 families. You might think picking a font is mostly an exercise in preferences, but there are less subjective criteria that you should always be on the lookout for.

1. Does it have 2–3 usable weights with italics?
   You’ll generally need a regular weight and a bold weight. Adding a medium or semibold weight into the mix will give you more flexibility for creating a variety of complex components. Whichever weights you choose, having italics for them is a valuable addition.
2. Does it look good on PCs?
   Theoretically this should be does it look good on your target devices, but I’ve yet to find a font that looked good on Windows and poor on Macs… The important thing to remember is operating systems, browsers, and screen quality all affect how a font is rendered so preview your fonts on various devices.
3. Does it have the characters you need?
   Depending on the languages you support, you’ll want to look for those character sets. But beyond that, if your users are in the UK, does the font include a pound sign in addition to dollars? What about Euros and yuan?Don’t forget to check for less common but useful characters like ellipses and basic math symbols.
4. Does it have appropriate numbers?
   Tabular numbers are equal-width characters that are especially useful for comparing values in tables, hence their name. Proportional numbers vary in width and are more appropriate for displaying numbers next to text (for example, in an address). One or both may be required based on your needs.
5. What does it cost to license?
   I won’t try to convince you to use a free Google Font or buy the latest font from Hoefler&Co, but cost is a constraint you’ll have to weigh. Something to consider when choosing a system font or a system font stack, is that usage outside of the native devices may not be permitted (for example, in advertisements or print).

5 tips to help select great user interface fonts was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Your portfolio will get you an interview, not a job

The role of your portfolio (and resume) is to get you an interview. Your work should stand on its own, but it shouldn’t include an 8-page case study. Save your detailed process and trove of artifacts to review onsite.

2. Unsolicited redesigns are OK

Junior designers often don’t have a lot of client projects in their portfolio. It’s OK to supplement these with a couple unsolicited redesigns. I’d recommend a product you already use but have some issue with. Take a look at one I did awhile back or find more here on Medium.

3. Your portfolio should reflect what you want to do

Your portfolio should reflect the work you want to do. It may sound obvious, but often portfolios show everything we’ve done, not just what we want to continue doing. No longer interested in logo design? Prune your portfolio.

4. Tailor your pitch to the interviewer

Always feel free to tailor your portfolio and presentation to a specific interviewer or role. For example, highlight the details of your design process to fellow designers, share your collaboration techniques with developers, and stress business goals and your impact to product managers.

5. Understanding code is an advantage

It’s might not be a requirement, but knowing how to code can tilt the scales in your favor. Anyone can pick up the basics of HTML and CSS, and with more patience, JavaScript. There are good free courses on freeCodeCamp.

But even more important than coding is understanding technical concepts and terminology. In addition, knowing the possibilities and difficulties of developing for your target platform — be it web, native, or mobile — goes a long way.

5 things I wish I’d known as a junior designer on the job hunt was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

With Firebase’s new Firestore for offline support

In case you haven’t heard, Progressive Web Apps (PWAs) are finally ready for prime time.

It might not yet be obvious to many people how to install a PWA, but if you’ve done it once you won’t forget it and it’s simpler than using an app store.

There are many reasons to start building PWAs and converting current responsive web apps, including:

• Offline support: Service workers keep much of your application running smoothly with a spotty internet connection or none at all. Once users are back online, their data syncs behind the scenes.
• A truly native looking and feel: Your app is launched from a custom app icon and can function in fullscreen.
• Breaking free of the app store: As opposed to native apps, there’s no approval process for PWAs so no delay for new features or bug fixes.
• Progressive enhancement: If users don’t install your app it will still function as a normal web application. Hence the “progressive” in Progressive Web App!

✨ The magic ✨

You need 4 things to make a PWA: HTTPS hosting, a service worker, a properly configured index.html file, and a web app manifest.json file. The examples below are geared towards React but are similar for any framework.

Step 1: HTTPS hosting

Firebase provides free SSL certificates and freemium hosting. Another great choice is Netlify.

Step 2: Set up a service worker

If you want your app to work offline once installed, you’ll need a service worker. Create React App makes one for you, but you can always configure your own using something like this. Learn more about how they work.

Step 3: Configure your index.html file

A challenge in configuring your app is understanding the difference in how iOS and Android use the meta tags in index.html and the web app manifest. We’ll explain how each option is used below.

One painful part to this process is creating the massive number of splash screens for iOS: one for each screen size and orientation you want to support, otherwise users will see a white screen while your app loads.

Step 4: Configure your manifest.json file

Create React App makes a manifest.json file in your public directory, but if you don’t have one yet create it and make sure it’s referenced in index.html (lines 19–20 above).

Spice it up with Firebase and localStorage

With a service worker, your app loads without a network connection, however it won’t have much functionality.

Enter Firebase. Firebase’s brand new Cloud Firestore improves upon their Realtime Database with several enhancements but most notably it will continuously attempt to sync data while offline.

To make sure users also *start* with data when they launch your PWA without a connection, use localStorage. Our sample React app combines these two methods to let you access tasks you’ve already created and add new ones regardless of connection status.

👉 See our sample React app to use Firebase with offline support 👈

Bonus: Design considerations

Much like responsive design, PWAs offer unique design options. Should something be styled differently when viewed as an installed PWA and when viewed on the same device but in a browser?

Here are handy media queries for targeting installed PWAs:

Similarly, to see how users are viewing your PWAs in JavaScript:

Building a Progressive Web App in React was originally published in Perficient Digital Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

My role as a hybrid designer and front-end engineer gives me a unique opportunity to see how the sausage is both designed and made. Our process at Perficient Digital Labs varies by project, but is often:

• 📓 Gather requirements through 👩‍🔬 research & interviews
• 💡 Brainstorm and ✏️ draw potential solutions
• 🖥 Create wireframes and mockups in Sketch
• 🤹‍ Bring these to life with prototypes in InVision
• 🤓 Code a refined prototype or production app in Angular or React

This workflow always involves a handoff from designers to front-end developers, sometimes several if we’re working in an iterative sprint style. Below are some tips for making this transition as smooth as possible.

☝ Tip 1: Size your artboards correctly

Let’s say you’re designing for an iPhone 6/7/8 (they’re all the same size). You select the handy iPhone 8 artboard size (375px by 667px) and go. Easy, right?

Well…it depends. If it’s a native app you probably want to account for the 40px tall status bar at the top of the screen. But mobile web is where it gets tricky. The visible area on mobile Safari is only 559px tall (growing to 627px as you scroll). So that design you thought fit comfortably above the fold might not, leading to an awkward QA process.

The easiest solution? Create your own custom presets in Sketch for common desktop and mobile sizes.

☝ Tip 2: Only use opacity when it’s needed

Want a medium gray? Make it a solid color, not a 30% opacity black over a white background. Opacities can live in several places: on the alpha channel of the color, on the opacity of a fill, and on the opacity of the element itself. And that doesn’t even count groups! This makes it hard to compute the actual resulting color when coding it up.

There are cases where opacities need to be used, like a modal overlay, but make sure before moving those sliders.

☝ Tip 3: Keep borders on the inside

Most developers prefer something called “border-box box-sizing.” What this means is that if you put borders on the inside, your devs can simply copy/paste these values. However, if you put borders on the outside, it takes math to code it up. Less math = less mistakes.

Also, Sketch ignores outside borders when aligning elements and creating symbols. Probably not what you want.

☝ Tip 4: Version control is your friend

Final-v6-for-real-this-time.sketch anyone? A version control tool like Abstract will make your life easier in many ways, but one benefit is each revision automatically tracks what changed. This keeps you and fellow designers on the same page and keeps devs from sorting through every artboard to make sure they grabbed all the latest edits.

☝ Tip 5: Do a design audit

There are several tools that automatically generate style guides for Sketch. Craft’s Library is my favorite. Not only will this make your life easier while designing, but you can quickly scan the generated styles to see if you have two slightly different fonts or colors anywhere in your document.

You’re probably already taking advantage of Sketch’s symbols and styles (because you don’t hate yourself), but making sure to use them consistently is a huge time saver for developers.

☝ Tip 6: Two lines to solve font woes

Sometimes during QA, the fonts actually look like the mockups across browsers and devices. But more often than not, something looks too bold here or too thin there.

The issue is with the different anti-aliasing algorithms used and that the default values aren’t necessarily consistent. If things look off, have your dev try adding these CSS styles:

body {
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}

Pro tip: validate your font and weight choices on all the browser and device combinations you’re targeting before finalizing your style guide.

☝ Tip 7: Unsure? Ask!

Some things seem hard to code and are actually reasonable. Some things should be easy to code but unfortunately aren’t. One example is truncating text with an ellipsis: easy peasy for a single line, not so much for a paragraph.

Before you head down one of two potential paths, ping your dev to see if one solution would require significantly more work than another. It never hurts to get a second opinion and devs often like to be included in the creative process.

Have any tips of your own? Let me know 🗣

7 design tips to keep developers happy was originally published in Perficient Digital Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Do your eyes glaze over at the mention of an API? Have no idea if cookies are good, bad, or just delicious?

Web development is complicated. And there’s a lot of confusing terminology surrounding it. So here’s a short list of concepts, tools, and languages written in plain English for designers, project managers, and other non-tech folk.

This is primarily for those who want to become more comfortable talking about web tech and to developers. If you want to learn how to code, take a look at this extensive guide.

The Basics

Web apps
Run in a browser (Chrome, Safari, etc.) on your computer or mobile device. Examples include Google via google.com and Facebook via facebook.com.

Mobile apps
Are downloaded from an app store. Mobile apps don’t run inside a browser. Examples include Snapchat and Candy Crush.

Desktop apps
Are downloaded onto a desktop or laptop computer. Desktop apps don’t run inside a browser. Examples include your browser itself, iTunes, and Word.

Native apps
Can describe mobile apps or desktop apps.

Client & Server
The client (aka client-side) is the user’s computer. The server (aka server-side) is a remote computer where your application is running.

Front-end development
Writing code that runs on the client, including HTML, CSS, and JavaScript.

Back-end development
Writing code that runs on the server. Examples of back-end languages include Java, Ruby, Python, and PHP.

Full-stack development
Includes front-end and back-end development.

APIs
Application program interfaces are how applications communicate. APIs can be free or paid, public or private, well documented or not at all. APIs can communicate with other apps in the same organization (e.g. your mobile app communicating with your database) or across organizations (e.g. pulling data from Facebook using their API). An example is a simple weather app that takes the user’s current location and sends it to a third-party weather API. This API returns forecast data which is processed by your app to tell the user the current temperature and if they need an umbrella.

Frameworks
Code templates used to save time and benefit from established conventions. Frameworks are like pre-made pasta sauce you can customize to your own taste. They exist for the front-end and back-end.

Cookies
Small pieces of data that websites store on your computer. Each time you visit a new page on the same site, this data gets sent back to the site. One helpful use for cookies is to persist items in a shopping cart, even when you’re not signed-in. Another helpful use is letting you to avoid reentering your password once you sign-in. Cookies are (more nefariously) used by advertisers to track behavior and target ads.

Content management systems
CMSs are applications used to create and edit the text and media on your website. Their visual interface let users edit a site without writing a single line of code, after the initial setup. Wordpress is the most popular CMS.

Open-source software
Software that can be used free of charge. This includes everything from operating systems (e.g. Linux), to programming languages, to small bits of code. Companies that rely on proprietary software (e.g. Twitter) often still contribute to open source (like Twitter’s Bootstrap framework).

Responsive design
The ability to alter the contents of a page based on the viewing device. This is most often done using CSS and the browser’s current width. For example, a wide screen (desktops & large laptops) may show 3 columns of content and 1 column of ads, a medium screen (small laptops & tablets) may show 2 longer columns of content and 1 column of ads, and a small screen (phones) may show one long column with content and ads combined.

Common Tools & Activities

Text editor
Where most code is actually written. Can be as simple at TextEdit but many developers like the customization available in tools like Sublime Text and Atom.

Browser inspector
Allows you to inspect the HTML, CSS, and JavaScript on a page, as well as insert your own code for testing. The inspector is primarily used for debugging.

Command line
A desktop application for directing your computer (or a remote computer) to do many things, including downloading code and managing git.

Git
A version control system for code. This allows people to work on the same files simultaneously and smartly combine their edits. It also provides a comprehensive store of all changes and versions for every file in a project. GitHub is the most popular service for hosting version-controlled projects.

Pair programming
When two programmers code side-by-side, taking turns typing. This extra set of eyes can help spot errors and improve the quality of the code.

Refactoring
Rewriting code to be simpler to understand or more easily maintained. Similar to editing an essay to be more clear and concise.

Sprints
Typically a 1–3 week development cycle with a list of tasks to accomplish set from the start.

Stack Overflow
A free Q&A site for programming-related questions. Many searches for programming-related questions will lead you there.

Languages, Libraries, & Frameworks

HTML
A markup language that defines the content (text, media, forms, etc.) of every webpage. HTML5 is the latest version.

CSS
A styling language that defines the look (fonts, colors, layout, etc.) of every webpage. It can also be used for simple animations. CSS3 is the latest version.

Bootstrap
A popular CSS framework. Defines styles for things like the layout grid, form elements, and common components. These basic styles can be overwritten to fit your brand and specific needs.

JavaScript
A unique language since it can be used both client-side and server-side. JavaScript is often used for sending or receiving data, animation, and responding to user input (e.g. validating form inputs as you type).

AJAX
A method of using JavaScript to communicate with a server. One use is to keep users from waiting. For example, here on Medium, your feed loads with several articles in it, but waits to load the next “page” until you’ve scrolled near the bottom. Another use is to avoid unnecessarily reloading a page. For example, when writing a blog post on Medium, they autosave as you type without reloading the page each time.

jQuery
A popular JavaScript library. Provides methods to make AJAX calls, edit the content of the page, and detect user actions.

Java
Has no relation to JavaScript. Can be used as a server-side language and is the only option for creating native Android applications.

Objective-C & Swift
The two language options for programming native iOS applications.

Ruby, Python, & PHP
Just a few of the many server-side languages. Ruby on Rails is the most popular framework for Ruby.

Find this useful? Click the ♡ below to help others see it.
Suggestions? Anything unclear? Post your thoughts below.

A blank page is less intimidating than a blank screen

My urge is often to start wireframing in Sketch. But even if you’re keeping things simple — only using basic shapes and grayscale — pencil on paper is a better place to start.

Sketching comes easier to some. If you like drawing, it’s instinctual to start there. But I’ve never drawn for fun and certainly am not skilled at it.

None of that matters. Sketching allows you to produce designs faster than a computer. More speed prevents second-guessing your ideas and leads to more unique concepts and thorough exploration.

Best of all, you don’t have to show these incomprehensible scrawls to anyone. You can always tidy up your ideas later using Sketch.

The idea of starting with paper isn’t new, but it’s important enough to reread until you actually start believing it.

What we learned making a bot that talks like a person

It’s 12:30pm at Truth Labs which means we’re standing outside trying to decide where to go for lunch. We’re a creative bunch, so this seemed like a problem we should be able to solve. And a perfect opportunity to take a shot at experimenting with conversational UIs.

First, some terminology

Graphical user interfaces (GUIs) are a visual way to interact with a device. Instead of typing specific (and often cryptic) commands in a terminal, GUIs let users interact with files and programs by clicking and dragging.

Conversational user interfaces (CUIs) are a spoken or written way of interacting with a device. CUIs aren’t completely new, but they’re becoming smarter, more natural, and — therefore — more useful.

If you build it, they won’t come

Companies are realizing it’s hard to get users to download and use their apps. More than half of the time we spend on our phones is talking, texting or in email:

Here’s where CUIs come in: since users already spend so much time in apps like Slack, Facebook Messenger, and even plain-old email, why not integrate your app inside these platforms?

Sure, users still have to find and install your app, but you can now interact in a more natural way. Users are more likely to use your service if it doesn’t break their workflow by requiring them to switch apps.

Making Lunchy

Lunchy is a Slack bot that smartly suggests where to go for lunch. He lives on a Node server hooked up to Slack using Botkit. The first step was getting him some data. We created a simple database using Fieldbook and added the 30 carry-out restaurants within 0.5 miles of our office.

Lunchy started out being able to understand a few commands:

• Suggesting a restaurant
  Typing something like “what’s for lunch?” or “where should we eat?” results in Lunchy responding with a suggestion.
• Responding to feedback
  If you don’t like a suggestion, typing “what’s for lunch” again isn’t the most natural solution. We could have gone with something like “nah” or “try again” but even easier is responding with a single click. A 👎 on a recommendation results in a new one.
• Finding a location
  Responding to a suggestion with “where’s that?” or “show me a map” results in Lunchy sending a link to the restaurant.
• Telling a joke
  Just because he’s a robot doesn’t mean he can’t have a personality. We gave Lunchy a few jokes to keep up his sleeve. My personal fav: “What’s better than MacOS? TacOS.”

There’s still a design process

The “no UI” buzz may sound worrying to designers, but “no UI” is a misnomer. Conversational UIs are interfaces, just — well — conversational.

How are conversations started? What options do users have? How do they discover these options? What happens when people get confused? The role for intuitive design in conversational UIs is even more important without any visual affordances to fall back on.

Don’t be a robot

During our process, a surprising finding was that personality matters. The Slack API is fast, meaning Lunchy replied almost as soon as you finished typing.

Part of the magic was lost. Lunchy felt like a robot, not a helpful member of the team who happened to love lunch.

The fix? Simulate that Lunchy was “typing” and delay his response by a mere second.

Make sure you solve the problem at hand

At this point, Lunchy was a personable bot that drew suggestions from a digital hat. He’d find you somewhere to eat, but not necessarily somewhere you’d like. The next step was making him smart.

Recommendation algorithms live on user data. The data drive suggestions and let you evaluate an algorithm’s effectiveness.

We were already providing feedback on what we liked (restaurants skipped less often > restaurants skipped more often), we just had to start storing this information in our database. Lunchy could now use an algorithm to prioritize our favorite spots and stop recommending places we never went.

Try to anticipate user needs

It’s the middle of winter right now and we quickly found suggestions more than a few blocks away were often getting passed — not because we didn’t like the food — but because Chicago winters are not so forgiving. The fix? When making a suggestion, Lunchy quickly checks to see if it’s bitterly cold or raining (using Forecast). The worse the weather, the closer the recommendation.

Several days into our experiment we noticed a familiar trend reemerge: the team congregating around a computer or phone to ask Lunchy where to go. Automating repetitive tasks like this are what computers have been doing for decades. Since we always go for lunch around the same time, we now have Lunchy send a friendly ping every day at noon.

What’s next?

There are a couple areas we’d like to explore such as menu suggestions using Yelp and automating orders for pickup or delivery. We’ll post our updates…

Lunchy was a fun experiment to spend a few days between projects on. But more than that, he’s added some spontaneity to our daily routine. Welcome to the team our brown-bagged friend.

Enjoy the post? Click the ♡ below.

Where does conversational UI leave design? was originally published in Perficient Digital Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re big fans of Sketch. We use it for everything from low-fidelity wireframes to pixel-perfect mockups.

However, many of us who cut our teeth in Illustrator find that while Sketch rocks 99% of the time, there are still a few workflows that, well, need work.

Specifically: it’s a pain to unlock layers. Illustrator has a handy keyboard shortcut but Sketch doesn’t. And it seems to be a common ask amongst the community.

So we made a plugin to do just that. To install it, simply download the zip and double-click the “.sketchplugin” files. Keep reading to learn more.

The problem

You’re in the flow, navigating your artboard when you decide to shift a few items around. You drag-select them only to find that some things are locked:

So now you need to find the locked layers. You look for the little lock in the layers palette but you’re not sure which is which, because you didn’t name your layers… (╯°□°）╯︵ ┻━┻

Instead you try a group-select to toggle the locks, but that toggles unlocked layers too. Boo. You have to select each one individually, without the pesky scrollbar getting in the way:

Our solution

We wrote a simple plugin to unlock all layers on the current artboard with a keyboard shortcut. To install it, simply download the zip and double-click the “.sketchplugin” files. Check out our code on GitHub.

Here’s a screen capture of the plugin in action:

You can access the plugin via the plugins menu or keyboard shortcut: ⌘⌥L (Command + Option + L). You’ll know its worked when you see the notification at the bottom of the screen.

It’s worth mentioning that adding keyboard shortcuts to your plugins is incredibly easy via method a or method b.

Sketch plugin: Unlock all layers was originally published in Perficient Digital Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

• They’re free for commercial use
• They’re super simple to set up
• They can be quite fast (common fonts are likely cached)

Love ‘em or hate ‘em, Google Fonts are everywhere. Here are my favorites…

Lato

Looking for a sans-serif? Lato is a great place to start. It’s a versatile font available in 5 weights. One of my favorite uses for Lato is in all-caps with loose tracking, as on my personal site.

Source Sans Pro

How about another versatile sans-serif? Source Sans Pro is available in a whopping 6 weights and even comes in a serif version. It shines in headings or body copy.

Merriweather

Merriweather is a workhorse serif available in 4 weights. It’s a joy to read, even at small sizes. In fact, I use it for the body copy of my portfolio. Merriweather also comes in a sans-serif version.

Playfair Display

Playfair Display is a distinctive serif available in 3 weights and with small caps. The font is full of character (no pun intended) with the bold weights and italics being especially suitable for striking headings.

Oswald

Oswald is a narrow sans-serif available in 3 weights. It really only works for headings but looks wonderful in all-caps where it’s reminiscent of old newspaper headlines.

What are your favorites that I left out?

So what does this have to do with software? A big component to Agile and lean development is to minimize your build to learn ratio. That is, to build as little as possible to learn as much as you can.

This can be easier said than done, so let’s look at some real-world examples.

If I build it, will they come?

I attended a great talk by Angelique Rickhoff the other day where she discussed UX research at Solstice Mobile.

Angelique was tasked with designing an internal app that gave salespeople information on clients right before a meeting. At this point there were two unknowns: Would people use the service and what content was valuable?

Her first step was talking to potential users, but there’s always a difference between what people say and what they actually do. So Angelique’s team didn’t build anything. Yet. Before each meeting, they manually scraped information to compose their messages.

These messages contained links to things like “recent tweets” and the “latest earnings report.” They could have easily embedded this content, but there was a reason they linked to it: so they could track what was clicked.

By analyzing email open rates and what content was actually viewed, Angelique and her team determined what was and wasn’t worth building.

Ideas to get you thinking

Bringing data into your app

Integrating with third-party APIs and parsing various formats is incredibly time consuming. And you might not know what users need support for.

Instead, have users upload their data (XLS, CSV) and tell them their data is being processed while you work to manually create items (users, products, whatever) in the background. This helps you prioritize what to actually build support for.

Testing an algorithm

Take the dating app Coffee Meets Bagel, where users are matched with one potential date each day. I’m sure they have an automated system now, but I’d be surprised if they didn’t start by reading profiles and matching users by hand.

Even if your algorithm is too complicated to fake, running the code yourself let’s you do a sniff test on the results before showing them to the user.

What else?

Have any Wizard of Oz examples of your own? I’d love to hear them.