There’s a lot to consider when designing album cover art—from carefully selecting the right typography, to capturing the essence of a record’s sound using just the right combination of visuals.
So, what makes an album cover design stand-out from the rest? We asked the designers at DKNG—a design studio with a focus on the music and entertainment industry—to share their top album design tips for folks just getting started in this niche field. Use these tips as a guide to creating both thoughtful and effective cover art for the musicians you’re designing for.
For even more cover art inspiration, check out our recent Weekly Warm-Up, where we challenged graphic designers to redesign their favorite music album.
1. Think about versatility
Think about a range of sizes—album art appears on everything from billboards, social media, to the music app on your watch, so think about creating a design that’s iconic enough to work in small sizes, but with enough detail that it shines when reproduced in larger applications.
A lot of album artwork today is simply for a digital single. But if you have the opportunity to create a unique package for vinyl, get creative with it. And creative doesn’t need to be expensive—you could even screen print your own packaging and just have the vinyl itself commercially produced. There’s even a Grammy Award for best album packaging. Check out previous years’ winners and nominees for inspiration.
Our biggest goal As the designers is to let the voice of the band or musical artist come through, rather than our own aesthetic. What visual style resonates most with the band and their fan base? Some artists we work with have their own style guide which can be super helpful in knowing what themes to focus on, and which themes to avoid, to make the album art truly their own.
Even if it’s not your cup of tea, listening to the music of the artist while you design will help you determine the best look for their album art. Even if you think you have a solid opinion of what the sound and vibe is, listen again. You might be surprised to catch a specific lyric or sound that provides new inspiration.
We hope you enjoyed these design tips in addition to the album title art inspiration! Thanks so much to DKNG for sharing their insights with us. Now that you know how to design a great album cover yourself, we challenge you to try your hand at redesigning an existing one. Whether it be a new album or an old favorite, we’d love to see what you come up with on Dribbble.
How one little team sparked a design system revolution in the world of developers.
Four years ago, Brainly helped spur the digital industry’s move toward formalized style guides, and since, full design systems. Our original style guide added some much needed cohesion to the Brainly UI, but it soon showed itself to be inadequate. The problem was that our style guide was driven by the views of frontend devs rather than a healthy balance of dev and design. As such, it couldn’t serve as any kind of common ground for the teams to cooperate from. So, we ran an internal inquiry about problems in the design to frontend workflow and decided that the two teams would join libraries to unify the process. It was this expansion of scope that led us to create an end to end design system we call Pencil. It’s an ongoing collaborative effort that defines everything from our brand strategy and design principles all the way down to rules for font sizes and padding.
A brief history of our design system, Pencil:
Kudos to everyone who helped sharpen Pencil so far. You can meet them all here.
Seeing as our users are the audience for all that we do, we always make sure to get their reaction to a proposed design via an A/B test. So, during a set time period, half of all users see the new design while the other half sees the old. With 150 million users worldwide, we very quickly have statistically significant data to inform our final decision. As a rule, unless the A/B test shows a neutral or positive reaction to the change, it doesn’t go forward to implementation.
Our work to close the gap between design and development inspired our (then) developer Konrad Dzwinel to inventHtml-Sketchapp.
This homemade bridge between worlds turns HTML nodes into Sketch layers or symbols, thus translating directly from dev to design. Bringing the work of Design and Frontend together under the same roof like this was a revolution in cross-team communication and cooperation. A revolution that turned out to be so effective that it spread to dev teams all over the world [1, 2] , including those of Microsoft, Yelp and Seek.
Our main tool for actual design work is Sketch. Its introduction of libraries combined with our invention of Html-Sketchapp has left us with a toolbox we can feel confident in. However, we have been testing Framer and, more recently, Figma, which is looking more and more promising thanks to its unification of design, prototyping and handoff in a single tool.
Another milestone in our process was introducing Abstract for versioning and handoff. With it’s GitHub-ey versioning structure, multifunctional comment section and unique support for custom symbol naming, Abstract remains our weapon of choice for iteration.
When we need the occasional prototype, we use Principle, Webflow or ProtoPie. Whatever the designer prefers.
Similarly, devs use code editors of their own choosing but all iterate together in github.
Both the design and the frontend team use Google Drive for storage. This is also where we keep asset libraries created from our design system.
Our toolset handling the introduction of a new component:
We work in a federational model where interaction designers on the Design team are also members of the various Product Teams developing Brainly features. This means each designer acts as a design system advocate and liaison to frontend engineers, product owners and business intelligence. This close cooperation between designers and the stakeholders of their work is what allows for user-centered design from us and design system respect from them.
Our federational model does have a hint of a centralised model, since we have a Design System Lead, and we work with a frontend engineer from one of the product teams who takes time out to translate between frontend style guides and design libraries usingHtml-Sketchapp.
Meanwhile, our Visual Designers work on non-product projects like marketing, which also generates new and distinct libraries.
All these libraries are organized within the overarching design system architecture that is Pencil, to be used and followed by anyone in need of a Brainly design, even when no designers are available.
How members of the design team work on our design system:
Currently, we’re working on expanding our design organism library within Pencil. Rather than putting together smaller atoms and molecules for every iteration, the goal is to have all versions of all organisms included and accessible at every stage from Sketch toHtml-Sketchapp export. This day-to-day record-keeping will dramatically improve the ease, speed and consistency of future designs — especially those messy multi-version projects.
Hopefully, this gives you some inspiration if not outright guidance on how you might take advantage of your own design system to make life easier and results stronger — not just for your fellow designers, but for your differently-skilled coworkers as well.
Cover illustration of our design system documentation at design.brainly.com by Olga Wysopal.
The very nature of business is being transformed by the cloud. In a world where products are no longer finished before they reach users, and incremental improvements are regularly deployed, the relationship with a consumer shifts from buying a product once (owning it) to paying a fee to use it for a set period (renting it). Whereas in the past we might have paid a few thousand dollars for a “finished” piece of software on a CD-ROM, we now pay a few dollars per month for regular access to a cloud-based service.
[Image: Portfolio]
This shift to a recurring revenue model, or subscription business, has many advantages, which include scalability, predictability, and high customer engagement. You’re never making a final sale—and you’re relying instead on regular income through subscription fees. To illustrate this difference, it’s like the distinction between dating and being married: when dating you always want to have your game on, but after getting married you might start taking your mate for granted and get a little lazy. When you’re always “dating” your customer, it’s critical to constantly please them, especially when they’ve come to the end of their subscription period and it’s time to re-up.
The average consumer is now less often the stereotypical nerd of yore, and instead could be someone’s hip over-seventy parent, an iconic reality TV star who’s never used a spreadsheet before, or a teenager who sits at the athletes’ table at lunch instead of the mathletes’ one. A purely functional approach is no longer enough, and instead a richly experiential one has become table stakes because of the relatively new premium standards that have been set by mass market devices and services—think Apple and Instagram.
The minimum viable product (MVP) approach is the minimal or “lean” way to give consumers what they want without it necessarily being a fully realized idea. Given how the cloud works and its unprecedented ability to test incomplete ideas, the MVP approach has become the dominant methodology for pushing ideas out into the world. Although the definition of “viable” is debatable and rightly in the eye of the beholder, because the folks who actually build software systems usually come from an engineering background where “V” will signify being reliable and having as few defects as possible. They want to build a bridge that won’t spontaneously collapse—why bother adorning it with a beautiful floral pattern if it can’t withstand the weight of more than one vehicle?
A techie might be fine with a rough, purely functional experience, since their tolerance for discomfort is already high to begin with. But the general population has grown high expectations for their apps, so it’s become important to redefine “viable” as needing to grant a degree of comfort and a modicum of delight. A professional test pilot in an experimental aircraft doesn’t need a cozy place to sit, whereas a passenger on a commercial jet will expect a pillow and a soda—preferably the whole can. To make this point clearer in an MVP-ridden world of computational products that are missing creature comforts, I like to use the term “MVLP,” where the “L” stands for “lovable.”
Why? Because it’s easy to forget that we’re making viable experiences for more than just technical people who prize reliability and efficiency above all. I like to throw in the “L” to remind ourselves that, whether we think we’re dating or married to the customer, we still need to play a flirtatious game to keep our relationship solid to remain in business with them.
The art and science of design is fundamentally tied to the Japanese philosophy of aichaku (AYE-chaw-kooh), literally “love-fit.” This design word describes that special connection to something in your environment that fits your life so perfectly that you are immediately bonded to it. Being able to frame the construction of lovable, desirable experiences as proximate to the goals of making scalable, robust computational machinery is no longer just a “nice-to-have”—it’s now a “need-to-have.” Brokering this connection between the Temple of Tech and the Temple of Design is something I’ve been doing for most of my lifetime.
A few technology companies have benefited from the practiced vision of people who understand the psyche of software engineers and who have managed to convert that creative energy into experiences that any human being can love without the Temple of Design’s help. So, departing from the usual design success example of Steve Jobs, I like to point to the early work of former Yahoo CEO Marissa Mayer, back when she was VP of search products and user experience at Google. Mayer went in the exact opposite direction from prevailing approaches to visual design on the web by focusing entirely on the time it took for information to get from Google’s cloud onto your machine.
In 2006, Mayer asserted that users “really respond to speed,” pointing out how reducing a Google search from 100 kilobytes down to 70 kilobytes led to a material increase in traffic. Place this in contrast to what was at the time the natural inclination to want to deliver a “designed” experience with many full-screen photographic images and other bells and whistles. I attribute the brilliance of Mayer’s strategy to Google’s newfound position of design excellence, which is rapidly approaching Apple’s, even though most celebratory articles largely misunderstand or omit Mayer’s seminal contributions.
Mayer took something that engineers could understand and measure and then used Google’s in-house expertise to ruthlessly pursue an experience that could be delivered quickly. This is not unlike what the McDonald brothers achieved when they figured out how to deliver a tasty burger at breathtaking speed with their Speedee Service System. They managed to address a fundamental experiential constraint lying at the foundation of well-designed experiences, which I highlighted as the third law in The Laws of Simplicity: Savings in time feel like simplicity.
Google’s ability to deliver experiences with the right choice of engineering perspective strikes me as truly foundational to their product. Although this early approach often became conflated with a minimalist design approach of “less is more,” or with just a nerdly bias, it’s way more than that. It’s the recognition that the “L” in MVLP needs to be taken seriously at the engineering level from the start, because everything depends upon computation. And so Google’s selection of speed as a design attribute stood at the rare intersection of what could be loved by both engineers and nontechies, because when a web page loads quickly, it qualitatively feels divine. And once the technical challenge of achieving speed was mastered by Google, they smartly broadened their “L” approach to include nonengineering attributes such as beautiful, highly compressed imagery such as what is often featured on their home page.
The lovability of an MVP for nontechnical people can only be made possible by bringing businesspeople and designers early into the inception and construction of digital products of any scale. To slap on a business model to a finished computational machine is no longer a winning strategy; by the same token, spraying design all over it after it’s done is a reliable way to lose. An integrated approach is necessary: one that appreciates what developers love to make happen—that is, bridges that don’t fall down—in service of consumers who can pay a fair price for an experience that achieves a satisfying aichaku-style fit.
Imagine you’re tasked with implementing dark mode. You look around for standards, only to find a wild west of creatively applied themes in third-party environments. Hours turn into days. The darkness consumes you, and the answer becomes more distant with every keystroke. Meanwhile, dark mode continues to climb as a top customer ask in your feedback channels. The pressure’s on. What’s clear: people want dark mode. What isn’t: how to do it in a way that’s scalable without losing the product’s soul.
This isn’t as easy as it seems. Designing a cohesive, maintainable dark mode that makes existing creature comforts feel fresh seemed like a daunting task to the Outlook mobile design team. But after chatting with a few people in the community, we know we’re not alone. We’ve found five things to think about when designing for dark mode, and we hope you’ll find them helpful too. Let us know what you think in the comments!
1. Stay true to core product identity
To begin, we examined our product identity. For Outlook mobile, the combination of email and calendar is key. People use our product to tell them important information, and we need to serve that purpose well in any environment. Throughout the course of our journey, we made sure to protect the way people composed and read emails, and how they understood their schedules.
We also don’t live alone. Outlook mobile is a part of a bigger family, so we needed to bring all our other mobile apps along and ensure a consistent experience. For example, Outlook would have to look and feel familiar to a user coming from Word.
Microsoft 365 mobile prioritizes preserving continuity and collaborative promise for the user. As part of that effort, we constantly try to balance functionality, usability, and quality in Outlook mobile. It’s what helped us earn our reputation, and we can’t forget our roots.
Because our products live within a larger family, we needed a solution to work across all of Microsoft 365.
2. Pure black is mobile friendly
To understand what surface colors made sense for us, we collaborated across Microsoft Design. The work that came from Fluent Design on web and desktop served as our north star. We explored various surface color variations and decided on a mobile-first direction. Here’s why we chose a pure black surface:
As we refined our explorations, we discovered that pure black saved battery life.
Neutral grays lived in harmony with time-of-day color temperature shifting such as TrueTone and Night Mode.
Black surfaces gave us flexibility with other UI elements, such as cards, dialogues, and toolbar elements, all of which served as context signaling for the user.
Pure black gave room for buttons and dialogues to separate from the base. The base was a starting point which served as a backdrop for accessibility-friendly fill colors and text.
Once we established this, we worked backwards. We applied each surface color variation to our core product screens, checking for accessibility and preserving user meaning. These screens served as early prototypes to help us see what did and didn’t work.
We explored a bunch of different surface colors and complementary detail treatments to find the right solution.
3. Applying color is a game of balance
Showing colors on darker surfaces means the differences between your saturated and unsaturated colors will stand out a lot more. Maintaining a balance between distinction and accessibility is key when designing for dark mode.
We started by auditing the most-used parts of our experience in light mode. We identified elements living at different elevations, such as action sheets and dialogues. This audit helped us define 80% of the elements we were using throughout the app and helped us isolate remaining gaps quickly. Sketch Color LibrariesandLayer Styles allowed us to collaborate from a single source of truth and see our changes on both platforms simultaneously.
We then examined saturated color usage. In general, we increased brightness while dialing down saturation for most colors to meet WCAG contrast ratio standards across both modes. We made sure to support a high contrast accessibility feature in our color choices, too, which can make it easier to see text and UI elements.
4. A semantic system brings order to chaos
A semantic system allows us to create a single color swatch that has two or more color values, these colors then change when the app is in light or dark mode. For example, in Outlook mobile, primaryNavigationBar is outlookBlue in light mode and grey900 in dark mode. Assigning two fills to one component makes things easier, faster, and much more maintainable. Designers wouldn’t add bloat to app colors, and developers understood how to apply the components with built-in colors instead of one-off hex values. Everybody wins.
Embracing a semantic system allowed us to assign multiple colors to a single swatch, which made it easy to alternate these swatches between light and dark mode. The semantic name remains the same but the color could change app-wide without missing a spot.
5. Small details make a big difference
The work doesn’t end at the surface level. The smallest details, including icons and images, must communicate what they’re meant to. Icons need to maintain their form: for example, an envelope in light mode should look like an envelope in dark mode to show presence. For images, this means the smallest details, down to our app onboarding screens or supporting tutorials, need to be updated to support a newer, darker world.
We hope these lessons we learned creating dark mode for Outlook mobile can help other designers facing similar challenges. Dark mode should respect your core product purpose, feel familiar to a user, and set a foundation for future growth and success. The details matter, and being thorough with them can make all the difference. At its best, dark mode balances familiarity with excitement and shows people we’re paying attention to how they use our products.
Have you applied dark mode to your products? Share your learnings in the comments below!
A big thank you to William Hou, Lance Wang, Daohan Chong, Summer Li, Lency Qian, Luna Zheng, Bei Li, Claire Anderson, Ting Zhang, Miles Fitzgerald, Corbin Reynolds, Tali Roth, Michael Palermiti, Jon Friedman, and Charles Riccardi. This was a huge effort across the company with countless names to list.
Under the scheme, parents will be able to get financial support to cover the costs of burials or cremations.
Tight deadlines meant that the team and I had just 6 weeks to design and launch the service to the public.
While the service also applies to funeral directors and cremation and burial providers, this blog post focuses on the journey for parents and friends of the family (also known as the responsible person).
Making tradeoffs
With our deadline, we didn’t have time to do research directly with users or go through a service assessment.
Here are the tools we used to help us design a simple service as fast as possible.
1. The MOJ Form Builder platform
Page flow view inside the Form Builder platform.
Ministry of Justice (MOJ) Digital and Technology created the Form Builder platform to let publishers create digital forms easily using components from the GOV.UK Design System.
Using the platform for this service significantly reduced the time it took to develop and launch our service.
2. Desk research
Google Doc with links and resources to things we found during desk research.
The team shared links to articles, content on funeral director sites and existing content on GOV.UK.
Our user researcher also contacted bereavement charities and spoke to the Funeral Expenses Payment team at the Department for Work and Pensions to learn how best to communicate with those who have suffered bereavement.
3. Journey mapping
Digitised version of the end to end journey map in Miro.
I planned and facilitated workshops to map the end to end journey. This helped us to understand the process, spot gaps and jot down ideas quickly as a team.
We used the map to prioritise additional tasks, like doing more targeted desk research and getting clarification about the policy.
We spoke to the cross-government design community to ask questions and get feedback on our designs as early as possible. I’ll provide some examples of this later.
Shorthand form design
In the early stages of form design there’s often lots of changes to the content and the order of the questions.
For example, brackets for radio buttons and square brackets for checkboxes.
Google Doc showing how we collaborated on the design of the questions using shorthand form syntax.
We also used the error templates from the GOV.UK Design System to set the validation rules and write error messages ready for the live service.
Question protocol mapping
As part of doing the hard work to make things simple for users – especially in this sensitive situation – we only wanted to ask users questions that were absolutely necessary.
The map has columns for clauses from policy, form fields, data needed, details of how it will be used, and the level of importance. Rows represented the data being captured.
I organised a workshop with our user researcher and a colleague from the operations team to run through each row of the map.
For example, we ran through what will happen when the user doesn’t have the burial or cremation certificate. The answer was: the caseworker will contact the cremation or burial provider to confirm the funeral took place.
We then focused on what the cremation or burial provider needs to be able to do that. As they don’t need the certificate for burial or cremation, we removed that question.
By the end of the workshop, we’d removed many questions and simplified the claims process for both claimants and caseworkers.
Using the Form Builder platform
When the shape of the form stabilised, we began using the Form Builder platform.
The Form Builder is pretty new, so along the way I noted down issues with some of its components, ranging from accessibility issues and the inability to set certain content.
Once prioritised, I was able to work with our developers to fix some of these issues and make the Form Builder even better.
Role play research
In the last 2 weeks we found a small amount of time to test the service with a couple of bereavement charities.
We asked participants to act as someone who had lost their child, incurred funeral costs and wanted to make a claim.
On the whole, participants thought the service was fast and simple and were surprised that they didn’t have to provide much information to make a claim.
We found that some participants weren’t sure they were eligible for the service or what exactly they could claim for, for example, the cost of a nicer urn.
We used their feedback to improve the content to help users understand more about who the scheme is for and what it covers.
Including people who don’t have an email address
Iteration 1
One of the first questions we added to the form was to ask for the user’s email address.
Email address field on its own.
But we realised that this could create a potential barrier for people who don’t have an email address or who prefer to be contacted another way.
Iteration 2
We thought a branching question would be long winded for this. So we designed a version that asked users how they would like to be contacted.
Contact preferences represented as a group of checkboxes. The first checkbox for ‘Email address’ is expanded to reveal the email text field.
Subsequent screens had additional details based on their choices. Like an address form if they selected ‘By post’.
But this didn’t make sense because we needed a postal address to process their payment, regardless of their contact preferences and the service wouldn’t be able to support telling claimants the outcome of their claim by phone.
Iteration 3
We went back to asking for an email address. But this time we told users how they could proceed without an email address.
Email address field with an expandable area underneath with content explaining what users must do if they don’t have an email address.
This seems sensible based on our assumption that most people who use a digital form prefer to get a response by email.
Asking for the child’s name
Iteration 1
Not all children who die have a first name so we couldn’t rely on this information to verify a claim. So we decided to only ask for the child’s family name.
A single field asking for the child’s family name.
Iteration 2
Research carried out by the Child Bereavement UK charity shows that parents fear their child will be forgotten after they die—so mentioning a child’s name in correspondence is advised.
We added a field to let claimants enter the child’s first name if they want to. That way we could use it in subsequent communication.
A form with 1 optional field for the child’s first name and 1 for the child’s family name.
Helping people upload receipts
The service asks claimants to upload their receipts in order to validate their claim. File uploading is a complex interactions for users.
Iteration 1
Before needing to upload receipts, the service asks users what they’re claiming for using checkboxes. The initial design consisted of a single screen with a file uploader.
Field asking users to upload receipts for everything they’re claiming back.
The claimant can upload their receipts and continue. But if the user doesn’t have a receipt they get stuck in a deadend.
We couldn’t make the question optional as this could cause users to skip the question. As a result this could slow down their claim or put their claim at risk of being rejected.
Iteration 2
If a user doesn’t have a receipt caseworkers need to know why.
The first iteration, asked users for this information in a question below the upload field.
Additional text field labelled ‘If you do not have some if your receipts, tell us why’.
Users can answer either question or both questions. This is problematic because it’s not clear, it’s error prone and means caseworkers have to attribute receipts to the reason.
Iteration 3
I initially thought about adding a branching question to ask users whether they have all of their receipts or not. But they could be missing just 1 receipt which really meant we needed to provide 3 options:
Yes I have them all
No, I don’t have any receipts
I have some of my receipts
Here’s what the screen looked like:
Branching question with 3 radio buttons.
This approach is problematic because:
it could encourage users who have receipts to not provide them which could delay their claim
the answers are longer and harder to understand
users need to remember what to upload in subsequent screens based on what they answer here
Iteration 4
I shared this dilemma on the cross government Slack channel.
All the feedback was great, but in the end we used Amy Hupe’s suggestion to ask whether users had receipts for each item being claimed for. If yes, they upload the receipts. If not, they explain why.
Flow diagram illustrating that for each item the user is claiming they are taken down a specific path.
This involves more screens, but it keeps the cognitive burden on the users low. It leaves little room for error, and users are guided step-by-step through a challenging process, during a time when they’re most vulnerable.
Helping people make a declaration
At the end of the form users need to make a declaration before they submit a claim to say that they know it’s a criminal offence to knowingly submit false information.
Iteration 1
Our first idea was to give users a checkbox at the bottom of the ‘check answers’ page to confirm they have read and understood the declaration.
Checkbox on the check answers page to let user’s declare they understand the terms.
But:
it’s not clear that clicking a checkbox carries more legal weight than just pressing a button
there’s some evidence that people have become so used to the check-to-agree pattern, that they’ll just tick it without reading it anyway
it’s another question to answer
Iteration 2
Instead of a separate checkbox which says ‘I agree’, we updated the button text from ‘Submit claim’ to ‘Agree and submit claim’ which avoids an additional question that’s not valuable.
Checkbox removed and submit button updated to ‘Agree and submit claim’.
Thanks to the team for making this happen in such a short space of time. And thanks to Alex Nash, Martin Oliver, Amy Hupe and Sonam Sony for helping me write this.
—
I write articles like this and share them with my private mailing list. No spam and definitely no popups. Just one article a month, straight to your inbox. Sign up below:
As content strategists, researchers and product designers at Facebook, we aim to create experiences that are clear, consistent and compassionate through both the language and the design. Everything from the tone we use to the controls we provide helps to make products across Facebook that are more thoughtful, more human and better for the people using them.
We work together to consider the entire user experience, paying close attention to both the product design and the content strategy. The two must coexist in a way that ensures that the products we make actually solve the problems people are facing, that the user experience is intuitive and easy-to-use, and that the visual design feels familiar and engaging.
Across Facebook’s family of apps, our teams are dedicated to designing for well-being. We take on topics like suicide prevention, including tools and resources for people at risk and their concerned family and friends; memorialization, to preserve the wishes of people who’ve passed away and support the bereaved; and harassment.
As we learn about how people engage with our products, key insights help guide the decisions we make to launch new products and features, evolve what is already in market, sunset certain features and identify and build teams around new opportunities to create better experiences for people.
Back in 2017, our team explored the ways people experience harassment on Facebook, especially through receiving unwanted messages. As a result of these explorations, we built the capability to ignore a conversation in Messenger. Let’s look at the content and product design process through the lens of that product. Our team sees it as a process in four stages — understand, design, gather feedback, build — with some fluidity between each stage as we go.
We start each project by doing the work to understand the problem. This helps us recognize people’s needs and uncover opportunities to improve the products we build. The core product team consists of a product manager, data scientist, content strategist, product designers, researchers and engineers.
In the case of the work on harassment, the team first aligned on the goal to explore whether our harassment-mitigation tools were serving people’s needs. To understand what people were experiencing, we looked at foundational research insights and survey responses. We also dove into the data to understand behavior at scale and find patterns.
To narrow our focus and scope, we condensed all of this information into “people problems,” which are concise explanations of the issues people are facing. The team discussed and debated which ones to address, combining what we knew from existing data and research — as well as engineering constraints — to define the biggest opportunities.
People problems and opportunities surfaced during a team sprint
Let’s take a step back here, because in many cases, and on our team in particular, “people problems” are serious, real-world problems. A people problem might be, “I want to stop someone I’ve just met online from sending me inappropriate images on Messenger.” These scenarios, reframed as people problems, allow us to abstract and generalize the problem so that it’s solvable — but individuals can’t be abstracted and generalized. So we never lose sight of the people who are facing these problems in the real world — where safety and reputation may be at risk.
As a result of our work to understand the problems, we decided that building additional tools to help address harassment over Messenger was the biggest opportunity. Specifically, we heard that the concept of blocking someone on Messenger or Facebook felt extreme for repetitive badgering or for those who knew the harasser in person. While the block feature did not explicitly declare to the person that they’d been blocked, there were indicators that a savvy user might be able to figure out. Even for the person doing the blocking, the action might feel rude. And in cases of harassment, blocking someone on Facebook can prevent you from being able to report them, because they’re hidden from you.
We started to think of our harassment-mitigation tools on Messenger along a spectrum: from muting, which merely turns off notifications, to blocking messages, to blocking on Facebook. But between muting and blocking messages, there was a hole we sought to fill. We wondered, how might the capability to “hide” a conversation work?
Spectrum of harassment-mitigation tools
In broad strokes, we outlined the user experience: The person being hidden could continue to send messages without knowing that their messages were going unseen, and the person hiding the conversation could proceed without being aware of annoying or harassing messages. If the recipient needed to seek out the conversation, they could find it easily and unhide it if necessary. They could also block someone they had hidden.
We had extensive conversations about product functionality, from the very specific to the very broad. We discussed questions like:
Where would people expect to find the option to hide a conversation?
How do we communicate what will happen without overwhelming someone?
Where should the balance be between feeling lightweight versus robust and satisfying?
What exactly does the person who’s being ignored see?
What is the visual affordance to indicate the feature is on or off?
Where do we surface the ability to escalate to a block?
How will this work across Android, iOS, mobile web, desktop web and all the other platforms we support?
Whiteboard wireframes mapping out the flow
While answering these questions, we sketched out design solutions, starting wide and narrowing to what might have the greatest impact. We created mid-fidelity mocks to get a better sense of how the top solution would fit in the existing product, explored content options in context and visualized the design details. We talked a lot amongst ourselves and with our content and design colleagues to get feedback and ensure that we were thinking deeply from the perspective of people experiencing these problems. To flesh out the interaction design and make our ideas feel like a real product, we eventually created high-fidelity prototypes.
High-fidelity interface explorations
How could we deepen our understanding of this problem space? We needed to do in-person research. Data plus existing research on harassment got us part of the way to understanding the problem. In order to ensure our solutions truly meet people’s needs, our content strategy and design teams rely heavily on research — and that often takes us away from our offices and into the world. In our case, we’re based in California, so our team planned a trip to India to get a first-hand understanding of how people who live in a culture different than our own experience harassment on Facebook and Messenger.
Our team — including two researchers, a product manager, two product designers, a content strategist and an engineer — traveled to Delhi and Ghaziabad, a smaller city near Delhi. We conducted focus groups (grouped by men and women) and in-home interviews, speaking with a wide range of people. To get a sense of how they understand and use the current blocking options, we showed them the existing tools for blocking messages, receiving message requests, or turning on the ability to review the posts you’re tagged in. We then sought their feedback on prototypes for new ideas including the feature to hide conversations and a promotion to raise awareness about message blocking.
Early prototypes used for feedback in research
In doing this research, we wanted to understand both the perspective of someone who’s being harassed or bothered on Messenger, and that of a person who’s repeatedly trying to contact someone. People in our focus groups talked about seeing Facebook as a way to connect with anyone in the world; there’s a real curiosity and interest in meeting new people online. Both men and women said that they accept any and all friend requests, no matter how remote the connection. We also heard from women who told us how easily and often the line can be crossed from friendly hellos to unwanted contact and harassment. We got a strong sense of the pervasive ways that harassment plays out in the real world, in all sorts of interactions.
We spoke to participants who said they had experienced a lot of harassment on Facebook, so we knew we’d hear difficult stories. But we also heard strength and courage — as well as a deep familiarity with the tools at hand. Men and women understood the functionality to block both a message as well as a person on Facebook, and they had no issues with blocking someone who was bothering them. “I just blocked him” was a refrain we heard over and over. But we also confirmed that in certain situations, there’s a need to stop hearing from someone who’s sending harassing messages without explicitly blocking them because it could cause serious real-world implications.
Unwanted and harassing messages have no place on our platform.
This is where the work becomes really, really hard. Harassment affects millions of people every day — well beyond Messenger. We know that a button on Messenger will not take away the memory of a harassment experience, and it won’t mean that something upsetting won’t happen again. Unwanted and harassing messages have no place on our platform. To help combat this behavior, we work to adjust and augment the tools that someone might be using.
In the early stages of this project, we had been referring to the functionality as “hide.” We learned on this research trip that people were already familiar with the capability to hide a comment on Facebook, which didn’t align with the idea of hiding an entire conversation with someone on Messenger. So, after much discussion and exploration of options, we shifted our language to “ignore.”
As with any product, we collaborated with our engineering colleagues who were building the back-end functionality and front-end interface. We needed to ensure that the product we designed was technically feasible, while still being intuitive to use. Once we launched the ignore functionality, we ran surveys and analyzed data to understand how it was (and is) performing. We found that it was quickly adopted and coexisted harmoniously with blocking and other harassment-mitigation tools. However, we also needed to account for group messages, so we iterated and did another round of usability research to ensure that the built product was intuitive, valuable and easy to understand.
Final prototype for the feature to ignore messages
As product designers, content strategists, and researchers, everyone can leverage each other’s skills on the team to deeply understand the problems people are facing, lead the team’s efforts to design solutions for those problems, show prototypes to real people for their feedback, and work collaboratively with engineers to bring the final product experience to life.
But our design work does not stop there. Testing, learning, iterating and sometimes making decisions to sunset products and features is all part of the journey to getting it right for the people who use our products. This work has been one step along that journey to determine the best way to help people avoid harassment on Messenger. We’re proud to have the opportunity to continue learning and designing for well-being, keeping people at the center of our work each day.
Google wasn’t exactly known for their design a decade ago. A lot has changed since then.
I joined Google last year on the week of their 20th birthday. I was curious to see how design evolved for such an unconventional company.
Looking back at the past year, here are 10 things I learned that I hope will help you with your design journey.
Focus on the user and all else will follow. From the very first day of orientation, speakers instilled into us to respect the user. With nine products that have more than one billion users, designing for everyone took on a whole new meaning. The smallest design changes could affect millions of people.
At my previous companies, accessibility and internationalization were an afterthought. At Google, our designs need to be inclusive and we need to think about supporting the next billion users.
I’ve become a better designer by focusing on providing a great experience for as many people as possible.
Before Google, I was the head of UX for a midsize, public company. When I joined the search giant, I had the same title as hundreds of other designers and no direct reports. Here’s the thing — you don’t need a fancy title or to manage a team to be a design leader.
Google is very much a relationship-based organization where influence is everything. Building strong partnerships with product managers, UX researchers, and engineers are essential. That’s been true for every company I’ve designed at, but especially here.
How do you build influence? Start building trust by asking questions, listening, and taking a personal interest. Once you’ve got the team’s trust, inspire others on your vision by showing how it aligns with the team’s goals.
Google’s design community is huge and everyone wants to be helpful. It’s not uncommon for someone to throw a quick chat on your calendar to meet or get advice. Chances are pretty good that someone has already dealt with a similar problem in the past.
As the new designer on the team, take advantage of your status by asking lots of questions. You don’t know what you don’t know. There’s a lot of history and design decisions that went into a product that you’ll need to uncover. Don’t be afraid to show unfinished work to get early feedback. By the time I go into a design review, I’ve already had a chance to address any concerns.
Ego gets in the way of good design. During my interview, I asked what traits successful designers at Google have. One that I heard many times was not having an ego. While a healthy dose of confidence is good, don’t aspire to be the smartest person in the room. We don’t always have all the answers and that’s okay.
Good ideas can come from anyone. There have been many times where someone else has come up with a different way to solve a problem. By remaining open-minded, we collaborated on a better solution for the user. Stay humble by reminding yourself who you are designing for and empathize with them.
There’s always that voice in the back of your head questioning if you belong. At a company the size of Google, that feeling multiplied. I worried I wouldn’t be successful despite designing many products people love.
I’ve come to realize that everyone experiences some form of imposter syndrome. No matter how much you know, there’s always more to learn. I’ve learned to embrace the feeling. Now, when I have even the slightest of doubts, I’ll look back at my past year of achievements and know that I belong.
“The most important investment you can make is in yourself.” ― Warren Buffett
One thing I appreciate about Google is the many learning opportunities available. I’ve taken classes on everything from storytelling to running design sprints. Once a year, Google has an internal UX conference. Designers from all over Google come together to give inspiring talks and workshops.
Not only have I learned from others but I’ve tried to give back to the culture of learning. I give talks on design, mentor others, and teach courses. To become the best version of yourself, embrace the uncomfortable. Do things that scare you. That’s when real growth happens.
How do you excel among other super talented designers across the organization? Develop and optimize your strengths. Using your strengths results in higher levels of positivity and engagement. It also leads to sustained peak performance.
During performance review time, everyone has to list one thing you do really well. One of my strengths is analyzing data to find patterns and organize ideas. I try to get data whenever I want to make an informed design decision. I’ve learned to focus on my strengths and to look for opportunities to use them in my career.
In a lot of ways, working at Google is like working at a well-funded startup. Each team has different processes and tools. While debating between Sketch and Figma is fun, tools change all the time. Technology is always changing and there are new design trends each year.
The one thing that stays consistent is people. We like to think we are all unique but the way human’s think, feel, and act is predictable. Human’s are creatures of habit and don’t change as fast. Understand how to work with your teammates, their motivations, and goals. It’s much more important than learning new tools.
Throughout my career, I’m amazed by how many people don’t understand the business they work for. Everything from the products, users, goals, and how they make money.
As designers, advocating for the user is still the number one priority. Knowing the business makes it easier to convince cross-functional partners to invest in your solutions.
Google is big on OKR’s (objectives and key results). When presenting designs, I make sure to tie them back to the company, team, or product goals. Linking design outcomes to the greater company strategy reinforce the importance of design.
“Fall down seven times, stand up eight” — Japanese Proverb
Getting into Google was a dream come true but it didn’t come easy, which made me appreciate it even more. For the first seven years after college, I applied to Google almost every year and only got as far as a phone screen. A few years later, I managed to pass the initial screenings. I was flown to the Googleplex for a full day of interviews. I didn’t get in.
Between all the rejections, I continued to learn new things and work on my craft. A recruiter reached out almost five years later. After going through the process again, I finally got an offer.
Everyone’s journey is different. There will be ups and downs. If you put in the work, you can achieve anything but the journey never ends. There will be new goals and dreams. I’ve learned so much in my career and the past year at Google but there is so much more to learn. I can’t wait to see where my journey takes me next.
I started designing for the web in 2011 and working in 2013. One of my first jobs was at Microsoft as an intern in their design team located in Helsinki. At that time most of the resources for UI were made in Photoshop. Yes, Photoshop, a tool for editing photos was the same for designing web pages. Using this tool, I could export images that were passed to development and they would do all the magic to bringing it to life through code. But, they didn’t coded it as I expected them to do. The design never fit exactly what I had designed and it frustrated me, a lot. I didn’t understand it, so I decided to learn how to code frontend, to understand what the problem was and how it could get it solved.
Some time later, I started learning how to code HTML and CSS properly and very soon I was already writing production code in a smaller company. Of course, not leaving the design work. That’s when I began to realize that there was something weird, even a bit wrong, with the process. Why did we design static images when the web was not? Why couldn’t I design a button that fit its content instead of adjusting its margins manually as it did when coding on the web? Why didn’t my designs adapt to the screen’s width with relative styles as I could make it do when coding? Why did it seem like I was designing in “position: absolute;”?
And not only that, while the designers were doing handicrafts, in development they used Git as version control, working as a team and in a totally safe and organized way thanks to it.
Until one day, Sketch came out. I remember that I started using it at the end of 2014. It seemed the revolution, surely the designers who are reading me right now can affirm that our quality of life was improved so much. Finally a program only to design UI!
A program where there were not a thousand buttons that you didn’t need, where you couldn’t not only export images, but also SVGs! And everything was much faster and easier than using Adobe. It also had plugins that looked like super powers to me compared with the old-fashioned Photoshop.
But the really game-changing feature was its symbols. We could finally save designs, reuse them and sync them throughout the tool, it was great.
Also new other tools like Zeplin came out. This ones helped the developers (that didn’t have Sketch) to implement our designs. But let’s not fool ourselves, the CSS generated by Sketch or Zeplin rarely ends in production or is event relevant. Some stuff like colors, spacing or shadows can be useful but nothing else. We don’t even use plain CSS in most of the frontend projects, but we use CSS preprocessors like SCSS.
Some time later, in 2017, Figma appeared in the market, and it has gained a lot of attention for these reasons:
It runs on the web and have a free initiation plan.
Real-time collaboration in the same file.
Version history (not version control tho)
Web API which we can use to dynamically export information from any Figma file.
Plugins, surely the strongest feature of Figma at this time. Although Sketch already has plugins, thanks to the web API that I mentioned before, Figma’s plugins are much powerful.
I think that both real-time collaboration and version history is a great step, although I’d like an independent version control to the program and preferably hosted where the code is, to centralize resources. What it surely has to improve is its API, where the results it returns are still very poor, especially related to components and styles, which makes it impossible to connect frontend and design, one of my wishes for this API.
We haven’t still solved the key problems
Yes, Sketch or Figma are much better than Photoshop and the industry continues to evolve constantly, but we haven’t still solved the key problems:
We design and implement the same website 2 times and there are even differences between them! How much time have we lost designing a rule for x pixels spaces and then in development has not been implemented like this or we haven’t even been able to apply that rule in all the elements on our design? It’s not the developer’s fault, nor is it the designer’s, but the medium (the design tool) which is the only one to blame. The difference between the designed concept and the developed product will always exist as long as they are separated.
Current tools don’t allow us to design responsively. I wish we could make relative positions in design. I would love to have CSS media queries to structure the content based on its width. I hate designing the same screen 3 times because it can’t be designed to fit its width. Waste of time. Inefficiency. As a UX Engineer (design and front), I end up not designing the responsive versions for other devices on Sketch because I design them modularly in one width and then I adapt them responsively in the implementation.
The web is not flat, it’s not a blank artboard. We are used to creating static drawings that don’t represent reality as a whole: the web is not images or vectors, it’s not flat, it has interactivity. The web also has states (hover, active, focus, visited …), but how are they represented in the flat world of design nowadays? Repeating designs. We design that same element 4 different times to represent these states unreally and we don’t see how the real result looks until it has been implemented.
Working without version control means that we cannot work as a team in the same file in a completely organized way. Yes, Figma has real-time collaboration and version history but we are still years away from being able to document and create different versions of the project and then compare and join them as we do with the coding version controls. And no, tools like Abstract for Sketch don’t seem sufficient, since they are not based on web code and we cannot compare objective differences from the same medium.
Visual bugs end up in production because we don’t have acceptance tests for our designs. When I speak of testing, I speak about technical acceptance testing, not user testing. Imagine having a way to verify that all the colors used in the design are the official colors. Or another example, that all the measures used are multiples of 8 as defined in the design system. It would be very useful, right? On the development side they are very used to do testing that allow them to minimize possible errors in their work, designers don’t have that when designing, and this leads to visual bugs in production.
Why is this happening?
Many UI designers still keep the graphic design’s mindset, as if designing for the web was the same as designing for offline but with different measures or rules. No, it’s not like that. The medium of the product is totally different and our tools should change depending on it.
That is why I believe that the tools we use to design websites should also not be the same we use to design native mobile apps. They don’t work in the same way, they aren’t developed using the same technologies, they don’t have the same interactions and they shouldn’t be designed in the same way. SwiftUI has taken the step of being able to design with the same code used in development, making it the most suitable tool for designing iOS apps.
The main problem is to separate the concept and the implementation. Do we really need to separate it? Why? As a result we get twice of work with idealized sketches that don’t fit reality and generate frustration between the design and development teams.
Unlike other design modalities, web UI designers have the privilege and great luck of being able to use the same medium where it is implemented to conceptualize that design. But the current design tools are far from how the web works, they keep the mindset of separating the concept from the implementation as is done in all other design modalities. You cannot design buildings in your same medium, using those same buildings. But we can design using the web, since its material (HTML, CSS and JS) is flexible enough, through a graphic tool, to allow us to conceptualize having the same speed and fluidity as with a vector-based tool like Sketch.
As Colm Tuite mention in his article: “Design tools shouldn’t need to resemble or reflect the web and its nuances — they should just BE the web.”
Design systems
Our favorite topic, design systems. But we barely mention how incredibly difficult it’s to maintain two design systems. First, the one maintained by the design team and second, the one maintained by the frontend team. And when you have two different projects with different technologies and maintained by different people, they will never, ever, have a total consistency. And therein lies the problem, the duality.
I get tired of seeing very nice design systems that when inspect their code I realize that those websites are implemented differently than how they were designed. Which is silly, because why to spend time defining a design system if your frontend team ignores it or can’t implement it? A concept that doesn’t get developed well or at all is just useless. Wouldn’t it be better to have a single design system? A single source of truth?
What kind of tool do we need to solve these issues?
I imagine the perfect design tool kind of like a Storybook where the designers could have the components of a design system written in code, the same ones that front-end would use in production, so we wouldn’t need to maintain two design systems, we would only have a single one.
By dragging we could combine these components to create organisms where CSS would be applied from a graphical interface that could reflect the real properties of the web, such as relative measures, media queries, flexbox, CSS Grid…
The same could happen with the animations, we could animate those web elements with CSS animations. And most importantly, our designs would stop being JPGs to be HTMLs. Accessible, responsive and above all, real.
In addition we would solve the version control problem and the creation of acceptance tests. Being a tool based on web code there would be no problems with creating that version control. You could preview by graphically comparing the HTML files displayed by the browser and choosing which version you stay in addition to objectively viewing the web code that has changed. Also, there wouldn’t be any problem creating any acceptance test since code would allow it.
Luckily, there are already some tools that work like this and although they may not solve all the issues listed in this article, they are on the right track.
Framer X: its hype in 2018 was tremendous with the announcement that their designs could be exported to React or we could design using components previously programmed in React. Although it was a huge step, we later discovered that the code isn’t intended to be production ready but to resemble React as closely as possible. And here we find the main problems:
Separating design and development by not creating production ready code means working twice.
Locking yourself in a framework. I believe we should try to use web standards such as HTML and CSS for styling as much as possible. Using React, Vue or Angular should be a JS layer above styling that controls the reactivity of the webapp and it should be delegated to the frontend team, not to the design tool.
Webflow: It’s a great and mature option and it meets the vast majority of points. The only problem is that the generated code is saved in its own hosting and it seems impossible to edit out of the graphic editor.
Modulz: falls into the same problem as Framer X when exporting code only in React. The main advantage is that it exports production ready code and it uses CSS properties for design styles such as flexbox and native states.
Hadron: although it’s still in version 0.14, it’s going in a very good direction. On its website we can see how they solve all the problems raised in this article (including responsive design) with mediaqueries or grids made with CSS Grid. I think it’s very promising.
Mason: It is a tool to create UI code from a graphical interface by replacing the text editor. It seems to have a lot of potential.
Finally, I will not go into the “debate” of whether UI designers should know how to “program” (what a broader term!) Because I think there shouldn’t even be such a debate. Being a UI designer and knowing how the web works and therefore HTML and CSS, which are purely declarative languages, is as basic as knowing physics as an architect.
Design tools have to help us working through graphical interfaces that provide us speed versus code editors but the implementation should be the same.
How we’re crafting Dark Mode experiences across Microsoft 365 that adapt to your daily flow
People often think of Dark Mode as a choice between a black or white screen, but this feature involves a wide spectrum of both grayscale and color gradients.
It’s an apt metaphor for why we love Dark Mode: human needs unfold across an equally broad spectrum. Whether you want to reduce eye strain, improve battery life, or it just has aesthetic appeal, Dark Mode exemplifies our ability to craft simple and powerful Microsoft 365 experiences that give you choice and flexibility.
Customer choice was why we first brought a darker UI theme to desktop apps in Office 2010, and we’ve brought it to more Microsoft experiences, like Teams, ever since due to its popularity.
A cross-company design collaboration propels us to seamlessly bring Dark Mode to the broader M365 product suite, and today marks the initial rollout of Dark Mode on Outlook for iOS and Android, as well as Office.com! The upcoming launch of iOS 13 will then extend this rollout to Word, Excel, OneNote, PowerPoint, SharePoint, OneDrive, Planner, and To-Do on mobile.
Today’s fast and fluid world constantly blurs the lines between work and life, and we believe in meeting people where they are. Our tools are used to keep up to speed on everything from work communication, to personal events that include friends and family, to changes in shared documents. This often means viewing email, calendars, or files in places where the default white mode may be less suitable, like darkened airplanes, movie theaters, or in bed at night.
Our design research specifically focused on these contexts where folks would want to use Dark Mode, and the response was very positive. While some Dark Mode experiences can be neon or overly bright, people felt that Outlook mobile kept the kind of relaxed feeling you might want in a dimly lit living room or bedroom. They described the experience as comfortable, crisp, clear, and aesthetically pleasing, a nod to how Dark Mode can reduce eye strain.
Dark Mode experiences on iOS. The colors pop for legibility without overwhelming the darker feel.
Dark Mode may also save battery life when you’re traveling or on the go for long stretches of time. We’re building in capabilities so following the next round of OS releases on iOS and Android, Outlook will automatically switch to Dark Mode depending on the preference you set. In the meantime, Outlook for Android automatically switches to Dark Mode when you choose Battery Saver. These perks all hold true for Dark Mode on Office.com.
Dark Mode experiences on web.
The seamlessness and flexibility that we’re building into Microsoft 365 design systems mirrors our own fluid creative process. We brought designers together from across the company to create a common Dark Mode experience for all our mobile and web apps. The creative energy that came from exchanging ideas and collaborating with new peers was one of the most fun parts of this entire effort.
Starting from the ground up and using the new gray palette for Fluent, our app teams began by aligning to the single palette. This included increasing contrast, brand color saturation, and consistency among details like how and when we use shadows when in Dark Mode.
We explored hundreds of color options against various backgrounds before selecting these muted color categories.
We’re excited to bring Dark Mode to even more of the Microsoft 365 product suite, starting with additional mobile experiences. Dark Mode comes to Word, Excel, and PowerPoint for mobile with the launch of iOS 13, as well as iPad, where we know many people choose to use those apps. That same launch will also bring Dark Mode to SharePoint, OneDrive, OneNote, Planner, and To-Do on mobile.
There will be more experiences to follow — Dark Mode for all Outlook clients, Planner and OneDrive on web are coming down the pipe — so stay tuned for those rollout dates. Meanwhile, we’d love to hear your thoughts and feedback in the comments below!
![Qualia: New beginning [MMXVII] #Vinyl cover](https://cdn.dribbble.com/users/1368832/screenshots/3542863/qq_cover_1x.jpg)
