See, for every need that a user has, there are a host of apps that provide a solution. That means your app needs to stand out from the crowd—not by being the flashiest or trendiest, but by providing the best experience possible for your users. And that all starts with Design Thinking.

Design Thinking is an iterative, five-stage process that puts the focus back on the user, from start to finish.

But what about my business goals? Are we just ignoring those? Not in the slightest. A major component of Design Thinking is first understanding what you hope to achieve and then translating that to a product that surprises and delights your users. In fact, focusing on the user oftentimes leads to a better-received app all around.

Now that we know why Design Thinking is so important, let’s jump into the five stages.

1. Ask, Listen & Ask Again – The Empathize Stage

Like any good process, Design Thinking starts with questions. A lot of questions. Who is using the app? What are they hoping to achieve from it? And, most importantly, what is going wrong, and why are they frustrated with the current user experience.

 Being able to empathize with the user on the good and the bad will help you hone in on what’s working (so you can do more of that) and what’s causing users the most headaches and why. Often this stage is done through observation of, and interviews with, the actual users of the app.

2. Context is Key – The Define Stage

It’s time to put all those answers to work. The goal here is to look at the observations through the lens of the overall business goals (see, we haven’t forgotten!) and define the most concrete and important issues for the users. In essence, it’s about framing the most pressing challenges in the context of what both the business and users expect from the app. 

3. A Brainstorm is a Brewing – The Ideate Stage

This is the fun part and the part that really anyone in the company can be part of. Now that the main issues have been identified, it’s time to come up with as many solutions as possible. It’s here that you think big and aren’t afraid to change your minds or contradict yourselves.

 At the end of the session, it’s time to pick the winners from the group. The criteria for a winner will vary by project, but overall you can ask yourself a couple of questions to help guide your decision.

• Which solution best benefits the user?
• Which one meets our business goals?
• What is the most viable from both a development and go-to-market standpoint?

 The answers to these questions should help you narrow in on the solution that will best fit your, and your users’, needs.

4. Putting Ideas into Action – The Prototype & Development Stage

It’s time for the virtual rubber to hit the digital road and see how that solution fares in the wild. It’s here, or a digital product agency, will first create a quick and dirty prototype to get a gut check on what works and what needs some tweaks. Employing an inexpensive, scaled-down version of the product/features and asking users to take a turn trying them out helps you narrow in on what’s doing the job, what isn’t, and why.

5. Hope You Studied – The Testing Stage

Finally, it’s time to send those prototypes through the wringer. You’ll break them in as many ways as possible and figure out everything that can go wrong. This is the redefine stage where you see the wreckage of solutions laid out in front of you, and learn from them.

Then, it’s iteration time. Taking all that you learned from what went wrong, you head back to The Prototype and Development stage. Change this, fine-tune that, get rid of that feature altogether—and then you test, and test, and test again.

Design Thinking is a practical way to solve problems. At once fixed and fluid, it provides the structure needed to build brilliant digital products and the flexibility to respond to last-minute changes. It’s a process and one that takes time to get running smoothly.

At Big Nerd Ranch, our senior-level designers and engineers work to continuously refine our approach to Design Thinking and Digital Product Development. So, if you’ve got a great idea or need some support on an existing app, we’d love to chat about how we can help put Design Thinking to work for you.

The post Five Stages of Design Thinking—and Why They Matter appeared first on Big Nerd Ranch.

When a client hires Big Nerd Ranch to build their product, they entrust us to build the best experience for their own customers. The Design team is responsible for ensuring that the product meets and exceeds the needs of the users. This, in turn, helps our clients attract and retain their customers.

Product design is like building a house, you must start with a solid foundation.

If creating an application is like building a house, it doesn’t make sense to pick out the paint and the fixtures until the walls, plumbing, and electrical are in. User Experience Design does not begin with the user interface. Rather, it concerns itself with how the user will complete the most important tasks, what data they will need, what data they will provide, and the path(s) that navigates them to their goals.

There are various methods of User Experience Design. An essential first step is to document the user flow. User flows communicate how the user will interact with the system and how the system itself can help the user complete a task. User flows are typically in a diagram format. They do not necessarily show how the user interface will support the completion of a task, rather they help the designer understand the steps and decisions points that are necessary for a user to complete a task.

User flows are based on prior knowledge of the domain and the user, gathered in the Discovery phase. Conducting user research is an essential part of being able to accurately document the user flow, and it is so essential that entire industries have been created around this goal. With either found research or freshly conducted research, the designer can start documenting how the user should move through the experience at a very high level.

From user flows, the designer can then move on to creating a sitemap or app map. This map is a way of organizing the sections of the application and all of the individual screens that support the needs of the user and the features that support them. From this, it is possible to decide on the best navigation for the application. Should it be a hierarchical navigation? A flat navigation or experience-driven navigation? These decisions cannot be made until a detailed map is rendered.

Without the user flows and app map, hastily drawn conclusions could result in a confusing navigation and an untidy collection of screens that place undue burden on the user. It should be fast, easy, and intuitive for a user to get content and complete tasks.

Finally, once the app map is created. The designer can start the task of designing wireframes. Wireframes are like the blueprints of the actual house. The wireframes do not concern themselves with color, typography, button styles, or other types of graphic content. Wireframes, rather, communicate the details of the screens that are required for the user to accomplish the tasks and where all of the content will appear on the screen. In keeping with our analogy, the designer is deciding on where to place certain walls, closets, doors, and so forth. But not deciding about the style of door, paint colors, fixtures and other things that make the house livable. That will get designed during the UI phase.

The wireframes are ultimately the most important deliverable of the UX Design phase. They will be used by the developers to start building the product. Many placeholders can be used at this time, but it is good practice for the designer to try to use as much real copy language and have as much information about the content as possible. This is where the product begins to really take shape. The designer may even create low-fidelity prototypes at this stage to validate certain design decisions.

“If you think good design is expensive, you should look at the costs of bad design.” – Dr. Ralf Speth

If the user experience is hastily designed, there is great risk that the app will not meet your customer’s expectations. The navigation, content organization, and essential features of the app require careful thought so that the user can begin the process of engaging and trusting your product. It is the designer’s job to design the best foundation possible. If you want to learn more, read our blog about the customer experience vs. user experience.

Interested in discovery, design, or app development? Reach out to Big Nerd Ranch today to talk about how we can work with your team.

The post Our Approach to User Experience Design appeared first on Big Nerd Ranch.

Design Discovery

At Big Nerd Ranch, we believe that projects are successful when Design is the tip of the spear. The Discovery phase of a project is an important step in determining the best path forward for the design and subsequent build of any application.

Sometimes it is difficult to make good decisions in the middle of a project when so many things are in flux. For this reason, we usually recommend a Discovery at the beginning of a project in order to deeply understand the problem or opportunity that needs to be solved. This phase allows us to design and develop the best solutions and promotes learning the essential goals of a project to reference throughout a project.

When do you need a Discovery?

A Discovery is recommended if:

• There is a new product idea that has not yet been designed or developed.
• The product exists, but requires a redesign.
• New, significant features need to be added to an existing product.

On some occasions, another short Discovery in the middle of a long project or after a major release can be helpful to make sure the product is still aligned with the project goals.

What do we learn in a Discovery?

In the design and development of any product, it is important that the designers and developers understand more than just user stories. During a Discovery, we seek to learn as much about the product, the company, and the customer as possible, so that we can ultimately make the best design decisions and create accurate user stories. We also seek to learn the constraints that will eliminate certain infeasible or unsustainable paths. To do this, we investigate many different areas of the project.

Users

Understanding the user and the user’s needs are fundamental to every project. In Discovery, we attempt to understand as much as possible about the user’s expectations toward this product or service, their behaviors, their motivations, and their needs. In doing so our designers can make better decisions for the user throughout the project.

Features

During Discovery, our team will begin to learn about features that require user interactions as well as anyobstacles to those features. Features that require the product to have built-in intelligence and logic, like learning your commuting route and optimizing your time to leave for example, demand extra attention in order to fully understand the scope and depth of the feature. This allows the team to make smart scoping decisions prior to getting into the feature work.

Content Sources & APIs

How will dynamic content will displayed in the app? Are there existing web services or APIs for dynamic content and data? How will that information be stored and what should happen when those content sources are not available? With knowledge of what data we have available, our team can better design and frame content while also keeping in mind error states, empty states, and how the UI should adapt to as content provided changes.

Data Inputs

There’s no doubt that we’ll need the user to input data of some kind. Understanding what data we’ll need, what’s the best way to obtain the data, and where it will be stored are all important questions to answer in Discovery. While we don’t expect the client to solve these problems, we definitely need to start the discussion early on in the project in order to avoid a significant roadblock later.

Constraints

Throughout Discovery, we’ll also uncover technical and business constraints that are inherent to the business (legal, financial, etc.) or that may exist in development. Understanding these constraints help us align the design of the end experience with the goals of the project and ensure that the product will avoid technical blockers.

Discovery Methods

How do we uncover this information in the Discovery phase? There are many methods inherent to User Experience design that allow us to efficiently gain as much learning as possible. The designer(s) will use the methods that best reveal the learnings that must take place during this phase.

Overall, these methods will guide the discussion between the Big Nerd Ranch team and the client team in a productive manner. They facilitate deep investigation and sharing.

Some of these methods include:

• Card sorting
• Feature definition/prioritization
• Persona identification
• Stakeholder interviews
• Competitive analysis
• Rapid prototyping

Discovery Duration and Delivery

Based on the learnings conducted during the Discovery, the designer will put together documents that explain the scope of the application and identifies the users and their motivations. Features will be explored and user flows will be documented. From the overall scope and feature set, the app map starts to take shape.

An App Map details the user experience at a high level, giving the team context on the navigation and feature scope.

The hands-on portion of the Discovery (with the client) can take 3 to 5 business days and will involve lots of group discussion and exercises. The entire Discovery can usually take 1-3 weeks depending on the complexity of the product features.

As a partner to the client, we must learn as much about their business and customers as possible, so that every decision we make in the design and development of the product aligns with their goals. As experts in user experience, we can then advocate for the overall best designs given all of the various goals, needs, and constraints that exist.

Overall, the Discovery is a critical phase of learning that prepares the entire team to design UI, plan sprints, and write stories throughout product design and development. At Big Nerd Ranch, we feel that Discovery helps our clients make better decisions both at the beginning and throughout the project.

Interested in discovery, design, or app development? Reach out to Big Nerd Ranch today to talk about how we can work with your team.

The post Design Discovery Overview appeared first on Big Nerd Ranch.

A famous economist once said about consumers, “People don’t want a ¼ inch drill. They want a ¼ inch hole.” While not formally a designer, Theodore Levitt understood the difference between identifying the problem and coming up with the right solution for a customer.

Most people accept without question the tools or solutions that are designed for them, until that solution becomes more of a pain or detriment than it’s worth. Your customers always want to get their outcome as quickly and painlessly as possible. Occasionally, they want to arrive at their outcome with a smile on their face, but it’s mostly about getting the job done. As such, it is critical to understand the user’s actual problem, and job stories are an effective way of uncovering the problem and designing for it.

Traditional User Stories

Here’s the problem: traditional user stories fall short as a tool to aid designers in arriving at the best solution for the user, given all of the existing constraints. Why? Traditional user stories, as they are written, presuppose or imply a solution without question. Assumptions are embedded in many user stories and the team blindly follows them or inserts their own meaning, often without there being a full discussion about these assumptions and presuppositions.

In the case of the drill example above, a typical user story might read:

As John the handyman, I should be able to drill a 1/4 inch hole into the wall.

Firstly, the most descriptive users stories start with a persona; however, in practice, most people just revert to writing “As a user…”, which is even less helpful. Including “As a user…” to every user story doesn’t provide much actual value to solving the user’s problem.

After framing the persona, a typical user story will then suggest a solution. “I should be able to drill…” “I should see a notification…” “I should be able to view a list of…” “I should be able to confirm…” Like I mentioned, this is one of the big problems with the typical user story: the solution is assumed and implied. For the designer, we should never start here. The solution is arrived at through open-ended questions and understandings of the user’s needs, their motivations, and their intended outcome.

Traditionally, user stories lack a lot of information about the user’s actual problem. Because of this, it becomes too easy to imply a default solution which may not actually be the right one. This is where the JOB STORY comes in.

Job Stories

The job story began with the work of Harvard business school professor, Clayton Christensen. To better understand how to improve and market products (even milkshakes), his team began asking “What job do people hire this product to do?”. In order to really understand the consumer (the user) better, the team wanted to deeply understand what motivated the consumer to buy a product. By understanding the consumer’s motivations and their context, the team was able to optimize the product in the best possible way.

The job story is about context, motivation and causality – can we design a solution that works for the situation and causes the expected outcome that the user needs and expects?

The format of a job story is critical, but it’s a pretty simple format to follow:

When ____[SITUATION]____,

I want to ____[MOTIVATION]____

So I can ____[EXPECTED OUTCOME]____.

In the above example, the job story might go something like this:

When I’m ready to hang a shelf, I want the shelf to be secured into the stud, so that my shelf can hold many things of varying weight without falling off the wall.

There is a pretty established set of solutions for this everyday example, so much so that it is difficult to avoid vocabulary like “screw”, “drill”, and so forth. If we’re trying to innovate and disrupt the drill and shelf industry, then we need to eschew many of the usual industry assumptions and solutions.

The above example is about a physical product, but the need for authentic innovation is especially critical in digital products. The established solutions to things like profile views, settings, notifications, search, composing content, etc. could stand for original thought. Of course, we want our users to recognize familiar UI patterns, but by using job stories we can challenge certain assumptions. For example, does your app even need a profile view? Many social media apps rightfully have a profile view that caters to the user’s needs; however, these profile views have begun cropping up in payment apps, weather apps, and just about anywhere else you could imagine it being useless. By posing the problem instead of the previously designed, junk-drawer solution, you can challenge this status quo with a solution that targets your user’s specific problem.

In the context of a digital product, a job story might state:

“When my credit card expires, I want to be able to change my credit card so that I can continue purchasing without any problems.”

This job story helps us plan for the user-initiated credit card expiration. It also doesn’t assume that the credit card information MUST be part of a profile view. It allows the designer to try many options for where and how the user accesses their credit card data. Additionally, this job story could spark in us the idea that maybe the user should be notified, as in:

“When my credit card expires, I want to be notified so that I can update my information without any disruptions to my service.”

In order to think through the context and situation, think about the user’s motivation. This will help create the best solution for the user, and also helps to identify gaps in the design that need to be addressed either now or in the future.

Design for the Problem Instead of a Solution

Agile software development advocates for writing good user stories, but in my experience, many user stories are hastily written and imply a solution without the problem being fully understood yet. To designers, job stories are the most effective tool to understanding the user and the problem that they need solved. We should never think that the app we are designing is, in and of itself, the thing that the user wants or needs. What we can only hope to do is to provide them with a tool that is the best, given all of the constraints, at delivering the outcome the user desires. At the end of the day, a person hanging a shelf wants a ¼” hole in the wall, not a ¼” drill.

The post The Effectiveness of Job Stories appeared first on Big Nerd Ranch.

This past week, I had the pleasure of attending a great conference right in the heart of Georgia called Creative South. It was my first time at the conference and y’all… if you’re a creative-type person, you should definitely check it out.

The first day was full of workshops and I got my day started early with a mobile design workshop. This was the only real digital design offering on the agenda the whole weekend; the rest was mainly graphic, typography, illustration and lettering. Naturally, I had to attend the mobile design course. I love mobile design. And I teach mobile design, so it was a great fit.

The talented Rick Messer from Funsize, a super-cool Austin agency, taught the class, and while I don’t envy his position of trying to teach mobile design in four hours, he did a great job.

Intensive Training

As a self-taught designer myself, I’ve had to piece together many things on my own. Now that I teach design bootcamps at Big Nerd Ranch, I have a sense of the depth that is required in a workshop so that students can truly take away useful tools.

The Creative South workshop got me thinking, though. What do designers, who may have little to no experience with mobile design, want and expect out of courses? Do web designers or graphic designers see the value of an extended, in-depth course like we offer at Big Nerd Ranch?

We pride ourselves on the level of rigor that it takes to get through one of our bootcamps. The training we offer is above and beyond what you’ll be able to find on YouTube or collect in any online school.

Our technical bootcamps are for app developers who have read the books, scoured the web, and want more intensive training that will prepare them for the big leagues. Our design courses are the same level of intensity, and for very good reason. Let me explain.

A Deep Dive into Topics

The mobile app design process deviates from web design in critical ways. During most courses you’ll find online, the basics will be covered in a couple of hours: app concepting, basic app flow, user interface elements, wireframes, maybe visual design and maybe prototyping. Especially in workshops where the students are also creating screens and the instructor is giving feedback, it is nearly impossible to get even this much into a few hours.

That is why we created a curriculum where we dive deep into topics that are not normally included in most mobile design courses. We cover topics such as how to design a temporary modal that fits with the overall interaction design of your app, or mobile animations and transitions, how to optimize your iPhone app for the iPad, typographic hierarchy, different navigational models and when to use them, mobile design trends, and how to export your assets the right way so that your developer doesn’t have to come back to you for more.

Throughout the entirety of our bootcamps, students do exercises so that they can apply their knowledge in context. The instructor gives one-on-one feedback and students can learn by doing. We’ve carefully crafted these courses so that designers can confidently start designing a mobile app right away.

Unmatched value

I believe that the value of our in-depth bootcamps cannot be matched. I know that the students who have left our design courses feel confident about what they learned. They understand the essence of mobile design and how it differs from web or graphic design. We’ve refined our materials and training over the years to make it the most in-depth but practical courses for mobile designers. I’m proud of the bootcamps we offer and have a new appreciation for the empowerment we offer students.

Are you ready to get started? Sign up for our next iOS Mobile Design or Android Mobile Design bootcamps, kicking off in May.

The post Our Mobile Design Courses Will Prepare You for the Big Leagues appeared first on Big Nerd Ranch.

Fumbling with a bunch of credit cards and a wallet is a hassle. Who wouldn’t prefer to just use their phone or smart watch for transactions? But are we giving up security in the name of convenience?

I don’t think so. Not only is Apple Pay convenient and easy to use, you will not find a more secure form of credit card payment today—period.

There are four basic things to understand about Apple Pay’s security:

• What happens when you link a credit card to Passbook?
• What is the secure element?
• What happens when you make a purchase?
• Is any of your financial data stored in the cloud?

Linking Your Credit Card to Passbook

The foundation of Apple’s security lies in the secure element in the phone, and the way credit cards are authenticated when they are added to Passbook. The process of adding your credit card to Passbook looks like this:

1. When you scan or manually enter your credit card into Passbook, Apple sends an encrypted message to the credit card networks (Visa, Mastercard or American Express), who in turn pass it on to the credit card issuer.
2. In this message is a request for a token and a cryptogram, which makes the iPhone the token requester (I’ll talk more about tokens and cryptograms later, but for right now, it’s important to know that the iPhone requests the tokens).
3. The credit card issuer sends back a token and cryptogram, making the issuer the token provider (this is also important). Therefore, the issuers are responsible for the security of the token and cryptogram.
4. The secure element on the iPhone is the only thing that stores the token and cryptogram. These items are not stored on Apple’s servers. The secure element is the only thing that contains this data. And because the data there is not actually your credit card number, you don’t have to cancel your credit card if you lose your phone. You simply disable your phone.
5. The last four digits of your credit card are the only thing in Passbook that resembles your credit card. This is to help distinguish the credit cards in Passbook; if you’re like me and have two cards from the same bank, you need to see the last four digits.

The fact that the credit card issuers are the token provider is important because at no time does Apple create, contain or store the token. The onus and liability is completely on the credit card issuer.

Additionally, the token and the cryptogram are not just encrypted versions of the credit card number. They are actually completely separate data. Therefore, the token and cryptogram cannot be decrypted to reveal your actual credit card number.

The Secure Element (and Tokens)

So, how secure is the secure element, really? The secure element is a chip inside the iPhone 6 and 6 Plus where the token and cryptogram are stored. The software accesses this hardware only when you link a credit card to Passbook or a transaction is being made. The data on the chip is never passed to the software for use within the operating system, which is where breaches normally occur. If someone were to hack your operating system, there would be no way to extract the financial information.

The token stored on the secure element is unique to your device, not just a replacement of your credit card number. Tokens are meaningless mathematical strings, which cannot be decrypted back to an account number. Furthermore, they’re useless on their own because they require both the device and the cryptogram to work. Only the token provider can map the token back to the account, and as I mentioned earlier, Apple cannot do this. The token isn’t stored in Apple’s servers anywhere—it is stored only on the secure element in your phone.

Making a Purchase with Apple Pay

When you make a purchase with Apple Pay, Touch ID is required as part of the authentication process. The biometrics of touch ID are not completely 100% secure, as we’ve seen in the past few months. However, it is still leaps and bounds ahead of any signature or PIN-based user authentication. I would rely upon my fingerprint over a PIN any day.

When you make a purchase:

1. The NFC reader recognizes the NFC chip in your iPhone 6 or 6 Plus. The secure element then sends the token and cryptogram to the retailer.
2. The cryptogram is sent to the credit card network, which determines whether it is authentic. If so, it then sends the token to the authorizing bank (the credit card issuer), which decrypts the token.
3. The bank recognizes the token it established when you linked your credit card to Passbook. It authorizes the transaction and sends back the authorization to the retailer.

The cryptogram is a layer of security in which part of it is dynamically created per transaction; it links the token to the device and that particular transaction. Tokens can never be used without an accompanying cryptogram and the cryptogram ensures that the token can only be used from the device in which it was originally linked.

The important fact here is that the retailer never has possession of your actual credit card number in any part of the transaction. That is a distinct difference from the credit card magnetic swipe we have today, where the exact credit card number is unmasked and sent directly to the retailer’s point-of-sale system. This is the weak point where hackers have intercepted credit card numbers at Target, Home Depot and others.

The Cloud

Apple does not store your credit card number in the cloud during any part of linking your credit card or making a transaction. The only thing stored is the token and that is stored in the secure element. This is a distinct difference between Apple Pay and Google Wallet. Google actually stores your credit card number in order to facilitate the transaction. The authorization of the transaction first hits their servers, is decrypted, and then goes to the bank that issues the credit card. Google also requests and stores your Social Security Number when setting up Google Wallet.

With Apple Pay, the only party to actually store the credit card number and associated token is the credit card issuer themselves.

Safe Financial Data

Credit cards with magnetics strips are the least secure form of payment. There are many tech companies vying to replace your old credit card, but if we’ve learned anything from the recent data breaches, it’s that we should not trust a payment solution that decrypts and stores our account numbers in a server that can be compromised by hackers.

While banks still hold this information, the responsibility for storing our financial data should be on the banks, and not with tech companies or retailers. Apple Pay does just that.

The post Why Apple Pay is the Most Secure Form of Payment appeared first on Big Nerd Ranch.

Adobe Illustrator is great for creating wireframes and visual designs, and for some of us designers at Big Nerd Ranch, it’s the primary tool we use for client apps and internal projects. Here are some of our favorite tricks and tips.

Symbols

Symbols are essential for designing interfaces in Illustrator. If you’re not using them, you should be. Symbols are perfect for anything that will be reused in your designs—and as we all know, when designing interfaces, many elements should be reused.

When you create an icon or button, just drag that object into the Symbols panel, and a symbol is created for you. From that point on, you can just drag the symbol onto your artboard.

Why not just copy and paste? Well, when the client asks for a change later, you can change the symbol once and it will update everywhere in your Illustrator file, across all artboards.

If you have created a set of symbols during the wireframe phase, then there’s a good chance that symbol will evolve into a visual element that will need to be part of the style guide for the final product. If it’s reusable, then a visual language can start from your symbols panel.

Appearance Panel

Speaking of panels, the Appearance panel can be used in a very powerful way to create visual graphics that can also be reused.

This tutorial and others opened my eyes to the power of using multiple fills, strokes and effects within the appearance panel on a single object.

This is an example of just how complex the Appearance panel can become on a single object.

Then, when you’re happy with the appearance, you can drag the object to the Graphic Styles panel and reuse that appearance on other objects. This technique can even be used on typography in really interesting and creative ways.

Pixel Perfect

If you want your designs to be tight and clean on device or on the web, then you’ll want to start your AI documents with these settings.

When you create a new document, make sure you are working in pixel units and have Align New Objects to Pixel Grid checked.

Then, in your General Settings, make sure your grid and keyboard increments line up to individual pixels.

I have a gridline every 64 or 8, depending on the project. But make sure that subdivision divides into individual pixels.

Then if your keyboard increment is every 1px, you can be sure that you’re nudging on the pixel grid.

That’s not all. If you want things to be pixel perfect, you MUST make sure that Snap to Grid is checked. This is very important. If this isn’t checked, you may still get objects that sit on half a pixel (which will cause a fuzzy edge).

From that point on, use the Pixel Preview option in the same View menu to check your design and see how much anti-aliasing is being applied. It’s possible something is falling off of the pixel grid and could use a little tightening up.

I’ll have more tips and tricks to come in a future post, but if you can’t get enough of learning about design best practices, check out our iOS Mobile Design and Android Mobile Design bootcamps.

The post Designing with Illustrator: Tips and Tricks, Part I appeared first on Big Nerd Ranch.