For one reason or another, you may find yourself wanting to publish things online anonymously. Now to some, the “A-word” conjures up images of hackers, Guy Fawkes masks, and people generally saying terrible things to each other on Twitter. There’s long been an ongoing debate about whether anonymity is something that should even be allowed on the Internet.
Yes. Yes it should. There’s no doubt that there are terrible people in the world; but anonymity is a powerful tool for good as well. Here are some of the more obvious examples:
Fighting the power: It sure would be nice if we lived in a world where everyone in every government had the people’s best interests at heart. We don’t, and they don’t. Ask Nelson Mandela, or any number of other great men and women throughout history who have fought for progress and human rights.
Exposing criminal activity: Whether you’re a crime blogger writing about the criminal underworld, or a whistleblower from some large corporation, exposing criminal activity is dangerous. People have died.
Adult content, and other “culturally offensive” themes: Something as simple as writing your own (very personal) memoirs can draw a lot of unwanted attention from those around you. Even if what you’re doing isn’t morally or ethically wrong by any reasonable standard, people aren’t always terribly understanding. And then, perhaps the people in your life would rather that their personal activities didn’t become public knowledge. Staying anonymous is a good way to avoid unnecessary drama, in cases like these.
Maybe it’s just work: One of my favorite blogs back in the day was Waiter Rant where a then-anonymous waiter told all of his juiciest stories. He stayed anonymous for the simple reason that his bosses didn’t want any extra drama at their restaurant. Besides, rude customers who might’ve just been having a really bad day don’t deserve the kind of hate the Internet can put out.
Not holding back: Webdesigner Depot runs a series of posts written anonymously called The Secret Designer. They’re anonymous, because they expose the underside of the web design industry that the writers don’t want to be associated with.
Now if any of this sounds familiar to long-time WDD readers, that may be because I addressed some of these points in The Ultimate Guide to Blogging some time back. I wanted to address the topic in a little bit more detail, and cover some more options we have for protecting our privacy. Here they are, in no particular order:
1. Paranoia
The most common security point of failure always has been, and always will be people. You could be uncovered by some random screw-up you make yourself, or you could be outed by trusting the wrong person. Even people who would never hurt you on purpose can give things away by accident.
More commonly, people who supposedly want to remain anonymous get caught because they can’t help but brag. If this is something you’re committed to doing, you need to change your entire outlook on life. You can’t be Hackerman by night, and turn it off by day. You need to get paranoid, without acting obviously paranoid; because someone probably is out to get you, but they can tell if you start acting too paranoid.
Sounds fun, right? [/sarcasm] How do you know when you’re paranoid enough? Let’s start with the realization that doing everything on this list alone isn’t enough to keep you perfectly safe. This is a basic beginner’s guide at best.
Oh, and remember to avoid actually writing any identifying information in your actual content if you can help it. Just sayin’.
2. Avoid Big Platforms
Don’t use Google for e-mail, sign-ins, or anything else. Ditto Yahoo, Outlook.com, or basically any other major corporation. If they have a reputation for collecting your data and selling it, they’ll mostly likely sell it to the people you want to hide from.
The same goes for your publishing platform. Simply put, you want as much control over your data as possible. That means you shouldn’t give your data to Medium, Tumblr (which is owned by Yahoo), or even good old LiveJournal (yeah, that’s still a thing). The bigger corporations have a history of playing nice with other corporations, but they play especially nice with governments. They will not advocate for your privacy, or even for your life if you find yourself in that sort of situation.
Their PR teams might mutter something about human rights, but you’ll be human left-for-dead. (Sorry, I wanted to lighten the mood a bit.) In any case, most of these platforms probably don’t even want sensitive content associated with them, and will likely take it all down.
3. Hosting
So if you’re going to be buying hosting, here’s the criteria:
You want privacy nuts.
You want a hosting company that is willing to take the (legal) fight to whoever comes looking.
Ideally, it would be good if they believed in your cause, too. That will make them fight harder to protect your data.
You want your hosting to be in another country entirely. Distance is a good way of delaying people trying to track you down. It means less in this day of the Internet, but it still counts for something.
In general, these guys are pretty good options, and they’ve been around for some time:
It should be noted that secure hosting and adult-content-friendly hosting are not the same thing. If you need hosting for those racy memoirs or what-have-you-I’d-rather-not-know, you need to find a host that specifically allows you to host those things in their TOS.
4. Intermediaries
Now remember where I said to be careful who you trust? That still stands. Even so, you may find it incredibly helpful to find someone who can act as your intermediary. If you’re acting in a whistle-blower capacity, you might be able to find a foreign aid worker or activist to do things like help you buy hosting and domain names.
Having a third-party represent you can be indispensable to a smooth operation. But remember that if things are potentially life-threatening for you, it can also get hairy for them. You want someone either committed to your cause, or at least someone who is very, very far away.
If you’re just posting stuff that’s perfectly legal where you are, but still potentially embarrassing, you might use an attorney to handle these sorts of details for you. Attorneys are expensive, but that’s because their silence is worth it.
5. Location and Devices
Don’t write from home, if you can help it. If you’re going to write from home, at least don’t post things from home. Take your device to a separate network far away from where you live, do everything you can to mask your IP, and then post. Do this with different networks, preferably in places that forgo security cameras. This is the time to be most paranoid.
Purge your machine of your notes and rough drafts regularly, preferably right after you’ve posted. Secure your machine with a password only you know on the BIOS, and on the OS, and for God’s sake, use some form of Linux or UNIX-based operating system. Nothing you do will keep a dedicated person who has physical access to your device from breaking in, but you can delay them.
You might consider forgoing a laptop or phone altogether, and just have a USB drive with a Linux OS on it, and no persistent storage. That way, you can go to almost any computer, boot it up with the OS on your flash drive, write your post, and leave. No persistent storage means that your files will not be saved when you shut the computer down.
No, really. Whether you’re exposing corruption in your own government, or just posting some artistic photos that conspicuously do not show your face, you need to live as legally and unobtrusively as you can in your day to day routine. It’s the best way to avoid unwanted attention. Remember, not even the Joker would mess with the IRS.
7. Extra Notes
VPNs
VPN services have gotten traction, recently, as more and more privacy scandals hit the airwaves. Most of them, however, are not all they’re cracked up to be. Many keep logs of exactly which traffic goes where, and so they are a weak point if anyone wants to track you down.
That said, you should probably still use one. Just pick one that doesn’t keep logs, and allows you to pay with anonymous options like cryptocurrency. Here’s a list of some of the better privacy-oriented VPNs.
Tor
Using Tor to anonymize your browsing can help, but remember that the network has been compromised before. It’s perfectly fine to use it so long as you realize it’s just one extra layer of security, and not a guarantee of safety.
That’s just what everything on this list is: a layer of security that can, with time, be peeled back. The rest is up to you.
For a while now, Sketch has been the application of choice for many UX and UI designers. However, we have lately seen many new contenders for Sketch’s position #1 as a universal UI design tool. Two apps that I think stand out mostly from the rest (and that have made the biggest strides in their development) are Figma and Adobe XD.
This article is oriented towards user interface designers and developers. I’ll try to summarize my thoughts on how Figma and Adobe XD compete with Sketch and what unique features each one of them brings to the table. I will also reference some other alternative apps that are aiming to become leaders in the same niche.
Note: To profit from the article, you don’t need to have prior experience with Sketch, Figma, or Adobe XD. Still, if you have some experience with at least one of these apps, it will certainly help.
The Sketch Competitors (And Where It All Started For Us)
A while ago, Adobe Fireworks was the preferred user interface design app for our entire team. Fireworks was flexible, easy to use, and with the help of many free extensions was fitting perfectly in our design workflow. When Adobe discontinued Fireworks, the only alternative we had left was Sketch. We made the switch (and it was an expensive one, considering we had also to move from Windows to Mac), but the gain in productivity was huge, and we never regretted the choice made.
For a while now, Sketch has been the application of choice not only for our team but for many other user interface designers. But in the last couple of years, a number of competitors started to seriously rival Sketch as the current tool #1. Given how rapidly these new competitor apps have improved, our team was tempted to try some of them out and even considered switching over. In this article, I’m hoping to give you a comprehensive comparison of the top contenders of Sketch in the UI design tools arena.
Although it feels like a week doesn’t go by without a new screen design app launching, only a few of them have matured enough to stand up to Sketch’s currently leading position. The two that I think come the closest are Figma and Adobe XD. Both apps have fully functional free versions — making the entry barrier for new users much lower.
XD has versions for Mac and Windows, while Figma supports Mac, Windows, Linux, and Chrome OS — pretty much any operating system on which a modern modern browser can be installed and run.
Comparing Sketch, Figma, and Adobe XD. (Large preview)
Figma
Figma is a web app; you can run it in a browser and therefore on pretty much any operating system. That’s one aspect completely in contrast with Sketch, which has been a Mac-only app. Contrary to my presumptions, Figma runs perfectly smooth and even trumps Sketch’s responsiveness in a number of areas. Here’s an example:
A lot has been said about how Figma compares with Sketch, but the race has only been heating up with the recent updates to both apps.
Figma’s success has the developers of Sketch reconsidering their native-only approach. The company recently raised $20 million to help it add more features — including a web version of Sketch app.
Adobe XD
Although an entire generation of designers grew up using Adobe Photoshop for design, it was never built with user interface designers in mind. Adobe realized this and started working from the ground up on a new app called XD. Although it took a while for XD to get up-to-speed with Sketch in terms of features, Adobe seems to have taken it very seriously in the last year. New features — and some of them quite powerful — are being added to the app almost every month, to a point where I can actually consider it a viable alternative at this point.
Others
Figma and Adobe XD are by no means the only contenders to Sketch’s leadership. Although it may seem like a new one joins the race every few weeks, some are clearly ahead at this point — just not in the same league as the ones above, in my opinion.
Framer X
Although Framer started off as a code based tool for creating prototypes, they have been steadily adding design capabilities. The latest iteration is Framer X, which can be termed as a UI design tool with the ability to code interactions and animations for finer control and flexibility.
InVision Studio
InVision started as the best way to share design mockups with colleagues and clients. Over the years though, they have added features to the app and also built Studio as a standalone app for UI design, prototypes, and animations. (Studio is probably based off of Macaw, which InVision bought in early 2016.)
Gravit
This is another UI design app that has been slowly but steadily improving in the background. Corel bought Gravit a few months ago, which means we might soon start seeing it gain more features and traction within the community.
“Another up and coming category of apps in this domain are the ones that combine design and code to output actual production-ready code that developers can directly use in their apps. Framer X actually does this to an extent, but apps like Alva, Modulz, and Supernova take things one level further. I will not dig into these here because all of them are in very early stages of development, but I wanted to point them out because that’s where the future of UI design tools seems to be headed.”
As a design consultancy, we — me and my team at Kritii Design — end up adapting to whatever toolset clients use. I saw the gradual shift from Photoshop to Sketch over the years, but in the last year or so we have seen a sudden switch from Sketch to Figma. Sketch is still the dominant tool in most teams, but Figma — and even XD in some cases — have begun to find favor with larger teams. I’m yet to come across a group that prefers any of the other options, but I’m assuming that divergence is not very far.
Similarities And Differences
I’ve been a Sketch user for three years now and consider myself a power user. I’ve been trying Figma on and off for about a year now, but much more so in the last couple of months. Adobe XD is fairly new to me — about a month since I started experimenting with it. As such, the comparison below is based on my experience with all three apps. I’ll also include snippets about other apps that seem to do certain things better, but it’s mostly just those three.
User Interfaces
I will not get into the details of the user interfaces of each app because all three share an almost identical interface: layers panel on the left, the canvas is in the middle, properties panel on the right, and tools toolbar at the top. Safe to say Figma and XD’s interfaces are heavily inspired by what Sketch started with.
Note: The right panel (which lets you control the properties of the objects on the canvas) is called Inspector in Sketch app, Properties in Figma Design, and Property Inspector in Adobe XD. They all do the same thing though.
The Basics: Artboards And Pages
When you create a new file in Sketch or Figma, you are on ‘Page 1′ by default, with a plain canvas staring at you. You can create artboards on the page, or add more pages. You can choose from a bunch of presets (for iPhone/Android phones, or for the web), or just drag any size you need.
Adobe XD does not support multiple pages yet. Just a canvas that you can add artboards to. Given how large some of my projects can get, I find this extremely limiting.
Artboards in Figma are called frames, and they’re much more powerful than Sketch. While Sketch stopped supporting nested artboards a few versions ago, Figma actually encourages nesting of frames. So you can have a frame for the screen, and then frames for the header, footer, lists, and so on. Each frame can have its own layout grid and can be set to clip content when resized.
The header, list and tab bar are frames nested within a frame for the entire screen in Figma. (Large preview)
When you create a new document in Adobe XD, it explicitly asks you to choose from a preset list of artboard sizes. You can choose “Custom,” of course. The preset selection in baked in the way XD lets you preview the designs. Anything beyond the preset height scrolls by default. When you increase the height of the artboard, XD adds a marker to show the original height of the device frame.
A blue line shows the height of the selected device’s viewport to help position content appropriately ‘above the fold’. (Large preview)
One thing Sketch does differently from the other two applications is that it adds a ‘Symbols’ page that holds all your symbols by default. You can decide not to send symbols to this page when you create them, but I’ve never seen anyone doing that. It actually makes a lot of sense to centralize all the symbols, so they are easy to organize.
Summary
Sketch and Figma support pages and artboards, although Figma’s artboards (or frames) — are more flexible because they can be nested. Adobe XD supports only artboards.
Grids And Layout
All three apps let you overlay grids on top of the artboards. In Adobe XD, you can use a square grid or a column grid. Sketch allows for both at the same time, plus allows for columns as well and rows in the layout grid.
Figma lets you add as many as you want of each type — grid, columns, and rows. Another example of the attention to detail in Figma — when you set the gutter to 0, it automatically switches from showing filled columns to showing lines only.
Comparing layout grid options in the three apps.
Figma takes layout grids a step further by allowing grids on frames (which can be nested) as well as individual components. One interesting possibility with the latter is that you can use them as guides for padding when working with resizable components.
All three apps also let you set constraints to define how elements will scale or move when their containers are resized. Moreover, they all employ an almost identical user interface to set and manage those constraints. Figma was the first of the lot with this UI concept. Sketch followed and improved upon it in their latest release, and Adobe XD introduced the feature in September 2018.
The object resizing and constraints UI in all three apps. (Large preview)
In Figma, constraints work only on elements inside a frame, not groups (like in Sketch and Adobe XD). It is mildly annoying because you can set constraints, but they just don’t work when you resize the group. But Figma does actively encourage you to use nested frames which are much more powerful than groups. Another advantage with Figma is that when using layout grids, constraints apply to the column or cell the element is inside.
In Figma, layout constraints apply to columns when a layout grid is added.
Summary
All three apps let you use grids and column layouts inside artboards. Figma’s implementation feels more powerful because you can nest frames and therefore have separate grids for sections of a screen. Support for constraints in all three is pretty good and more-or-less at par.
Drawing And Editing Tools
Neither of these apps have the advanced vector tools like Adobe Illustrator or Affinity Designer. What you get are the bare basics — rectangle tool, ellipse tool, polygon tool, and a free form vector drawing tool. Plus boolean capabilities to combine and subtract shapes. For most user interface design needs, these are just fine.
That is not to say that you cannot create complex vector artwork in any of these apps. The images below represent what each app is capable of, if you’re willing to spend the time learning all of the tools and features.
Sketch has been my staple design tool for a few years now and I’ve never felt the need to go to Adobe Illustrator for any of the icons and the occasional illustration I needed in my designs. You get the usual rectangle, ellipse and polygon shapes, a bezier tool for everything else, and even a freeform line tool that probably only makes sense if you use a tablet/stylus.
Figma has an advantage in this department due to what they call ‘vector networks‘. If you ever used Adobe Flash to draw, this will seem very familiar. Rather than try to describe it though, I’ll just show you what it does…
Figma’s vector networks in action.
Figma’s shape tools also feel a step ahead of Sketch. For ellipses, there is now the ability to easily carve out pies and donuts — a great feature for anyone who has tried to use Sketch’s dash settings to create donut charts. Corners of a rectangle can be dragged in to set the corner radius without bothering with the Properties panel.
Creating a donut chart in Figma.
Adobe XD falls behind here given it doesn’t even come with a polygon tool as of now. You also cannot align individual bezier nodes on a path, or change the roundness of these nodes — something we use very often to create smooth line graphs in dashboards.
Once you have added elements to your design, all three apps let you group them, arrange them above or below each other, align and distribute selected objects evenly, and so on.
One standout feature in XD is something called Repeat grid. It lets you create one item and repeat it in a list or grid, each with similar properties, but unique content. Figma’s answer to this is Smart selection. Rather than specify something as a list or grid, Figma lets you select a bunch of elements that are already a list or a grid, then arrange them by spacing them out evenly and easily sorting them via drag-n-drop.
Comparing XD’s Repeat grid feature with Figma’s smart selection.
Summary
Although none of the apps can hold a candle to the power of Illustrator or Affinity Designer when it comes to illustrations, they do provide an adequate enough drawing toolset for day-to-day UI design stuff. Figma’s vector networks place it ahead of the other two in terms of flexibility.
Symbols
All three apps support symbols — elements that all share the same properties and can be updated in one go. How they implement them though, changes quite dramatically from app to app.
Sketch
In Sketch, converting something to a symbol will send it to a page called “Symbols” by default, creating an instance of it in place of the selected elements. This clear separation between the symbol and its instances is by design. An instance of a symbol can only be updated in certain ways — size, text, images; while nested symbols can be updated via the Inspector panel on the right. To edit the original symbol, you can double-click it to go to the “Symbols” page and make changes. Any changes you make there will be applied to all instances of the symbol.
“You can set it so that symbols don’t get sent to the separate page, but I don’t know anyone who does that. Symbols in Sketch are designed to live on their own page.”
Starting with Sketch version 53, you can now select elements inside a symbol instance and then use the Overrides panel to change the content for just that element. This is an improvement from earlier when you could only select the entire instance.
Editing a symbol instance in Sketch.
Figma
In Figma, symbols are called components. When you create a component, it stays in place and is denoted as the ‘Master Component’. Copying it elsewhere in the design creates instances by default. Instances can be edited in a place like you would do with any other group, with the exception that placement of elements cannot be changed. You can change text, color, size and even swap nested symbols — all inline. This definitely feels more flexible than Sketch’s approach while at the same time putting adequate constraints in place as to not mess with the original component. For example, deleting the master component does not affect the instances. You can simply ‘recover’ the master component at any time and continue making changes.
Editing a component instance in Figma.
Adobe XD
Adobe XD’s symbols are the least powerful at the moment. It does not have the concept of a master symbol and instances. Every instance is a clone of the symbol, so any changes to any instance is applied to all the others. They’re also extremely limited in what you can customize per instance — which is basically text and background images.
All three apps support reusing symbols across files.
In Sketch, any file can be added as a library, which enables you to add its symbols and styles to any other file you have open. Changes made in the original library document can be synced in the files that use those symbols, as long as you open them and click the notification.
Adobe XD takes a more simplistic approach for its ‘linked symbols’. Copying a symbol from one document to another automatically links the two. Changes made to the symbol in any document show up as notifications in the others, giving you the ability to review and apply them within the other documents.
Figma’s approach is a centralized repository of components called ‘Team Library’. Everyone on a team with the right access can add components to the team library. Any changes made to the components in the library show up as notifications, allowing you to review and update them in the files you have open.
Summary
All three apps support symbols, but XD’s version is so basic it might as well not exist. Figma’s approach to editing a symbol — or component — instance is much more intuitive and powerful than Sketch’s, although the latter has been catching up in recent versions. Both have strong library features for easy management and collaboration.
Styles
Styles are one of the most basic elements of a design system. The ability to save sets of element properties, apply them to multiple elements and apply changes across the boards, is extremely helpful when working on medium to large design projects. All three apps include support for styles, but the implementation varies a fair bit.
Sketch supports two style types — text styles and layer styles. Text styles include all font properties, color, and effects. Layer styles include fills, borders, and effects. As is obvious from the names, text styles apply only to text elements and layer styles to everything else. Starting with version 52, Sketch lets you override styles for elements inside of symbol instances. This is a huge upgrade to the utility of symbols in Sketch, eliminating a lot of hacky ways you would have to go through in the past for something as simple as changing icon colors inside symbol instances.
Figma takes a dramatically different approach by making styles cascade. That means you can save styles for text (font, size, weight, line-height, etc.), colors or effects (drop shadows, blurs, etc.), and then mix and match them on elements. For example, the font properties and color on a text block are independently changeable. This makes it possible to have a different color for a word inside a paragraph, something you can’t do in Sketch.
Color, Text and Effect Styles in Figma. (Large preview)
Styles in XD are limited to character styles for text elements. You can save colors and apply them from the library, but there is no way to save a set of characteristics (fill, border, shadow, and so on) as an individual style.
Summary
All three apps support text styles. Sketch also has layer styles that can be applied to non-text elements. Figma breaks styles down by characteristic and lets you mix and match them to get the result you need. It can be more flexible or too open-ended, depending on what your use case is.
Designing With Data
One of my most used Sketch plugins is Content Generator, which allowed me to quickly populate my designs with realistic dummy data instead of the usual lorem ipsum and John Doe and the likes. With the release of version 52, Sketch eliminated the need for that plugin by introducing built-in support for importing data. Now you can easily add realistic names, addresses, phone numbers, even photos in your design. A couple of sets are built in, but you can add more as you need.
You can add and manage external data sets from Sketch preferences. (Large preview)
The Adobe XD team demoed some work-in-progress support for built-in functionality at Adobe’s MAX conference, but we don’t know when that will make it into the product itself. The one feature that has already made it in is the ability to drag-n-drop a TXT file onto an element in a repeat grid — or a bunch of images onto an image in a repeat grid — to populate all items in the grid with that data. What’s more exciting to me though, is the plugin ecosystem that is bringing in much more powerful ways of importing realistic and real-time data in XD. Case in point are the Airtable and Google Sheets plugins, which allow you to connect with the apps and pull in data from spreadsheets in real time.
Figma lags behind Sketch and XD in this regard. As of now, there doesn’t seem to be any way to populate realistic content inside elements in Figma, other than copy-pasting the bits of content one by one.
Summary
Adobe XD finally takes the lead with a much more capable API that lets you pull in live data, not just static data like Sketch does. Figma has a lot of catch up to do on this front.
Plugins And Integrations
This is where Sketch’s position as the most popular UI design application shines. With a huge library of plugins and new ones coming every few days, Sketch has no rivals when it comes to its ecosystem of plugins and integrations. From plugins for animation, prototyping and version control, helpers for managing text, styles, to connectors for popular apps, there is a plugin for everything you can think of. Here are some of my favorites:
A suite of super useful plugins, including prototyping, external data and library management. (You can read more about Craft for Sketch in Christian Krammer’s article “Craft For Sketch Plugin: Designing With Real Data.”)
A bunch of helpers for managing artboards in Sketch.
As the leader of the pack, Sketch also enjoys the largest list of integrations with third-party apps. Be it prototyping and sharing via InVision, developer handoff via Zeplin, version control via Abstract or Plant, most apps have direct integration with Sketch, with the ability to import, sync or preview Sketch files.
You can enable, disable, update and delete plugins from Sketch preferences. (Large preview)
Plugins in XD launched as recently as a few months ago, but things are already looking quite good. Adobe, with its marketing might, was able to get a lot of companies and developers onboard to launch their plugin ecosystem with a bang. Although not as vast as Sketch’s, the list of plugins for XD is pretty good and growing at a quick pace. Here are some highlights:
Bring real data from spreadsheets into your designs in real time.
The Airtable plugin I mentioned above is an example of app integrations that XD is quickly getting very good at. There are also integrations with usertesting.com, Cloudapp, Dribbble and more.
You can quickly browse and install plugins directly from inside XD. (Large preview)
As far as plugin management goes, XD does a much better job with a nice UI to find, read about and install all plugins. For Sketch, you need to find the plugin on the web, download it and launch the .sketchplugin file to install it. You can disable or remove them from the preferences screen, but not much else.
Figma falls short on the plugins front when compared to Sketch and even XD. It does not have a plugin API specifically, but Figma did open up some APIs for integrations with other apps earlier this year. Apart from built-in integration with Principle, Zeplin, Avocode and Dribbble, the result has been mostly things you can do with your files outside of Figma — like this PDF exporter, the ability to push assets from Figma to Github using Relay, and so on.
“We have watched as our competitors added extension models which granted developers freedom at the expense of quality, robustness, and predictability. We’re eager to leverage the incredible collective brainpower of the Figma community in making our tool better, but we’re not going to introduce extensions until we are confident our extension model is robust. There’s no estimated date just yet, but we are actively exploring how to build this in a solid way.”
Summary
Again, Figma has some catching up to do on the plugins front, especially when compared to Sketch’s huge ecosystem, or Adobe’s powerful APIs and marketing might to get more developers onboard.
Prototyping, Interaction, And Motion Design
Sketch and Figma started off as static design apps, whereas Adobe XD launched with the built-in ability to link screens together to build low-fidelity prototypes. Figma added the prototyping functionality in mid-2017, while Sketch added prototyping in early 2018. As of today, all three apps let you create prototypes and share them with others.
Sketch and Figma’s prototyping tools were mostly limited to linking individual elements to other artboards on click/tap or hover, with a limited selection of transition effects. Figma just pulled ahead with the introduction of overlays in December 2018. This — combined with the fact that Figma’s frames are more flexible than Sketch’s rigid artboard structure — opens up the ability to prototype menus, dialog boxes and more. Both apps have support for other prototyping apps, though. Figma has an integration with Principle and Sketch with pretty much every prototyping tool out there.
While Figma lets you share the prototypes with a simple link (the perks of being in the cloud), with Sketch you need to upload your file to the Sketch cloud before you can share it with others.
Comparing the prototype controls in Sketch and Figma. (Large preview)
Adobe XD’s October 2018 release pushed it way ahead in the race when it comes to prototyping. It now does everything I mentioned above, but includes two more powerful features:
Auto-animate
Where designers had to pull their designs into apps like Principle or After Effects to add motion design, some of it is built into XD now. It works by automatically moving elements with the same name when transitioning from one screen to another. This may sound simple, but the kind of effects you can generate are pretty spectacular.
Adding animations to prototypes using ‘Auto animate’ in XD.
Voice prototypes
You can now trigger interactions in XD by voice commands, and even include speech responses to triggers. This is a huge addition that makes it easy to prototype conversational user interfaces in XD, something that is not possible in Sketch, Figma, or any of the leading prototyping apps out there.
If animation is important to you, one app to look out for is InVision Studio. It has a timeline based animation workflow, something none of the other apps on this list can boast of. Or if you’re comfortable getting your code on, Framer’s code based interaction model is definitely something to explore.
Summary
Adobe XD has the most powerful prototyping toolset of the three apps, with voice and auto animate leading the way. Sketch has rudimentary prototyping capabilities, but Figma’s implementation feels more seamless when it comes to sharing and gathering feedback.
Collaboration
Sketch and Adobe XD are traditional desktop apps — built for designers to work in isolation and share their designs when ready. Figma, on the other hand, was built for collaboration in mind, more like Google Docs for designers.
In Figma, multiple users can work on the same document at the same time. You can see colored cursors moving around the design when others are viewing or editing the design you’re on. This can take some getting used to, but in situations where we have multiple designers working on a project, this can be a godsend. The cherry on top is the ability to view the design from another designer’s perspective. Just click the user’s avatar in the header and you can see exactly what she is seeing and follow along.
Collaborative design in Figma, à la Google Docs.
Going beyond collaborative editing, sharing your work is also more streamlined in Figma than in the other apps. You can either invite others to see or edit a design or simply send a URL to the design file or prototype preview.
Developers who are viewing the file can get specs for the design elements — a la Zeplin or Avocode — and export any image assets they need. The assets don’t even need to be set to export like in Sketch.
Note:For Figma designs, there are three levels of access: 1) owner 2) can edit, and 3) can view. We use “can view” to give developers access to all the specs, and the ability to export assets as and when they need them.
Figma also has a built-in commenting system which is important when reviewing designs with broader teams and clients. Today, I rely on a combination of Sketch and InVision to achieve this.
Sketch allows you to upload files to its cloud services, and then share a link for others to view. Ensuring that the latest version is in the cloud is up to you, though. This can be a big risk if you have developers working off of a design that may not be current. XD’s December 2018 release added the ability to save files to the cloud, and you can decide which files to save in the cloud and which ones locally. This addresses the problem with maintaining latest versions in the cloud.
Summary
This is where Figma’s web-based roots really shine. It leaves the other two far behind on the collaboration front with built-in sharing, commenting and the single-source-of-truth approach. Sketch and XD are adding sharing features at a good pace, but their file-first approach is holding them back.
Which One Is Right For You?
If you’re a user interface designer, you can’t go wrong with either of the three apps that I have covered here. Or the others that I touched upon just briefly. They all will get the job done, but with varying levels of productivity.
If a native desktop app is necessary for you, and you don’t care about a Windows — or a Linux — version, Sketch is the best bet right now. Adobe XD is getting better at breakneck speed, but it is not as good as Sketch yet for day-to-day design tasks.
If you’re on Windows though, or if motion design is part of your requirements, Adobe XD is your best shot. Sketch simply does not have any animation capabilities and it doesn’t look like that a Windows version could appear on the horizon any time soon. For animation, InVision Studio might also be something you can look at. And if you’re comfortable with code, Framer X provides the most flexibility of the lot.
For me though, at this moment Figma strikes the best balance between features, usability, and performance. Yes, you need to be online to use it (unless you have a file open, in which case you can edit it offline). No, it doesn’t have plugins or any animation capabilities. But if UI design mockups are your core requirement, Figma does a far better job for creating, sharing and collaborating with others than either Sketch or Adobe XD. It has a very generous free tier, it is available on any platform that can run a modern browser, and it’s very actively in development, with new features and updates coming in faster than I can keep up learning them all.
In my team, for example, there seems to be an even split between folks who prefer Sketch or Figma. I’m myself beginning to lean in on Figma myself, but also use Adobe XD every now and then for some quick motion design experiment.
And if you’re looking for an even shorter tl;dr summary — trust Meng To:
“My thoughts on design tools and why you should pick them.
Figma: collaboration and all-in-one
Sketch: maturity and plugins
Framer: code and advanced prototyping
Studio: free and animation
XD: speed and adobe platform”
“Multipurpose”, “all-in-one”, and
“universal” tools and products. You
heard of them before. They have a reputation for doing some things well, and
other things not very well at all.
We bet you also proverbial “Jack of all
trades, master of none” saying applies. it no longer does so in the world of
multipurpose WordPress themes.
There are plenty of good ones out there.
Admittedly, each has its unique strengths and weaknesses. But as you narrow
your search to the best of the bunch, weaknesses are inconsequential.
Select one of these 12 multipurpose themes
for your next project and guess what will happen.
When you go down the list of features of any premier multipurpose theme, you’ll usually like what you see. It feels good to have a theme that can handle anything you throw at it.
Be Theme’s list of features never seems to
end. Its 40 or so core features make Be Theme the biggest WordPress theme of
all.
The “key” features are naturally those you
have the most use for; but a key feature for every user is Be’s library of more
than 400 responsive, customizable pre-built websites. They cover 30+ different
business sectors, website types, and styles, and just about any business niche
you’re apt to get involved with.
Other features you’ll particularly like are
the new Header Builder, Muffin page builder, Options Panel, Layout Generator,
and Shortcode Generator. You’ll also have shortcodes and other design elements
and options galore to work with.
Download a pre-built website with a single
click, start building, and with Be Theme it’s not at all unusual to turn out a
fully-functioning website in as little as 4 hours.
Jupiter X is a total makeover of the popular Jupiter WordPress theme; the creation of Artbees, a member of the Power Elite Envato Hall of Fame. This new version is super-fast, powerful, scalable, and extremely developer friendly. With Jupiter, you can customize design and content elements that are normally difficult or impossible to customize in other themes.
Users can for example totally reinvent
their blog lists and portfolios, and the Shop Customize allows you to customize
online shop elements that in most other themes are simply off limits.
Headers and footers can be built from
scratch and you can customize every inch of your website using Jupiter X’s
powerful visual editor, and creating special forms, popups, and unique menu
styles is no problem at all.
Visit the Uncode website and you’ll be introduced to its website-building features. Nothing new here. Virtually every WordPress theme, multipurpose or not, does the same thing.
Where Uncode, one of the ThemeForest’s top
selling themes, is different from the rest is its showcase of user-built
websites. You can actually see what others have been able to accomplish using
Uncode, and you’ll be impressed – and perhaps inspired as well. We highly
recommend visiting the Uncode site for this reason alone.
Uncode’s advanced adaptive grid system,
adaptive images system, and more than 200 option-rich design modules should be
mentioned however, as should the hierarchical options feature that gives you
total control over your layouts and design content.
More than 150 exquisite pre-made layouts. More than 35 pre-eminent homepage designs. Blend in a premium responsive drag&drop page builder, a slider creator, and a host of intuitive design elements, we have Brook.
This multi-purpose creative theme features
a WooCommerce shop, numerable custom shortcodes, mega menus, one-page
scrolling, parallax scrolling, and many more to be listed. You’re invited to
pay a visit to their website for a full understanding of what Brook could do.
This developer-friendly theme offers an impressive array of theme options, blog, header, portfolio types (7 main types with options – 30 in all), shop items, a one-click demo content import and a premium page builders such as WPBakery Page Builder or Elementor. Kalium is extremely easy to use and offers endless possibilities. You should in fact be able to showcase your work as you’ve always wanted to the first time you use this theme.
TheGem lays claim to being the ultimate web design toolbox, and everything we’ve seen about it would seem to support that claim.
With its 150+ stunning demos pages, 50+
multi-purpose design concepts, flexible page layouts, and other design aids and
elements, TheGem is a great choice for startups looking for a way to let the
world know what they have to offer, and a great choice for other businesses,
large and small.
This #1 bestselling ThemeForest creative theme’s open-ended customizability feature, coupled with the premier WP Bakery page builder makes it a great choice for creating a website for virtually any business niche.
Other plugins add to this software tool’s
overall value as does its library of more than 376 pre-made websites that in
themselves guarantee to get any project off to a fast, solid start.
Modern, crazy-fast, and search engine optimized pretty much describes Pofo. Its 150+ pre-built websites, ready-to-go home pages and 1-click demo pages give you all the website-building flexibility you need. Pofo really shines in three key areas – portfolios, blogs, and eCommerce applications.
This
multipurpose theme with its more than 200 layouts to work with deserves much
more than a casual glance.
One way to
describe Kleo would be to simply refer to it as an adventure. This professional
community-focused website gives you everything you need to create a happy
community of shoppers.
Blogs, portfolios, eCommerce, community
forums and eLearning features – you name it. Kleo is also compatible with most
plugins; extending your website-building capabilities even more.
This website theme gives you a little extra for your money. If you’re quite capable of building beautiful websites, but have trouble getting traffic, you can count on Schema to save the day. In addition to its selection of impressive website-building features,
Schema improves your page load times, has
clean code, and guides the search engines through your site element by element.
This 5-star top-rated theme contains a few surprises that you will not want to let pass by; if you feel your websites could profit from an extra dose of sparkle and pizzazz. MOVEDO is the website designer’s answer to a magic wand.
MOVEDO takes ordinary images and makes them
move and takes static images and makes them appear to move. Website users love
it, and you’ll have fun figuring out ways to entertain them.
Crocal is the new kid on the block, having joined the neighborhood last January. It performs like an established pro thanks to an absolutely amazing adaptive grid system.
Created by a #1 rated ThemeForest Elite
author, Crocal is Gutenberg compatible, WordPress and GDPR requirements
compliant, and eager to strut its stuff.
Conclusion
We’ve
made your search for a better multipurpose WordPress theme a lot faster and
easier. You’re quite not done yet. You still need to find the one that will
best suit your needs. Or, the one that will take a little extra time and some
careful thought.
Don’t worry too much about struggling to
make the right decision. You really can’t make a wrong one with this group.
There is already an env() function in CSS, but it kinda came out of nowhere as an Apple thing for dealing with “The Notch” but it has made it’s way to be a draft spec. The point will be for UAs or authors to declare variables that cannot be changed. Global const for CSS, sorta.
That spec doesn’t seem to suggest how we’ll actually set those env() values just yet. If you want them now, the easiest way to fake them would be using regular ol’ CSS custom properties and simply not change them.
But if you want that env() syntax though, there is a PostCSS plugin for emulating it. The way the plugin handles them is through a JavaScript file that declares them.
Having them start life as JavaScript is interesting, as it means we could perhaps have a single place to set variables that are accessible both to JavaScript and CSS.
That’s what Harry Nicholls covers more in his article, “Why you should use CSS env()” like some gotchas when dealing with units and such. But if you really needed a single source for unchangeable variables in both CSS and JavaScript, then I’d say this is a good way to go — and could potentially be ripped out once support for env() formally arrives.
Hey CSS-Tricksters! Bryan Hughes was kind enough to take a concept from an existing post he published on converting to TypeScript and take it a few couple steps further in this post to elaborate on creating reusable base classes. While this post doesn’t require reading the other one, it’s certainly worth checking it out because it covers the difficult task of rewriting a codebase and writing unit tests to help the process.
Johnny-Five is an IoT and robotics library for Node.js. Johnny-Five makes it easy to interact with hardware by taking a similar approach that jQuery took to the web a decade ago: it normalizes the differences between various hardware platforms. Also like jQuery, Johnny-Five provides higher-level abstractions that make it easier to work with the platform.
Johnny-Five supports a wide array of platforms via IO Plugins, from the Arduino family, to the Tessel, to the Raspberry Pi, and many more. Each IO Plugin implements a standardized interface for interacting with lower-level hardware peripherals. Raspi IO, which I first created five years ago, is the IO plugin that implements support for the Raspberry Pi.
Any time there are multiple implementations that conform to one thing, there is a chance to share code. IO Plugins are no exception, however, we have not shared any code between IO Plugins to date. We recently decided, as a group, that we wanted to change this. The timing was fortuitous since I was planning on rewriting Raspi IO in TypeScript anyways, so I agreed to take on this task.
The goals of a base class
For those who many not be familiar with using class-based inheritance to enable code sharing, let’s do a quick walk-through of what I mean when I say “creating a base class to reuse code.”
A base class provides structure and common code that other classes can extend. Let’s take a look at a simplified TypeScript example base class that we will extend later:
abstract class Automobile {
private _speed: number = 0;
private _direction: number = 0;
public drive(speed: number): void {
this._speed = speed;
}
public turn(direction: number): void {
if (direction > 90 || direction < -90) {
throw new Error(`Invalid direction "${direction}"`);
}
this._direction = direction;
}
public abstract getNumDoors(): number;
}
Here, we have created a base class that we call Automobile. This provides some basic functionality shared between all types of automobiles, whether it’s a car, a pickup, etc. Notice how this class is marked as abstract, and how there is one abstract method called getNumDoors. This method is dependent on the specific type of automobile. By defining it as an abstract class, we are saying that we require another class to extend this class and implement this method. We can do so with this code:
class Sedan extends Automobile {
public getNumDoors(): number {
return 4;
}
}
const myCar = new Sedan();
myCar.getNumDoors(); // prints 4
myCar.drive(35); // sets _speed to 35
myCar.turn(20); // sets _direction to 20
We’re extending the Automobile class to create a four-door sedan class. We can now call all methods on both classes, as if it were a single class.
For this project, we’ll create a base class called AbstractIO that any IO plugin author can then extend to implement a platform-specific IO Plugin.
Creating the Abstract IO base class
Abstract IO is the base class I created to implement the IO Plugin spec for use by all IO Plugin authors, and is available today on npm.
Each author has their own unique style, some preferring TypeScript and others preferring vanilla JavaScript. This means that, first and foremost, this base class must conform to the intersection of TypeScript best practices and JavaScript best practices. Finding the intersection of best practices isn’t always obvious though. To illustrate, let’s consider two parts of the IO Plugin spec: the MODES property and the digitalWrite method, both of which are required in IO Plugins.
The MODES property is an object, with each key having a human readable name for a given mode type, such as INPUT, and the value being the numerical constant associated with the mode type, such as 0. These numerical values show up in other places in the API, such as the pinMode method. In TypeScript, we would want to use an enum to represent these values, but JavaScript doesn’t support it. In JavaScript, the best practice is to define a series of constants and put them into an object “container.”
How do we resolve this apparent split between best practices? Create one using the other! We start by defining an enum in TypeScript and define each mode with an explicit initializer for each value:
Each value is carefully chosen to map explicitly to the MODES property as defined by the spec, which is implemented as part of the Abstract IO class with the following code:
public get MODES() {
return {
INPUT: Mode.INPUT,
OUTPUT: Mode.OUTPUT,
ANALOG: Mode.ANALOG,
PWM: Mode.PWM,
SERVO: Mode.SERVO,
UNKNOWN: Mode.UNKNOWN
}
}
With this, we have nice enums when we’re in TypeScript-land and can ignore the numerical values entirely. When we’re in pure JavaScript-land, we still have the MODES property we can pass around in typical JavaScript fashion so we don’t have to use numerical values directly.
But what about methods in the base class that derived classes must override? In the TypeScript world, we would use an abstract class, as we did in the example above. Cool! But what about the JavaScript side? Abstract methods are compiled out and don’t even exist in the output JavaScript, so we have nothing to ensure methods are overridden there. Another contradiction!
Unfortunately, I couldn’t come up with a way to respect both languages, so I defaulted to using the JavaScript approach: create a method in the base class that throws an exception:
public digitalWrite(pin: string | number, value: number): void {
throw new Error(`digitalWrite is not supported by ${this.name}`);
}
It’s not ideal because the TypeScript compiler doesn’t warn us if we don’t override the abstract base method. However, it does work in TypeScript (we still get the exception at runtime), as well as being a best practice for JavaScript.
Lessons learned
While working through the best way to design for both TypeScript and vanilla JavaScript, I determined that the best way to solve discrepancies is:
Use a common best practice shared by each language
If that doesn’t work, try to use the TypeScript best practice “internally” and map it to a separate vanilla JavaScript best practice “externally,” like we did for the MODES property.
And if that approach doesn’t work, default to using the vanilla JavaScript best practice, like we did for the digitalWrite method, and ignore the TypeScript best practice.
These steps worked well for creating Abstract IO, but these are simply what I discovered. If you have any better ideas I’d love to hear them in the comments!
I discovered that abstract classes are not useful in vanilla JavaScript projects since JavaScript doesn’t have such a concept. This means that they are an anti-pattern here, even though abstract classes are a TypeScript best practice. TypeScript also doesn’t provide mechanisms to ensure type-safety when overriding methods, such as the overridekeyword in C#. The lesson here is that you should pretend that abstract classes don’t exist when targeting vanilla JavaScript users as well.
I also learned that it’s really important to have a single source of truth for interfaces shared across modules. TypeScript uses duck typing as its core type system pattern, and is very useful inside any given TypeScript project. However, synchronizing types across separate modules using duck typing turned out to be more of a maintenance headache than exporting an interface from one module and importing it into another. I had to keep publishing little changes to modules until I got them aligned on their types, leading to excess version number churn.
The final lesson I learned isn’t a new one: get feedback throughout the design process from library consumers. Knowing this going in, I set up two primary rounds of feedback. The first round was in person at the Johnny-Five collaborator’s summit where we brainstormed as a group. The second round was a pull request I opened against myself, despite being the only collaborator on Abstract IO with permission to merge pull requests. The pull request proved invaluable as we sifted through the details as a group. The code at the beginning of the PR bared little resemblance to the code when it was merged, which is good!
Wrapping up
Producing base classes destined to be consumed by both TypeScript and vanilla JavaScript users is a mostly straightforward process, but there are some gotchas. Since TypeScript is a superset of JavaScript, the two mostly share the same best practices. When differences in best practices do arise, a little creativity is required to find the best compromise.
I managed to achieve my goals with Abstract IO, and implemented a base class that serves both TypeScript and vanilla JavaScript IO Plugin authors well. Turns out, it’s (mostly) possible to have your cake and eat it too!
Part 3: Better Notifications UX And Permission Requests
Part 4: Privacy-Aware Design Framework
Imagine you are late for one of those meetings that you really don’t want to be late to. You hastily put on your shoes and your coat and fetch your door keys and grasp for the door handle — just to head out in time. As you are stepping down the stairs, you reach into your pocket and pull out your mobile phone to check the subway schedule or order a cab.
A brief glance at the screen is enough to have you breaking out in a sweat: you realize you’ve forgotten to charge your phone overnight, and it’s proudly running on its remaining 2% battery charge. As you rush down the street, full of hope and faith, you dim the brightness of the screen and hunt down the right app icon across the home screen. Of course, at that exact moment a slew of notifications cascades down your screen, asking for your undivided attention for new followers, updates, reminders, and messages.
Chances are high that you know way too well what this feels like. How likely are you to act on the cascading stack of notifications in that situation? And how likely are you turn off notifications altogether as another reminder reaches you a few minutes later, just when you missed your connection? That’s one of those situations when notifications are literally getting in a way in the most disruptive way possible, and despite all the thoroughly crafted user flows and polished, precious pixels.
With so many applications and services and people and machines and chatbots fighting for our attention, staying focused is a luxury that needs to be savored and protected, and so no wonder notifications don’t enjoy a decent reputation these days. More than that, often they feel off the point and manipulative, too.
“They often appear at times when they are least relevant, and they create a false sense of urgency, diluting focus and causing frustration.”
This goes for floating windows on the home screen as much as the almighty unread count in toolbars. This is also true for marketing messages masked as notifications, as well as social updates broken down in many small messages to permanently draw attention to the service.
All of these notifications demand immediate attention and feel incredibly invasive, playing on our desires not to miss out and stay connected with our social groups. In fact, they disrupt privacy in a way that no dark patterns can — by demanding and seizing attention unconditionally, no matter what the user is currently doing.
Can you spot anything weird in this particular design? It’s not common to see the notification count ‘0’, as it’s done on MassGenie in the top-right corner. (Large preview)
However, it’s not the fault of notifications that they feel invasive; it’s that we design them such that they often get in the way. Users don’t want to miss important notifications and miss out on timely messages or limited sales, but they don’t want to feel pestered by a never-ending tide of noisy updates either. If the latter happens too frequently, users turn off notifications altogether, often with a bitter aftertaste towards the app and brand due to its “desperate begging for attention”, as one user put it. A single culprit can ruin it for everybody else, and that despite the fact that no notification is like another.
The Many Faces Of Notifications
Notifications are distractions by nature; they bring a user’s attention to a (potentially) significant event they aren’t aware of or might want to be reminded of. As such, they can be very helpful and relevant, providing assistance, and bringing structure and order to the daily routine. Until they are not.
In general, notifications can be either informational (calendar reminders, delay notifications, election night results) or encourage action (approve payment, install an update, confirm a friend request). They can stream from various sources, and can have various impacts:
UI notifications appear as subtle cards in UIs as users interact with the web interface — as such, they are widely accepted and less invasive than some of their counterparts.
In-browser push notifications are more difficult to dismiss, and draw attention to themselves even if the user isn’t accessing the UI.
In-app notifications live within desktop and mobile apps, and can be as humble as UI notifications, but can take a more central role with messages pushed to the home screen or the notifications center.
OS notifications such as software updates or mobile carrier changes also get in the mix, often appearing together with a wide variety of notes, calendar updates, and everything in between.
Finally, notifications can find their way into email, SMS, and social messaging apps, coming from chatbots, recommendation systems, and actual humans.
You can see how notifications — given all their flavors and sources — could become overwhelming at some point. It’s not that we pay exactly the same amount of attention to every notification we receive, though. For the vast majority of users, it can take weeks until they eventually install a software update prompted by their OS notification, whereas it usually doesn’t take more than a few hours to confirm or decline a new LinkedIn or Facebook request.
Not every notification is equal, and the level of attention users grant them will depend on their nature, or, more specifically, how and when notifications are triggered.
In his article on “Critical Analysis of Notification Systems”, Shankar Balasubramanian has done remarkable research breaking down notification triggers into a few groups:
Event-triggered notifications
News updates, recommendations, state changes
OS-triggered notifications
Low battery, software update, or an emergency alert
Self-triggered notifications
Reminders or alarms
Many-to-one messaging notifications
Group messages from Slack or WhatsApp
One-to-one messaging notifications
Personal email from a friend or a relative
We can’t deduce that one group of triggers is always more effective than another, but some notifications from every group tend to be much better at capturing attention than others:
People care more about new messages from close friends and relatives, notifications from selected colleagues during working hours, bank transactions and important alerts, calendar notifications, scheduled events, alarms, and any actionable and awaited confirmations or releases.
People care less about news updates, social feed updates, announcements, new features, crash reports, web notifications, informational and automated messages in general.
Unsurprisingly, users tend to attend to low battery notifications or payment confirmations immediately; also, calendar reminders, progress updates (e.g. package delivery ETA) and one-to-one messages matter more than other notifications. In fact, in every single conversation we’ve had with users, a message from another human being was valued much higher than any automated notification. The priorities might change slightly, of course, if a user is impatiently awaiting a notification, but only few people would ever leave everything behind in a desperate rush to check the 77th like on their photo.
So notifications can be different, and different notifications are perceived differently; however, the more personal, relevant, and timely notifications are, the higher engagement we should expect. But what does it all mean for the design of notifications, and how can we make them less intrusive and more efficient?
Don’t Rely On Generic Defaults: Set Up Notification Modes
There is usually a good reason why customers have chosen to sign up for a service. Not many people wake up in the morning hoping to create a new account that day. In fact, they might feel like your service might help them in their daily tasks, or could improve their workflow. Hopefully they don’t need notifications to understand how a service works, but they might need to receive notifications to understand the value the service provides.
Perhaps they’ve received an important message from a potential employer, or perhaps there is a dating profile match that’s worth looking at. They might not want to miss these messages just because they’ve forgotten to check into the service for a while. As designers, we need to sprinkle just the right pinch of notifications into the mix to keep the customer motivated, while delivering only relevant and actionable pointers to them.
Unfortunately, with most services it’s not uncommon to sign up, only to realize a few moments later that the inbox is filling up with all kinds of messages (mostly purely informational), often sent immediately after another, and rarely actionable. Email notifications especially are often switched on by default, with the user’s consent implied by agreeing to lengthy and unmanageable terms and conditions. Nobody loves being bombarded with a stream of unsolicited messages, and that holds true for spam emails as much as for unwanted notifications.
Instead of setting up a default notification frequency for all customers by default, we could start sending just a few curated notifications very infrequently. As the customer keeps using the interface, we could ask them to decide on the kind of notifications they’d prefer and their frequency. The same goes for cookie consent prompts: we could provide predefined recommended options with a “calm mode” (low frequency), a “regular mode” (medium frequency), and a “power-user mode” (high frequency).
We could be more granular even than this, though. Basecamp, for example, has introduced “Always On” and “Work Can Wait” options as a part of their onboarding experience, so new customers can select if they wish to receive notifications as they occur (at any time), or choose specific time ranges and days when notifications can be sent. Or, the other way around, we could ask users when they don’t want to be disturbed, and suspend notifications at that time. Not every customer wants to receive work-related notifications outside of business hours or on the weekend, even if their colleagues might be working extra hours on Saturday night on the other side of the planet.
On Basecamp, new customers can select if they wish to receive notifications as they occur, or choose specific time ranges and days when notifications can be sent. (Large preview)
As time passes, the format of notifications might need adjustments as well. Rather than having notifications sent one by one as events occur, users could choose a “summary mode,” with all notifications grouped into a single standalone message delivered at a particular time each day or every week.
That’s one of the settings that Slack provides when it comes to notifications; in fact, the system adapts the frequency of notifications over time, too. Initially, as Slack channels can be quite silent, the system sends notifications for every posted message. As activities become more frequent, Slack recommends reducing the notification level so the user will be notified only when they are actually mentioned.
Another feature Slack offers is allowing users to highlight a selection of words so that the users only get notified when a topic they care about has been mentioned:
With this feature, it’s still important to remain selective about your choice of highlighted words in order to avoid getting too many notifications. (Image source: Slack) (Large preview)
It might sound like the frequency of notifications is receiving too much attention at this point, but when asked about common pain points with notifications, the most common issue was, by far, their high frequency, even if the messages were relevant or actionable.
The bottom line is: start sending notifications slowly but steadily; set up notification modes, and provide granular options such as a choice of triggers and the format of notifications. Better send too little than too much: you might not get another chance should the customer wish to opt out from numerous notifications that are getting on their nerves at just the wrong time.
Pick Timing Carefully
We might not like to admit it, but for many of us, the day doesn’t start with a peaceful, mindful greeting of the rising sun; instead, it starts with a tedious, reflexive glance at the glowing screen of our mobile phones. More specifically, the first thing we see every morning isn’t even the current time or our loved ones, but the stack of notifications that piled up tirelessly while we slept.
That state of mind isn’t necessarily the best opportunity to remind users of an updated privacy policy, shiny new features, or outstanding expenses that need finalizing. Personal notifications like new social shares and reactions from social circles might be way more relevant, though, just like upcoming appointments and to-dos for the day.
Timing matters, and so do timely notifications. You probably don’t want to disturb your customers in the middle of the night as they arrive at a remote destination with heavy jet lag. Therefore, it’s a good idea to track the change of time zones and local time, and adjust the delivery of notifications accordingly. On the other side, customers won’t be particularly happy about an important notification appearing when it’s no longer relevant, so if they are tracking an important event or announcement, you’ll have to decide if the event is critical enough to disturb them at an uncomfortable time.
Your analytics will tell you when your users are likely to act on your notifications, so it’s a good idea to study and track responses based on time, and trigger the dispatch of notifications around that time. For example, if a customer is most receptive to sharing a message in the mornings, hold off notifications until just the right moment at the local morning time.
There are many ways to present a notification. Most common notifications are displayed within a designated area, usually in the right top corner of the screen. It is the format we are used to from apps such as Facebook, Airbnb or Dropbox. (Image source) (Large preview)
Avoid Stressful Situations By Design
With notifications, timing is not the only important attribute to consider. Remember the poor character hoping to catch their connection from the beginning of this section? Unleashing a deck of notifications at a critically low battery level isn’t a good idea, and it’s just as counterproductive when the user is struggling with connectivity or is focused on a task like driving a car. If you can assess the battery level and the quality of connection, it’s a good idea to avoid sending notifications when a user’s conditions are suboptimal. Of course, notifications also have to be relevant, so if you can assess user’s location too, avoid sending location-dependent notifications that are not applicable at all.
Sometimes it’s difficult to hold notifications as they might be critical for the user’s current activity. If the user is driving a car, following directions in a navigator app, you might need to provide a more persistent and humble notification about the recommended change of route due to an accident on the road. In that case, just like other critical notifications, we could display a floating button “New updates available. Refresh.” It’s much less invasive than a notification blocking access to the content, but it’s as effective in indicating that the page or state of the page might be outdated and new information is available.
In fact, instead of sending out notifications at specific default times, even if it’s based on the user’s past behavior, you could explore the other side of the coin and tap into happy and successful moments instead. A money transfer service, TransferWise, displays notifications when the customer receives a payment — and isn’t that wonderful timing to ask for an app review on App Store? We could track important milestones and notify users about advanced features as they are reached, just-in-time, as Luke Wroblewski calls them.
Reduce Frequency By Grouping Notifications
There is no golden rule for just the right amount of notifications on a given day. Just like every notification differs, so do the preferences and motivations of every customer. To keep a user’s engagement, you might need to gradually release blocks of notifications depending on the customer’s reach or preferences. That’s where gradual grouping comes into place, as explained in the article “Designing Smart Notifications” by Alex Potrivaev, product designer at Intercom.
The idea is simple. If you know your customers get less than five reactions per post on average, it might be a good idea to provide a unique notification for each of them. You might also trigger a notification if a message is coming from important events, such as a message from close friends, family, or influential people. Besides, as we know that notifications triggered by an action from another human being are valued more than automated notifications, prioritize and focus primarily on personal ones, for that particular customer.
Once the volume of notifications has increased, we can start grouping them and provide compact summaries at an appropriate time. For example, Facebook summarizes notifications in non-intrusive blocks, with every line highlighting exactly one type of event, such as reactions to a particular message (“Stoyan Stefanov and 48 other people reacted to your post…”). LinkedIn, on the other hand, seems to trigger almost every single event one by one (“Stoyan Stefanov commented on your post”), hence polluting the stream of notifications and making them difficult to scan and use.
The quality of notifications matters. While Facebook provides a compact summary view of notifications, on Quora they are lengthy and verbose, making scanning difficult. (Image source: Designing Smart Notifications) (Large preview)
Of course, based on a user’s history, we could customize more than just grouping of notifications. Once we know how a user reacts to new photo likes, whether they briefly glance at them or dive deep into each and every notification, we can provide better notifications next time. As Alex concludes:
“Based on the way you usually interact with content, better wording and structure choices could be offered, and depending on the default behavior you may see notifications structured differently.”
This, of course, also requires continuous feedback loops.
Allow Users To Snooze Or Pause Notifications
Hardly any company will dismiss the value of data about their customers. In fact, we can gain valuable long-term insights by introducing feedback loops; that is, continuously offering customers options to “See more” or “See fewer” notifications of a particular kind. But just like we tend to perceive disability as an on/off condition (you either have a disability or don’t), we often feel that we can accurately predict the user’s behavior based on their past behavior alone.
The reality, however, is rarely black and white. Our users might be temporarily hindered while holding a baby in one arm, or because of a recent unfortunate accident, and the conditions in which they find themselves can fluctuate in the same way. Quick actions such as snoozing in response to an incoming notification can help alleviate the issue, albeit temporarily.
The user’s context changes continuously. If you notice an unusual drop in engagement rate, or if you’re anticipating an unusually high volume of notifications coming up (a birthday, wedding anniversary, or election night, perhaps), consider providing an option to mute, snooze, or pause notifications, perhaps for the next 24 hours.
This might go very much against our intuition, as we might want to re-engage the customer if they’ve gone silent all of a sudden, or we might want to maximize their engagement when important events are happening. However, pressing on with the frequency of notifications is just too dangerous most of the time. It’s easy to reach a point when a seemingly harmless notification will steer a customer away, potentially even in the long term. There might be good reasons why the user hasn’t been or doesn’t want to be active for a while, and more often than not, it has nothing to do with the service at all.
Another option would be to suggest a change of medium used to consume notifications. Users tend to associate different levels of urgency with different channels of communication. In-app notifications, push notifications, and text messages are considered to be much more intrusive than good ol’ email, so when frequency exceeds a certain threshold, you might want to nudge users towards a switch from push notifications to daily email summaries.
In the article “Designing Notifications For Apps”, Shashank Sahay explores different notification models and when to use which, e.g. notification center, with a few guidelines and recommendations along the way. (Large preview)
Set Thresholds And Build Up A Notifications Decision Tree
The thresholds aren’t easy to set properly, though. Important events should trigger immediate notifications to be received in time. Less important events could wait, but it might be useful to draw the customer’s attention to the service. Potentially irrelevant notifications have to be filtered out relentlessly to leave time and space for important notifications to be cherished and valued.
In general, shorter notifications, such as messages from friends and colleagues, are best suited as UI notifications if they aren’t urgent, or push notifications if they are. Lengthier notifications are better off as emails — whether they’re urgent or not. This rule of thumb would vary from service to service, so you could build up a notifications decision tree to track which medium works best for particular kinds of notification based on their urgency, length, and frequency. Additionally, you could define thresholds and trigger a prompt for snoozing or adjusting the settings if a threshold is reached.
Make Opting In And Opting Out Obvious
These days it’s almost expected for a service to go to extremes in making it ridiculously difficult for a customer to opt out from almighty notifications. Obscure wording and obscure labels skillfully hidden in remote corners of the interface are not uncommon. Few other design considerations can be more harmful and damaging for a brand. When users can’t adjust settings easily, they apply heavy artillery, marking email notifications as spam, or blocking notifications in OS settings or browser settings. For a website or an app, there is no easy way to recover from that, except begging for subscriptions yet again.
A much simpler way out is to provide very granular control over notifications, including their content, format, frequency, and do-not-disturb times. We could provide an option to reply to a recent notification with “Fewer emails” or “Stop” to change the frequency, bypassing website log-ins or app sign-ins (Notion.so does that). For apps, provide notification preferences integrated into the app rather than relying on OS native settings. There, you could also explain what the user can expect from every kind of notification, perhaps even with examples of how they would look.
In practice, many users will search for notification settings in both places if they really need to, but the longer it takes them to find that nebulous setting, the less patient they’ll be. In reality, most users seek a way of turning off notifications at the moment when they are actually frustrated or annoyed by recent notifications. That’s not a pleasant state of mind to be in, and as a service, you probably don’t want to unnecessarily extend that state of mind at the expense of feeling nagged and confused by your paying customers.
Don’t forget to explore the other side of the coin as well, though. Identify parts of the user journey when a user is more likely to subscribe to notifications; for example, once an order in an online shop has been successfully placed, or a flight booking has been confirmed. In both cases, notifications can help customers track delays or retrieve boarding passes in time. That’s also a good time to suggest real-time push notifications, which also means first asking the customer’s permission to send those reminders. And that topic deserves a separate conversation.
Asking For Permission, The Humble Way
Some websites are quite a character, aren’t they? Self-indulgent, impolite at heart, and genuinely unlikeable too. How often do you stumble on a seemingly modest, unpretentious page just to be greeted with a wondrous permissions prompt begging to send you notifications? You haven’t read a single word yet, but there it is, already asking for a long-term commitment — and frankly, quite an invasive one.
In terms of user experience, displaying a permission prompt on load is probably the best way to make a poor first impression, and in most cases an irreversible mistake. Starting from January 2019, Chrome has changed the options displayed when a native prompt is triggered. While users might be able to dismiss a notification to react to it later, now they have to choose whether they’d like to either “Accept” or “Block” notifications. The latter results in web notifications being permanently blocked for the entire site, unless the user finds their way through the wilderness of browser settings to grant access after all. No wonder the vast majority of users block such prompts right away, without reading their contents at all.
Strategically, it’s better to ask permission only when there is a high chance a user would actually accept. For that to happen, we need to explain to the customer why we actually need their permission, and what value we can provide them in return. In practice, this strategy is often implemented in form of the ‘double request pattern.’ Instead of asking for permission immediately, we wait for a certain amount of engagement first: perhaps a couple of page visits, a few interactions, a certain amount of time spent on the site. Eventually, we can highlight the fact that a user could subscribe to notifications and how they might be valuable, or that we need their permission for more accurate, location-aware search results. Sometimes the context of the page is enough, like when an interface would like to ask for geolocation when the user visits the store locator page.
In all of these cases, a prominent call-to-action button would wait for the moment when a user is most receptive to act on it. If the user chooses to tap on the button, we can assume they are likely to proceed with the action. So, once clicked, the button would prompt an actual native permission request.
Essentially, we are breaking down the permission prompt into two requests:
A request built into the UI,
A native request at the browser level.
As Adam Lynch notes, should the user still revoke permission, perhaps due to a mis-tap or mis-click in the native browser prompt, we need to display a fallback page that explains how to manually enable the permission via their browser settings (or link to an explanation). Obviously, it doesn’t make sense to display a request for notifications if the user has already granted permission. We can use the Permissions API to query the status of any permission through a single asynchronous interface and adjust the UI accordingly.
The same strategy could be applied to any kind of permission request, such as access to geolocation, camera, microphone, Bluetooth, MIDI, WebUSB, and so on. The wording and appearance of UI notification prompts is of critical importance here, though, so it’s a good idea to track engagement and acceptance ratios for each permission or feature, and act on them accordingly. And that brings us to the king of them all — tracking major metrics for your notifications.
Track Metrics For Notifications
Usually notifications aren’t sent for the sheer purpose of informing customers about an occurring or upcoming event. Good notifications are useful and actionable, helping both customers and businesses achieve their goals. For that, relevant metrics have first to be discovered and defined.
As a bare minimum, we might need to know if the notifications we send are relevant in the first place.
Do the wording, format, and frequency of notifications drive the desired action that we aim to achieve (be it social shares, time spent on the site, or purchases)?
What kind of notifications matter more than others?
Do the notifications actually bring users back to the application?
How much time passes between sending the notification and the user’s return to the site or app?
How much time is spent on average between the clickthrough notification and the user leaving the site?
Experiment with wording, length, dispatch times, and grouping and frequency of notifications for different levels of user involvement — beginner, regular user, and power user. For example, users tend to be more receptive to conversational messages that feel more casual and less like system notifications. Mentioning the names of actual human beings whose actions triggered a notification might be useful as well.
It’s never a bad idea to start sending notifications slowly to track their potential negative impact as well — be it opt-outs or app uninstalls. By sending a group of notifications to a small group first, you still have a chance to “adjust or cancel any detrimental notification campaigns before it’s too late,” as Nick Babich remarks in “What Makes A Good Notification”.
All these efforts have the same goal in mind: avoiding significant disruption and preventing notifications fatigue for our customers, while informing them about what they want to know at about the time they need to know it. However, if cookie prompts are just annoying, and frequent notifications are merely a disturbance, when it comes to the security of personal data and how it’s managed, customers tend to have much more pressing concerns.
It’s worth noting that there are significant differences in how notifications are requested, grouped, and displayed on Android and iOS, so if you are designing a native or a hybrid app, you’ll need to examine them in detail. For example, on iOS, users don’t set up app notifications until onboarding or a later usage of the app, while Android users can opt-out from notifications during installation, with the default behavior being opt-in. Push notifications sent by a PWA will behave like native notifications on a respective OS.
?
Admittedly, these issues will not be raised immediately, but as customers keep using an interface and contribute more and more personal data, doubts and concerns start appearing more frequently, especially if more people from their social circles are involved. Some of these issues are easy refinements, but others are substantial and often underestimated blockers.
In the final article of the series, we’ll be looking into notifications UX and permission requests, and how we can design the experience around them better, with the user’s privacy in mind.
An Event Apart Boston is almost here! We’re talking, like, less than a month away. If you’ve been holding off from registering, this might be your last chance because time and seating are both limited. Besides, we’re talking about three days of pure knowledge-dropping by an impressive lineup of speakers on a wide range of topics. Seriously, just look at the full schedule and prepare to be get stoked for a great time.
But, if a couple of weeks until show time is a little too tight for your liking, that’s where An Event Apart has you totally covered because there’s another one taking place in Washington D.C. this summer. And three more throughout the rest of the year in Chicago, Denver and San Francisco.
The reason an Event Apart is so near-and-dear to the CSS-Tricks family is that it scratches a common itch that we see come up around here often: how can we possibly stay on top of our careers as front-enders when our industry is changing at lightning speed and when we’re all-consumed trying to keep on top of our actual jobs? An Event Apart is our chance to take intention time away from the day-to-day and invest in our careers by learning from some of the best in the business, meeting folks who do what we do, and having those micro-interactions with others in the hallways that spark the interesting types of dialogues you just can’t get from Twitter.
Think about it: 17 speakers over three days covering everything from design systems and Progressive Web Apps to variable fonts and CSS Grid Layout. There’s so much to gain by attending. Just look at the awesome takeaways Chris got from An Event Apart Seattle in March.
And, to sweeten the pot, An Event Apart gave us a special discount code for CSS-Tricksters like yourself. Enter the AEACP at checkout to knock $100 off the price.
I work out of a small office in a co-working environment. Next to my dedicated space is a hot-desking area used primarily for video conferencing. Thanks to a bank of west-facing windows, an overenthusiastic heating policy, and unseasonably hot weather, meetings are often conducted with the doors open, and it’s then that I overhear some of the most engrossing insights into the minds of both clients and designers, that I’ve ever encountered.
Last week, as I munched on my lunch, I was eavesdropping on a meeting to determine the design direction of a fairly well known site (that will remain anonymous). The owner was connected from Australia, there were high-up members of the team connected from the US, and the UAE, and the design/dev team was about 10ft from me.
The conversation was increasingly heated, and centered around the fact that one of the design team had been removed from the project: such-and-such was a great person, and really dedicated, but her design style was all wrong; things had gone off the rails since such-and-such left; such-and-such did beautiful work, but it didn’t test well with users; and so forth.
Material Design…is seen as the standard to aspire to
The management team were clearly desperate to uncover a new design direction in which to take the service, and the design team were clearly desperate to accommodate them. After several hours of back and forth based on little (as far as I could hear) but subjective opinions, someone uttered a phrase that almost made me crash the meeting with subjectives of my own:
“Why don’t we just use Material Design?”
I’m not sure who said it, but it sounded like it was in the room. What followed was a cacophony of praise for Google’s design system: The designers admired it, the one developer I could identify loved it, the owner hadn’t heard of it but loved Google’s business model, the UX Lead—who until this point, I hadn’t heard contribute anything, said it was the “ultimate refinement of human-centered design”.
Five minutes later the meeting wrapped, a design direction chosen, a design team clutching a set of guidelines, a development team mentally mapping components. Leaving me, watching in horrified fascination as they filed back to their respective offices.
An Unhelpful Question
Material Design is astronomically popular. So popular in fact that I’ve spoken to numerous designers who refer to their work as “Material Design” when they have either never read the specification, or are ignoring it entirely.
Of course, there’s no reason that designers should implement Material Design. It’s simply an indication of its omnipresence that it is seen as the standard to aspire to.
The question posed in that meeting (Why don’t we just use Material Design?) reverses the design process in a way that epitomizes the problem with any design system. The question that should have been asked was: “Would employing Material Design solve some, or all, of our problems?”
If It’s Good Enough For Google
There’s an assumption that Material Design, as published by Google, is a magic bullet that addresses most, if not all, challenges in modern web design. I think that assumption probably stems from the fact that the Material Design specification is well written, and feels authoritative. I also think that assumption is false.
Material Design was initially intended as a solution to Google’s design problem—unifying a disparate group of services and apps, into a single brand identity and experience. It is now described as “a comprehensive guide for visual, motion, and interaction design across platforms and devices.” Which you have to admit, sounds pretty awesome.
when the insects take over the earth there will still be Google products about to receive their long-awaited Material Design upgrade
Just last week, there were reports in the design news that another Google product was about to receive its long-awaited Material Design upgrade. It doesn’t matter when you’re reading this, when the insects take over the earth there will still be Google products about to receive their long-awaited Material Design upgrade.
At the time of writing, it’s been five years since Google went public with Material Design. In that time, Google’s products have been constantly revised. Anything that hasn’t been updated in five years is probably at least mothballed— Google is far from shy when it comes to killing off projects.
If Google itself struggles to implement Material Design, and it has the get-out-of-jail-free card of writing (and rewriting) the specification with its own product demands front and center, how difficult is it to apply it to a third party site or app?
Don’t Even Get Me Started on That Floating Button
Probably the most controversial element of the Material Design specification is the floating call-to-action button that hovers in the bottom right of the screen, joyfully obscuring the single piece of content you are trying to access.
Material Design, means restructuring the architecture of your site
Design thinking is split on the floating action button, and anecdotally I’d say it’s roughly an even split. Some designers love the forced simplicity of a single call-to-action button imposing a primary action on a screen. Other designers object to an over-simplified user journey when natural experiences tend to be more nuanced.
In many cases implementing Material Design, means restructuring the architecture of your site or app. In other words, for the sake of an aesthetic your project needs to conform to Google’s preferred approach.
When all You’ve Got is Material Design, Everything Looks Like Gmail
There’s truth in the pop-wisdom that, when all you’ve got is a hammer, everything looks like a nail.
we’ll look for problems that don’t exist, in order to explain the solutions we have to hand
There are as many design approaches as there are designers and it would be preposterous of me to say “design is…” and expect it to be universally true. However, design, when done well, isn’t about putting a shiny polish on a project, design is inherent to what the project is, and to what it aims to become.
By framing a project in Material Design — or to any other design system — we are presented with a set of answers to which, as rational cause-and-effect minds, we will try to find questions. This means two things: firstly we’ll very likely distort our problems to fit those solutions because they’re the only solutions available that don’t break the specification; secondly we’ll look for problems that don’t exist, in order to explain the solutions we have to hand.
Why Don’t We Just Use Material Design?
Material Design is a design system, not the design system. Its failings are the failings of all design systems when applied to third party projects; namely that it is driven by a different, often undisclosed, set of priorities.
Of course, it’s entirely honest to confess that many designers dislike Material Design because it’s mind numbingly boring to implement someone else’s ideas. After all, we didn’t get into design to abandon creative thinking in favor of a paint-by numbers, one-size-fits-all approach.
Personal preference aside. We shouldn’t be using Material Design, because it puts the cart before the horse. It is a set of solutions to someone else’s set of problems. It may eventually work for Google, but it won’t work for you.
“The customer only cares about money and earnings, while the designer only cares about being able to publish a good job on Dribble or Behance.”
This is a concept that I saw represented in a viral video, produced by Pixelo showing the differences between the designer and the client. Things like “the customer wants bright colors at random, the designer chooses a well-considered palette”, etc.
As soon as I saw this part about money, though, I said to myself: is that really true?
Are there really so many designers who only think about their image return and not about improving their customers’ business?
Absolutely yes. Full.
And this led me to write this article in which I talk about what I think is the biggest mistake a freelancer designer can make when dealing with a client.
Why the biggest mistake?
Because if you ignore the side of the business in your work as a graphic designer, web designer and designer in general, you are ignoring half of your work.
Let’s start by first understanding what design is:
What is design?
But wait, are you serious? I’m a designer / studio design! Do you expect me not to know what design is?
Of course, we all know what design is.
True, design is planning. But what is missing in this definition is that design is planning… on commission.
Design is not art as an end in itself. Design, as well as graphics and communication, serves to sell! Excuse me if I write it so directly, but it helps those who have a business to make more money. Communicating better and therefore selling better.
I know this can be a “blow” for all those with the romantic idea of ??design as something artistic, abstract and maybe even a bit poetic.
Design = Business.
Design = Marketing
If you don’t understand this, or pretend you don’t understand it, you’ll always be a half designer. Or rather, you will be a designer who will not be able to help your client 100%.
Design = Business. Why is this so important to understand?
It is important to understand this if you want to succeed as a freelance designer. Because customers are always people or groups of people who relate to their company and only pay for the things that interest them.
The customer doesn’t care if the project comes out cool enough to be published on Behance.
The customer is only interested in how and how much you can help them improve their business. To make more money.
And rightly so.
This is an aspect that many designers do not understand. They don’t understand it when they ask for a €1000 logo for a local non-profit association, they don’t understand it when they create a project that is cool for them but doesn’t consider the client’s business needs and they don’t understand it when they complain because it does relate to the customers.
Want to be one of those freelancers?
If you’re reading this article up to this point, I’d say it’s not what you want to do, is it?
The solution to the problem: change your mentality
The best way to solve this problem of approach with the customer by the freelancer designer is to have a sudden change of mentality.
Such as? Try following these 2 practical tips:
1. Stop considering customers as piggy banks
Stop considering the customer as someone to get as much money as possible and then adios! Start looking at it as a resource. Start thinking long term about how you can extend your working relationship over time to help both.
Start thinking about how you can help your client in every aspect that competes for you in terms of communication or design. Even if they are small consultancies that go slightly beyond the contract you signed.
When I am commissioned to do a job (and accept it) I find myself very often talking to the client about future prospects and ideas that I’ve come up with. Even if they choose not to hire me in the future, at least I’ve shown that I’m willing to continue working with them, and it’s not just about the paycheck. It’s about helping them succeed.
I believe it is part of my job to help my client’s business in every possible way.
And this attitude has led me to have customers who come to me for all the jobs after the first one, creating a constant revenue stream and a solid working relationship.
2. Start thinking of yourself as a company and not as a freelancer
And by this I don’t mean that you go to interviews with customers and pretend to be the head of a company with 50 employees.
But it is certainly true that your freelancer business is not like an employee’s. Your business is actually a business.
You have to think about accounting, income, expenses, taxes, bills to pay and salaries (yours). All aspects that make you a business.
So why not have the same kind of attitude?
Why not develop long-term working relationships that allow your company to support itself? Why not develop products and activities for customers? Why not introduce yourself as the manager of your own company instead of as the freelancer who “you tell me what I have to do and I do it”?
In short: you too are a company, act as such!
Take care of your personal brand, build your bomb-proof portfolio, create your own blog with the most effective case studies you’ve worked on, networking at events and meetings, proposing yourself as the manager and not as the executor.
Conclusion
At the end of this article I hope I made you change your mind at least a little about the kind of attitude with which to approach the world of freelancer work and maybe give you some interesting and useful ideas for your career.
In summary: design is a business, the customer has a business and thinks only of that and how you can help them make more money. You are in business as a freelancer, which means you should take every opportunity to help your customer succeed.
This week, Chris Ferdinandi examined a clever JavaScript snippet, one that’s written creatively with new syntax features, but is perhaps less readable and performant. It’s a quick read, but his callout of our industry’s fixation on cleverness is worth… calling out:
…we’ve become obsessed as an industry with brevity and clever code, and it results in code that’s sometimes less performant, and typically harder to read and make sense of for most people.
He made a similar argument late last month when he wrote about code readability, noting that brevity might look cool but ultimately leads to all sorts of issues in a codebase:
Often, web developers are obsessed with brevity. There’s this thing were developers will try to write the same function in the fewest number of characters possible.
Personally, I think brevity is pointless. Readability is a lot more important.
I entirely agree with Chris on this point, however, I think there is one important distinction to make and that’s the difference between code that’s intended as a prototype and code that’s intended for production. As Jeremy Keith argued a short while ago:
What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes.
I agree with Chris that we should be writing code that is easy to read when we’re in production. I also think experimenting with code in this way is a good thing when it comes to prototypes. We shouldn’t ever shy away from playing with code and pushing things a little bit – so long as we’re not doing that in a giant web app with a a team of other developers working alongside us.
I’ve noticed that there are some folks that are doing genuinely ingenious things with Sass. I consistently sit back and think, “Wow, I’ve never seen anything like this before.” But when it comes to a production web app that has to be understood by hundreds of people at the same time, I don’t believe that this is the reaction we want when someone looks at the code.
As a result, I’ve been trying to write Sass code that is actually so simple that it almost looks dumb. One easy way to make code a lot simpler is to reduce the amount of nesting:
.element {
.heading { ... }
}
This looks fine when there’s code inside — and it’s pretty easy to understand — but add a complex bit of design in the mix (say, using pseudo elements and media queries) and you suddenly have a rather complex set of rules in front of you. Creativity and cleverness can be harder to scan and identify one small part of the code that you’re looking for. Plus, in this example, we’ve unnecessarily made our .heading class a little bit more specific which might encourage us to override things in a hacky way elsewhere in the codebase.
We could write the following:
.element { ... }
.element-heading { ... }
I know this looks foolishly simple but the relationship between these two classes is easier to see and easier to extend in the future. Bundling all that code into a single nested class can get out of hand real fast. Even if it happens to look a lot cooler.
(As an aside, Andy Bell’s post on using the ampersand in Sass — and the resulting comments — is a great example of the clash between creativity and practicality.)
Anyway, the point I’m trying to make here is that CSS (and JavaScript for that matter) is a strange language because there are no definite rules you can make about it. It all really depends on the codebase and the project. But I think we can safely say that our code ought to be a lot more boring than our prototypes when it moves to production.
Continue to make prototypes that are wild and experimental or impossibly weird! Code quality be damned.
