Looking for a new job is a twitchy process. Despite the fact that UI/UX designers are in great demand these days, the competition in this market is also very high. That's why you should thoroughly work out your resume to make it look professional and catchy.
When you are about to apply for a job many questions arise in your head: What should a designer resume contain? How should it look like? What common mistakes are better to avoid?
As a design agency, we understand how the resume should look from the perspective of both a designer and an employer. And we want to share this knowledge with you.
In this blog post, you will find useful tips on how to create a resume that your potential employer will definitely notice.
Let's start with the main components of the resume.
What should the resume contain?
A resume is not a document that shows your practical ability to design. There is no need to be over-creative and load the file with visuals. The main purpose of the CV is to present the text information about your work background, skills, and abilities. It's very important to make it readable and consistent.
When you create your resume adhere to the rule: the most important data in the top, less important in the bottom.
Here is the list of key resume components:
- Name and contact information. Of course, the most essential data would be your name and contact information (the employer should know how to reach you out to invite you for the interview). Put it first and don’t get into much detail. An email address and contact number will be enough. You can also include links to social networks if they contain pertinent information that might interest the recruiter.
- Experience. Arrange your work experience in descending order: from the most recent to the oldest. Don’t include the experience that has nothing to do with the current job offer.
- Education. Keep it short. Unless you are a graduate with little experience the name of the college, the field of study, and graduation year will be enough.
- Skills. This section shows why you are better than others. Skills for a designer in the resume is a list of the software you can use, IT knowledge, and other accomplishments you possess only if they may be useful in your potential position.
- Awards. You can end your CV with a list of awards (and again if they are relevant to this position).
In general, state only the information that meets the requirements of the job description.
How to make recruiters notice you
When you apply for a job, most likely you are not the only person who wants to get this position. You may be a great and skillful designer, but to have a chance to prove it you have to make your potential employers notice you among other candidates. A well-designed resume increases your chances for success.
What does a well-designed resume mean? Let’s figure it out.
Make your resume match job description requirements
It takes about six seconds for recruiters to skim your resume. Very often the people who look through it for the first time are neither designers nor technicians. They know little about the design language you use regularly. That’s why they tend to search for some keywords or specific info that will allow them to push your resume to the next stage.
To make your resume look suitable for a recruiter read the job description attentively and ensure that your resume contains the skills and requirements that the company is looking for.
Think carefully about who can read your resume and adjust it to that person, just like you do in the UI or UX designing process!
Pay attention to details
As we figured out in the previous section, you are not the only person who applied for a position. When two candidates are almost equal these are details that matter. That’s why it’s essential to make sure that you didn’t make even small mistakes.
- Check your grammar. Make sure there aren’t any misspelled words and all proper nouns are written correctly.
- Get rid of redundant information. There is no need to include too many details about your education or job experience. Write only that information that may be relevant for this specific job offer.
- Take care of conіstent design. The resume should be quick and easy to read. Pay attention to the fonts you use and the way you group the information. As well don’t make your resume too long (preferably one page).
Avoiding these mistakes will make you look more professional.
Don't forget to indicate your skills
Your UI and UX skillset is especially important in the designer job and can differentiate you from other candidates.
We’ve already mentioned it... but once again: read the job description carefully! Find what specific accomplishments the company is looking for in candidates. These can be knowledge of programming languages, the ability to use different design software, understanding of the latest trends and technologies, etc.
If your skills fit with those the company requires, state them using the same keywords as in the job offer. In case you apply for several positions, don’t forget to adjust each of your resumes according to different companies’ requirements.
This will make your resume look more appealing to potential employers.
Think out the design
When I say the design, I don’t mean all those interactive features and visuals that may be beneficial when designing a product or a website. Still, even in your resume, you can take care of a good user experience and make it appealing to the reader.
- Size. First of all, to make your resume easy to read keep it a single page. A hiring manager will be able to quickly scan it and see all the needed information at a glance.
- Style. Minimalist black and white color scheme is easier to perceive. What is more, this way the resume won’t lose its look when printed. Use whitespace to logically divide different blocks of information.
- Fonts. Use no more than two fonts in your document, make sure they are simple and easy to read. Don’t use calligraphy fonts that imitate handwriting.
- Text. Skim all your text carefully to make sure it is readable and highlights the most essential points in your resume.
To sum up, a simple black and white design with relevant information is the best variant for a good resume.
Send your resume in PDF
And finally, when your resume is ready save it in PDF format. Put your name and job position in the name of the file to make it easier to find.
So, a laconic style of the resume plus readable copy will make your skills visible to the hiring manager at a glance.
Best looking resumes
Now, as you know some basics about what a good designer resume should look like and what it should contain it’s time to entrench gained knowledge in practice.
Below you will find eighteen examples of designer resumes that work.
By Eleken
Here is an example of the product designer resume from our design agency. Black and white blocks divide the resume into two parts: basic information about tools and design responsibilities is to the left, design experience is to the right. This way the document looks laconic still includes all the needed information.
By Imani Joy
The clean and minimalistic layout of UX designer resume. In this example, the author addresses the reader to tell in the resume about her user experience skills, awards, and accomplishments which makes the “about me” section more personal. Also, this laconic design is nicely matched with the personal designer’s logo.
By Reux Studio
This example divides resume into two parts: short information is on the left side and the data that takes more space is on the right. Such division of categories makes the document readable and appealing.
By Webduckdesign
These two examples show excellent resume design with a nice division into two parts with the help of the color. Small icons don’t overwhelm the design with visuals and just make it more attractive. The strong bold header is clearly visible.
By Kejia Shao
This sample posses a nice posting of data, starting with essential info like name and contacts and ending with education.
By Yingyu Liu
Clean and simple design makes this resume be noticeable. The information is well-structured with the help combination of vertical and horizontal presentation.
By Laura Henderson
An example of nice use of fonts, spaces, and color.
By Gabe Cagara
A good example of laconic design with a lot of white space to logically separate the blocks of information.
By Misba Abbas
This example is easy to read because of the use of a bullet list, the color of headings, and phrases in bold.
By Tammy Taabassum
The author of this sample shows how to highlight the abilities to solve problems. In each work experience, we can find the line in bold with the solution the designer provided to the issue and the benefits it resulted in.
Template “Casey”
Nice use of frames makes this resume stands out. Blocks are well-separated and it makes the whole document easy-to-read.
By Mattia Schirano
This example shows good use of white space together with bright accents (names of sections).
By Alex Kauffman
The names of blocks are highlighted in blue color and all the information is posted according to hierarchy: the most important at the top, the least essential at the bottom.
By Reuix Studio
A stylish minimalist example by Reuix Studio shows a nice division of sections: those that require more space on the left and not bulky information on the right separated with a vertical line.
By Janice Koo
The author of this resume is a student, so we see she pays more attention to education and projects than other examples we’ve already checked. Janice highlighted keywords in the “experience” section, so that recruiter can quickly catch the necessary information.
Template “Anderson”
The use of horizontal lines makes this resume attractive, helps to make a clear division of sections, and distinguishes it from more traditional vertical variants.
Warren
Here is one more horizontal resume design with a creative and bold headline. The use of whitespace and lines help to easily scan the whole document and quickly find the needed information.
That was the last of well-designed resume examples. As you can see most of them has a minimalist black and white design with a lot of white space and contain minimum visuals.
To sum up
A well-designed resume should be more than appealing. It should clearly explain why you are worth this exact position.
Read the job requirements carefully and use keywords from it to describe your skills, be attentive to details, and check all the text for mistakes. And finally when creating a design take care of a good user experience and don’t forget to adjust it to the person that will read your resume.
Good luck with your job interview!
If you still hesitate if you are a good enough expert read what qualities should a professional product designer possess in the Product Designer Job Description.
Top Stories
What's the Role of a Product Owner During Daily Scrum? 5 Tips to Remember
Here at Eleken, a SaaS design agency, we are lucky to work with Product Owners (POs) that come directly from our clients’ companies. It’s natural that they are eager to get regular updates on current progress from the whole product team. In some cases, they hold separate meetings for this purpose, while sometimes they choose to attend the Daily Scrum.
The Daily Scrum is not a place for a PO to receive status updates, however, this event may be valuable for this professional to attend.
But why should the Product Owner attend the Daily Scrum (if they should at all) and what are they supposed to do there?
Before we discuss the role of the Product Owner during the Daily Scrum, we must, first of all, clarify why this event is important in project management.
The purpose of the Daily Scrum
Imagine you have two weeks and six workers to build a fence. Using the “Scrum language” that would be a sprint of two weeks with the sprint goal to build a fence with six developers. To successfully cope with the task and meet a deadline, you’ll have to create a plan and daily distribute the work among team members. Every morning, you’ll meet with your workers and discuss what was already done, what is to be done today, and if someone needs help to progress towards reaching the goal. Such a daily meeting can be translated as a Daily Scrum.
The Daily Scrum, also known as daily stand-up meeting, daily stand-up, or simply daily, is a short (up to 15 minutes) event held every day at the same time for a small development team.
The objective of the Daily Scrum is for the development team to collaborate, plan the work for the day and inspect the progress with the sprint goal. This helps the team to adapt the sprint backlog as necessary, adjust the upcoming work plan, and to identify issues that affect the project progress.
Here’s what Alexandra, our product designer, has to say about the importance of the Daily Scrum based on her experience:
“The developers in one of my recent projects worked in sprints and invited me to attend their daily stand-ups. Since they work as a team, it was important for them to be aware of who is doing what. And I noticed that a great advantage of these daily meetings was the motivation they gave the developers. Everyone wanted to show their progress at the stand-up, and thus they did their best to complete daily tasks in time and successfully.”
The Daily Scrum has no strict structure or techniques needed to be used, so it’s up to the developers to decide how to hold the meeting and what questions to ask. The main thing is to remember the purpose of the daily stand-up — inspect progress toward completing the Sprint Goal and create a solid plan for the day.
It’s also essential to understand that the daily stand-up is NOT a:
- status update meeting. The goal is to help the development team collaborate and see how the work proceeds. Participants shouldn’t report either Scrum Master (SM) or PO about status updates.
- problem-solving meeting. It’s not right to discuss issues and seek possible solutions to those problems during the Daily Scrum. Such discussions are better to hold right after the daily. Remember to keep the event no longer than fifteen minutes.
But what about the Product Owner’s participation in the Daily Scrum? Let’s shed some light on this topic in the next section.
Should the Product Owner attend Daily Scrum?
According to the Scrum Guide
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team…. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
Based on this extract, we understand that the Daily Scrum Meeting is, first of all, for developers. The Product Owner is neither encouraged nor forbidden to attend dailies, they are just not required to be present unless they are actively working on items in the sprint backlog like developers.
At the same time, the guide says that “the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.” and that “Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.”
Taking this into account, we may assume that though PO’s presence on a sprint daily stand-up is optional, their attendance will be valuable as they are a part of a Scrum Team (Scrum is effective when there are no sub-teams but a whole-team mindset).
Below are a few reasons why it might add value to a PO to attend the Daily Scrum:
- Presence at a daily stand-up allows PO to receive early feedback from developers. Listening about the sprint progress/challenges the team faces, allows the PO to use this information to refine user stories, modify the backlog, and update the product roadmap.
- The Product Owner in the Scrum meeting will get a better understanding of the technical aspect of a product which will help them prioritize the backlog more accurately.
- During the Daily Scrum, the team may raise questions about priorities (for example, if someone reports the bug) or user stories in a sprint backlog. As one of the PO's responsibilities is to manage and prioritize the backlog, their presence in dailies allows to bring clarity on the overall product vision and stories in progress, and define which story to omit if the team is falling behind the schedule. Finally, PO’s presence at stand-ups shortens the amount of time a developer has to wait for a response.
- At the daily stand-up, the team discusses obstacles and blockages they have and a PO might be able to provide them with helpful information regarding the business context to help developers smooth their way towards overcoming those obstacles.
Now let’s summarize the main points that characterize the role of the Product Owner in the Daily Scrum meeting.
- The Product Owner can attend the Daily Scrum if they feel it brings value. They shouldn’t be active participants there, but rather attentive listeners. POs can only participate as team members and may only share some really important information that helps developers reach the sprint goal.
- It’s not the responsibility of a Product Owner to lead or facilitate a Daily Scrum, and developers do not report them on what was done.
- Product Owners that attend stand-ups should listen about things that require their attention to be able to follow up with team members who have questions for them right after the Daily Scrum (if possible).
Now that we know that the PO can be present at dailies, let’s discuss how they should behave to support the team and not steer the event in the wrong direction.
5 pieces of advice in case the PO chooses to attend the Daily Scrum
Here are five things to remember to help the team benefit from your presence at stand-up meetings as a PO.
- Don’t interfere. The Daily Scrum is not your event, but developers’. They need to be self-managed and feel the ownership of deciding what to do next, and how to implement this or that feature. Stay focused and don’t step in, even if you have a brilliant new idea to share (there are refinement sessions for that) until you are asked a question.
- Focus on the outcome metrics and not the output-driven metrics. Very often, during the daily, the PO focuses on the velocity, asking developers why some items are moving to “done” so slowly. It’s not right, as the Product Owner should care about metrics that show if customers got the value they wanted to get, and not what actions were done to achieve this outcome.
- Avoid the “me vs they” mentality. Beware not to create a sense of hierarchy by holding the meeting (as you risk killing innovation). As well, during the Daily Scrum don’t stand aside from the whole team and don’t be late. Remember you’re a part of it. Mind that developers talk to the whole team, and not address their speech directly to you.
- Ensure the team is aware of why you attend Daily Scrums. If people begin to question why the Product Owner is present, when they know little about the technical aspect of a product, you may ask a Scrum Master to explain that your presence is advantageous to them and necessary for an efficient and open development process, as you are a part of the team that represents the product to the stakeholders (customers and management).
- If anyone in the team wants to raise any issues that require your assistance, leave it to the end of the stand-up to have a breakout discussion. Everyone uninvolved in that discussion can leave at that point. And if you want to receive a regular update on stories from team members, schedule a separate meeting. For instance, to be on track with the product teams, our designers at Eleken usually agree on regular meetings with a PO, that can be held every day, once a week, or at any other convenient time interval. There we can talk about current sprint progress, and roadblocks, or ask some specific questions.
To sum up
A Product Owner is a part of a Scrum team, who is responsible and accountable to deliver a working product at the end of each sprint. Therefore, even if a PO is not currently working on items in the sprint backlog as a developer, they still should join the Daily Scrum for quick decision-making and changing priorities in the sprint backlog.
Everything in the Daily Scrum should help the team collaborate together and move forward in reaching the sprint goal, and the Product Owner’s objectives during the Daily Scrum should also be directed to support this goal.
Figma Developer Handoff: Collaborate Like Eleken Designers
Designers and developers without exaggeration are people who turn ideas into real products. And how these two main groups of creators collaborate determines the quality of the end product.
Until recently designers and developers were often frustrated with their communication and felt like they were on different planets. Important details were getting lost, specs had to be written manually, and the whole collaboration process seemed to hover in open space.
Nowadays many designers including the Eleken team create designs and hand them over to developers in Figma. In this article, we will show you how we create designs of SaaS products and collaborate with different development teams using Figma as our main tool.
But first, let us remind you how designer-developer handoff used to work when Figma wasn’t around.
A little bit of history
Not a long time ago designers’ collaboration with the development team boiled down to sending tons of emails with ready design files, additional materials, and notes.
In case changes were needed, teams were exchanging messages and files again. And keeping track of design changes was another challenge.
Every designer who did this remembers how frustrating that was. And to be honest, developers can also relate.
Later tools evolved for the good, and developers started using different solutions designed for handoff. With the help of these tools, developers could extract the information they needed to implement design like color codes, fonts, measurements of elements, and other specs.
This made collaboration easier for developers, but as for designers, there was still some hassle, as they needed to keep their tools synced with other tools. But then Figma appeared on the market and quickly won the hearts of designers and the rest of the product teams.
How does Figma change designer-developer collaboration?
Figma takes collaboration between the design and development teams to the next level. When you’re a proud inventor of the time machine and don’t know what Figma is, it is a cloud-based software for collaborative interface design. All files are stored in the cloud and you can work in Figma directly from your browser or through the desktop application.
Collaboration in Figma has lots of benefits:
One of many reasons why not just designers but people who manage design teams love this tool is because Figma makes collaboration super easy. You literally need to just share Figma with developers by sending a link or invite:
Now designers can show their work in progress to the rest of the team in real-time, as well as share the previous versions. You can also jump into a call right in Figma to quickly discuss the details or leave comments on specific elements of design:
Figma design handoff explained by Eleken team
At Eleken, we design complex SaaS products, and collaboration with developers is extremely important for our work. That’s why we collaborate throughout the whole design process, not just when the design is ready for handoff.
Our design process usually goes as follows:
- Our designer receives direction and requirements from the product manager.
- He/she makes the UX research if needed and drafts a couple of design concepts then approves one with PM.
- Eleken designer, the client’s product manager, and the developers discuss technical details of design implementation.
- Eleken designer works on finalized design and hands it over to developers in Figma.
- Then starts the development phase, during which the designer stays in touch with developers in case minor corrections are needed.
For every new feature or set of screens, our designer has a separate page in Figma. The designer goes through several iterations to get the concept as close to the client’s vision of the product as possible. Then some details are added for the final variant when needed, and the design gets approved.
Right in the Figma file, the designer leaves comments for developers about what to pay attention to. Figma has a lot of features that allow describing right inside the component how it works. For example, you can leave a note about the most significant changes (like on the left screen below), or build user flows between actual screen designs (screen on the right).
We also recommend creating a design system in Figma. It’s like a shared library for your team, which is also helpful for developers. They can see the general structure of your design, review documentation, or search for design elements they need.
For example, Material Design from Google or Microsoft Teams UI Kit are very adaptable design systems backed up by open source code that certainly benefits your handoff process.
We often design prototypes and share them with the development team so they can see how the products are expected to look and work. The prototype also helps us to demonstrate how the aminated elements of design should behave.
By the way, a smoother developer handoff in Figma helped us improve our design operations by taking off some operational load from designers’ heads.
Eleken designer Roman says:
I don’t need to think of how to handoff design to a developer, I simply share a link. Guys pick up the design for implementation right there. If the correction is minor guys leave a comment about it directly in Figma and it’s super convenient and time-efficient.
What I love the most is that I don’t need to write any additional documentation with specifications. Developers get everything they need automatically in Figma.’
And that’s exactly how the magic happens - developers jump into your Figma file and have everything they need there to start bringing your designs to life.
How do developers use Figma?
After a developer opens a design file, they go to the right sidebar and click to see the details about the design elements. They can choose CSS, iOS, or Android depending on the technology they work with.
Developers can export these assets from Figma. Information about color codes and measurements of particular design elements can be easily connected to the tools that engineers use.
For that purpose, Figma offers many handy integrations with other products so everyone can connect their favorite tools and customize their workflow.
Figma handoff secret helpers - plugins
Here are the top ten Figma developer handoff plugins that you can share with your development team to make the handoff process even easier.
- Zeplin. If the development team you work with asks you to hand off the design in Zeplin, no need to worry, you can do it in one click from Figma. The tool will extract the design frames and specs to the developer's favorite tool.
- Gitlab. You can also easily upload your design to Gitlab, one of the largest open source code repositories and collaborative software development platforms.
- Zero Height. Sync up your Figma components and styles with the Zero Height platform and automate creating design systems and documentation.
- Avocode to easily translate your design into code.
- AWS Amplify studio plugin serves the same purpose as Avocode.
- Storybook add-on also helps to display code related to the story.
- Jira and Confluence. If your team uses these Atlassian products for workflow management, you can use Jira and Confluence in Figma.
- Notion, Slack, and many other productivity and design collaboration tools are available as Figma plugins.
But in general, there are over twenty plugins in Figma which makes the solution a favorite tool not only for designers.
In a nutshell
You can follow our checklist to ensure seamless design to development handoff in Figma.
- Start your collaboration with the development team early. Collaborate with developers on all stages of your design to make sure you create a design that can be technically implemented.
- Keep your files organized, one feature per one file. Messy work files are a sign of disrespect, not creativity.
- Leave notes and comments about design elements in Figma files, communication defeats misunderstandings and brings designer’s and dev’s planets closer.
- Build interactive prototypes instead of a thousand words! A prototype helps communicate your design ideas to others.
- Create a design system and share it with developers. Design systems in Figma are highly responsive and aligned with code.
- When handing off design to development in Figma try to think from developer’s perspective and provide details that will help others implement your design exactly how you intended.
Figma is like a super space station where the product is built and designers and developers can collaborate easily. The tool has made the design handoff process as quick as never before and serves product teams as the most collaborative design tool.
Eleken designers mastered all benefits of work in Figma and now cooperate in peace with any development teams creating skyrocket products! Curious to take a look? Check out our portfolio.
Your email has been submitted successfully. Check your email for first article we’ve sent you.
