I need to start off this lesson with a big disclaimer…
I don’t use Material design that often. At all.
There have been times when I’ve used the Floating Action Button or the FAB as well as the dimensional shadows, but that is really the two main things I’ve used from the guildelines.
The simple reason for that is I’ve been an iOS guy since 2007 and have never personally owned an Android phone, except for a brief one week stint with the Google Pixel, which was cool, but I decided I couldn’t bring myself to switch.
The primary reason I’ve used Material Design as a reference in the past has been for converting original iOS designs into Android-based designs.
If you are designing specifically for Android and the developer or development team you are working with is coding a native Android app, then you should definitely consult the Material Design guidelines and become as familiar with them as possible.
Even if you’re not designing specifically for Android right now, it’s definitely worth taking a look and reading through anyways, there is some really good stuff in there.
The Components Section is probably the most relevant for understanding tje individual design patterns.
iOS HIG or Material Design?
This is a loaded question and depends on your overall preference for different ecosystems. Again, it also depends on the goals of your project.
I will say from experience, I’ve worked with big and small clients designing their mobile apps, and every single one of them wanted to design an iOS app first and then “shoehorn” it in to an Android app.
iOS guidelines have existed longer than Material and have also remained a lot more unchanged over the years. A few years back Material added in the bottom tab bar for navigation whereas previous years they recommended a top navigation.
The Case for Hybrid
Using web technologies for native apps used to mean a very lackluster experience, but the web seems to have caught up with performance and is now capable of producing very similar experiences to native ones.
The appeal is very high to code one “responsive” app and have it work on both iOS and Android. This means that you may have more flexibility with the design patterns you use, even combining parts of iOS and Material.
The downside is that frameworks like React Native often change very frequently—much more often than native mobile frameworks—and can create lots of code problems.
This is all knowledge to equip yourself with before you begin designing someone’s mobile app. This needs to be a big part of the conversation so you’ll know whether or not you’ll have easy access to iOS or Material’s built in capabilities while you design. Not everything always needs to be completely custom.
Steady – Case Study
Steady was a mobile app project I worked on for a VC firm based on of New York.
Fun fact, Steady has Shaquille O’neal as their spokesperson.
The project began as 100% iOS-focused and then I “converted” the designs to Material-type designs for Android.
Android survey using the more standard Material-based progress tracker
iOS detail views
Android detail views
Roadie – Case Study
Roadie was another mobile project that started exclusively as an iOS design and then got converted to Android in the eleventh hour by following the Material guidelines.
iOS style guide
Android style guide
Take the designs you created for the previous iOS lesson and modify them using Material Design Guidelines. If you’re uncertain if anything should change, look up your specific component in their documentation.
The biggest change will likely be repositioning the ( + write ) button into a FAB.
Once you’re done with both iOS and Android, see if you can merge the things you like about each one into more of a hybrid-style app that may be built using web technologies instead of native.
Design Doc Organization
It’s ok to design messy at first…
But at a certain point though, you will need to get organized.
Clean up as it makes sense for you, but make sure to keep your old designs.
Maybe you clean up your files before a design review. Maybe you tidy things before you share your files with another designer.
- Start off by designing in an exploration document. See No-stress Design Experiments
- Use a versioning system that makes sense to you. See Organizing Design Projects and Figma Organization
- Consider using the
UXindentifier in your file name if you’re designing in low fidelity. (eg.
Cool Project Onboarding UX MDS v0.1)
- Consider using the
UIindentifier in your file name if you’re designing high fidelity. (eg.
Once you have a certain style in place and you’re starting to solidy some design decisions, it can be helpful to start getting even more organized with your design file(s).
There are three main types of design document organization that I’ve used in the past:
- Single File
- Single File with Pages
- Multiple Files
Regardless of the document organization method you choose, it’s always smart to organize your files by sections or features.
Think about the way you’d like to present your designs—the stories behind what you’re making. This might help inform you to name things a certain way if you know you’ll have to expain yourself later.
If your project is on the small-side in terms of features and/or team members, you can absolutely keep everything in one design document.
The key is to organize the frames or artboards by section. Take a look at the MyMonero artboard below. I’ve organized each row of artboards by feature. To keep them even more organized, I’ve added a number prefix so when they’re exported for viewing by the client or the devloper, everything tells a logical story.
Here’s how the features are organized:
- About Page
- Onboarding (or FTUX for "first-time user experience)
- New Wallet – This is the first thing a user does after onboarding
- Wallets – This is the view of the wallet(s) once created
- Send Monero – Sending Monero from your wallet
- Request Monero – Receving Monero into your wallet
- Contacts – Contacts that you’ve saved to transfer money to/from
- Preferences – App preferences
- Abstract – Used for various items like input states, loaders, etc.
The numbering system above just felt logical, so I went with it. There are no rules that Abstract type elemtents need to go last or that the About page should go first. I made a decision on the best way to present the information.
Rows of artboards organized by feature. Download the Sketch file here.
You can see the exported frames here are nice and organized because of the artboard names that were created inside of Sketch. See the actual files here.
Another example of a Single File with rows of features. Download the Cinesampler Sketch file.
Note how I’m using the following page structure in the Contrast 2.0 design document.
- Contrast 2.0
Screenshot of the Contrast 2.0 component view
Contrast 2.0 Single File system
Single File with Pages
Sometimes you may have too many screens to fit on one single page view, but you like to keep everything in one file. That’s what I did in the Skyscanner iOS app. Notice the same basic system applies where I’m numbering sections of the app based on sections or features, but instead of single rows over and over on one page, I’m using the additional Pages shown in the left column in the example below.
Note the numbered pages in the left column. Download the Sketch files here.
This can be a really affective way to organize files in Figma as well since you can link to individual pages within the same file.
Sometimes design files can get too complex for one single design document or maybe it’s easier to have access to specific parts of the design at the file level vs. having to dig through a bunch of pages.
Even the MyMonero project that I used the Single File method for the UI, used the mutliple file method for the lower fidelity wireframes. There was a lot of screens designed along with flows and annotations and I felt it was getting too complex to keep in just one file.
Another example when Mulitple files might be a better option is when you’re working with a larger team or larger client and documentation and organization are more critical. You can see that I ended up delivering the Smartline design files to GoDaddy in this way with the Framer X files.
Notice also how I’ve separated iOS, Android, and Presentation folders that all also contain design files.
Sorry can’t link to these files right now.
Keeping things loose and unorganized is definitely underrated. Often times getting too systematic too quickly can stifle creativity and create unneccesary problems. It’s good to follow certain guidelines, but you also want room to explore and have happy accidents.
“We don’t make mistakes, just happy little accidents.” —Bob Ross
Here’s a few screenshots from some of my unorganized files so that you can set your mind at ease just because you don’t have some layers named or files strictly organized.
While I did have the final deliverables for the Smartline designs very well organized, you can see in my Figma file that there is definitley a bunch of random projects in there that aren’t as intentionally orgnanized.
Here’s a fairly unorganized Figma project for FibreStream. I only needed to share the one Customer Dashboard v1.0 file with the client, so I was a lot more loose with the overall project structure.
Note that even in the Figma file I didn’t bother naming artboards with a prefixed number, I simply placed large type on the canvas in a Single File type structure.
Quickly rename multiple artboards inside of Figma by
shift selecting the frames and then pressing
⌘ R to launch the Rename layer modal. This is really handy for quickly renaming certain sections, etc.
Here you can find and replace certain words or give everthing the same name with an ascending or descending number.
In Sketch, the plugin Rename It works really well for batch renaming things.
Next time you start a project try the following organization steps:
- One file that you use for pure exploration
App UI Exploration v0.1
- Maybe a second file that is tightened up and ready for presentation to an inner-circle of designers and project managers.
App UI Exploration v0.2
- Maybe a third file that incorporates their feedback and is even more thoughtfully organized for presentation to directors and executives.
App UI Direction v1.0Note the name change from “Exploration” to “Direction” This isn’t critical, but it always helps to be very intentional when you do decide to name things.
- Decide later if you want to approach your design file organization with a Single view, a Single view with pages, or a Multiple file system
- It’s worth noting that Multiple file systems can often work better when projects get much larger and all pull components from a common library, or single source of truth.
Leading Design Reviews
- Make sure you have an agenda—a list of items to be discussed.
- Always present your own work when possible.
- Always present in-person or over video share.
- Don’t send files over before the first round of reviews. Later in a project can be slightly different.
Know if your design review needs to be informal, semi-formal, or formal.
It’s also important to know if your review needs to be collaborative, persuasive, informative, or demonstrative. Often times a design review will contain all four of these perspectives, but it’s important to know your goals for the meeting and the hopes, dreams, and fears of everyone else involved as well.
An informal review might be a simple walk through of your design document and telling the story of designs you tried and things that didn’t work, which ultimately led up to the latest and greatest designs.
This is the reason I like to say “keep the crap.” Keeping your old designs gives you an archive of older decisions that you decided were not the right direction. That way if any design objectives come up on something that you’ve already tried, you can quickly pull it up and show that option and explain why it didn’t work.
This might be a one on one meeting with a single stakeholder or it could be a meeting between a handful of internal designers, thinking through and collaborating on ideas, tossing things back and forth.
An informal design review is one of my favorite types of review because you can keep the review as half presentation and half conversation. You can even make live changes on the meeting if you feel comfortable doing so.
I like to walk through old designs first and explain what I initially tried, why I decided against certain things, and then ultimately landed on the current designs.
I’ll then follow up any thing that I’m still not certain about and open up for suggestions and feedback.
With an informal review, it’s less about an official agenda and more about making forward progress with the designs in general.
Walking through your No-stress Design Experiments would be an example of an informal review.
Informal Siempo review
Informal review of Fibrestream explorations
A semi-formal review would likely not involve panning around and walking other through your design document, but rather an exported batch of screens that you methodically cycle through in a very pre-meditated fashion.
This will always depend on the nature of the team involved in the design process, but also on the state of the designs as well.
This might be when you’ve incorporated feedback and are presenting designs based on the feedback, while another stakeholder is involved.
This might be a click-through prototype in InVision, numbered screens in Dropbox, etc.
Often times a semi-formal presentation is less about full collaboriation and more focused on informative and persuasive.
Most semi-formal meetings would have the agenda of reviewing a proposed solution and discussion around next steps.
Often semi-formal reviews would lead to approval or green lighting certain designs.
Semi-formal Fibrestream review
Walking through the “availability” designs. Get the sketch files here.
A formal presentation would be a full-on actual presentation complete with previously created slides and a very calculated walk-through of things.
This might be something that happens near the end of a project within an organization when a final fun-down needs to happen at the executive level.
In a formal presentation there isn’t room for any design fluff or talks about button radius etc. It’s mostly focused on how the design meets the user and business objectives.
There may be the odd scenario when a major stakeholder has questions about design details, but this would be more of the exception and not the norm.
12Stone Website Keynote – Formal Prensentation
Smartline Formal Review
Below is an example review where I built an entire presentation inside of Keynote for an official design review for a handful of project managers, designers, and the head of product and design.
In this particular design review I had already previous collaborated with other designers and a more free form screenshare where I simply clicked around and talked through some ideas in my design files.
Everyone involved in the presentation had already been exposed to the design style and the overall direction was pretty much locked in. At this point we were reviewing significant changes to the onboarding flow.
The Head of Product wanted to be able to circulate a video form of the live presentation to some of here upper level executives and adjacent teams, so I made a recap video for her to do that.
Onboarding presentation for posterity.
Revisions are a good thing
Critical feedback can sometimes sting, especially when you’re first starting out. It helps to disassociate yourself from the work as much as you can, but I know this can be hard to do.
Think of yourself as a solid teammate with the person you’re presenting too. Don’t think of them as the evil client or any other negative type thing.
You will ALWAYS need to deal with feedback on every single project and the best way to deal with it is a friendly non-defensive demeanor. Try your absolute best to keep emotion out of the discussion and keep things as logical as possible.
- Live file revisions
- Live comments after the meeting
- Follow up with revisions implemented
At the very least, bookmark this lesson and use it as a refresher when you need to present the designs you’ve been working on.
If you feel up for it, record yourself presenting any design of your choice in an “informal” way, talking through things you tried and how you ended up on certain design decisions.
Loom is a great tool for doing this. It’s what I use for all of my design reviews.
'5 Phases of Prototyping
Experiemental, playing around, asking “What if?” See some conceptual prototypes here.
This is how I think it should be and this is my attempt to persuade you into thinking the same thing. Prove a theory, build trst, convince someone of something. See some persuasive prototypes here.
Validation – Techinical feasibility, showing the flow, everything makes sense. See some validation prototypes here.
Instructional – Here’s how it works. See some instructional prototypes here.
The Thing – Build something quickly. Bootstrap. Tailwind. HTML/CSS. Design system. See some “the thing” prototypes here.
Prototype Mastery – presentation I gave at Atlanta Web Design Group
Knowing when and why to prototype is equally important as knowing how
SFWCo – Conceptual prototype made at Adobe Headquarters
After some deliberation, I decided to design a simple sandwich building app for a fictitious company called, San Franwich Co.
View my blog post that includes the wireframe, the UI designs, and the prototype. Download the XD files here.
More prototype files to include:
- Studio prototype files
- Case Basis
Lateshift wireframe/flow prototype
This was a prototype for a mobile experience that attempted to cater to three different types of users. The first screen is a prototype landing page that allows the internal team to see what happens for different types of flow scenarios.
The prototype also includes annotations in the footer of each screen to provide a little more context for what’s happening.
Download the XD file here
Exported Framer X prototype hosted on a live site.
Case Basis Handoff
HTML prototype that served as a design review, prototype, and hand-off tool in one. View the live version here.
More formalized animations for review. Less exploration and discussion, more showcasing and informing.
Detailed animated prototype of the Siempo OS
Demo of “flow mode” for Siempo
Simple tricks to keep in mind for screen-to-screen animations
- Positioning X axis (left to right)
- Positioning Y axis (top to bottom)
- Positioning Z axis (scaling up or down)
- Fading in or out (opacity)
- Changing color
- Using masks
Switch to Studio Animation
Checkout some of my videos on switchtostudio.com to learn how to make animation-based prototypes. Invision sponsored that project for me (ie: they paid me), which is why it’s shown using exclusively Studio.
Figma, XD, and Framer are great for prototyping as well. Lots of people have been using Principle for animation-based prototypes too, I just haven’t used it that much.
Figma Smart Animation
Sketch file video walkthrough for developers
The Sketch file can be downloaded from here: https://sketch.cloud/s/jVrnW
Prototypes for the Same Project
- Desktop: https://invis.io/TRGKB7FQWUF#/288665814_home_2-1
- Mobile: https://invis.io/EWGNPKLBQCK#/288928956_home_Mobile_2-1
- Modals: https://invis.io/WBGQA69DG2H#/289780657_home_-_Alt_Header
- Home address interaction: https://projects.invisionapp.com/prototype/fibreHome-form-demo-cjfk0szdb00akff01ww3242fg/play/b18e400a
Here’s a really enlightening thread, directly from a bunch of developers on Twitter, about why the idea of a “hand-off” is a problem to begin with.
Check out the completely overkilled website I made for the file hand off
Click here to view the Paper document. I’ve removed the links to the files for NDA reasons.
Case Basis Handoff
HTML prototype that served as a design review, prototype, and hand-off tool in one. View the live version here.
Communicate with your developers.
Ask them questions along the way. You’re all on the same team.
Pricing & Getting Work
Freelance Fire - View PDF
Freelance Fire is a book a started writing back in 2013 or so and never finished. It tells my origin story as a designer and how I slowly but surely “leveled up” in terms of pricing and projects. You can read in it’s current unfinished form in about 45 minutes. While it’s not fully complete, there is a ton of information in there about pricing and rates, complete with actual $ numbers and all.
This is a great (short) ebook and article written by Dan Mall
The Thing with Money
This is an article I wrote that answered some questions from someone who was getting into freelancing and wasn’t quite sure how the whole process worked.
Consider value is the biggest deciding factor…
- Value for you
- Value for the client
- Value for an hour
- Value for a day
- Value for a week
- Value for a project
The value someone is willing to pay must be equal to or greater than the amount of money you’re willing to do the work for. Otherwise it’s not going to work.
Never Split the Difference
The absolute BEST book you will ever read on negotiating just about anything. It’s filled with soooo many practical tips and great stories. Highly recommended.
Great book on psychology. Not necessarily directly tied to pricing and money, but definitley related. It’s always good to study psychology for matters involving humans (eg. basically everything)
The best ways to get work
- Let people know you are available and looking for XYZ type of work.
- Post work online to Twitter, Dribbble, and Instagram that is the kind of work you want to get, assuming you are looking for work. Don’t post a bunch of t-shirt designs if you’re looking for mobile app design work. Don’t post a bunch of logos, if you’re looking for responsive web app work. It’s OK to post conceptual work. The more work you post within a certain platform (eg. iOS) the more inquiries you will receive about producing that type of work for someone else.
- Be socialable online with people who work at companies that you’d like to work for or do work for. DM other designers and ask them simple, but direct questions about what it’s like to work there, etc.
- Making friends in the tech industry is the same thing as networking, just not in a sleezy way.
- Doing work for free is OK sometimes as long as YOU control the timeline, creative, etc. and you have strategically decided to do the free work on your own in an effort for possible future returns. Never let someone convince you to work for free when you don’t
Personal finances are directly tied to freelancing
The more you “need” money, the less negotiating power you have becuase you will want anything available and that will mean less than ideal clients or even things that you aren’t that excited about. Trust me that I’ve done toooooooooooons of work like this. There’s nothing wrong with that, just be aware of it.
The more money you have saved (3-6 months expense for example) the more power you have when negotiating. You can stand more firm on a certain price, etc. when negotiating and you can feel less afraid of “losing work” because you aren’t struggling at the moment. This can be a double edge sword though becuase if you stand too firm for too long, you’ll run out of money and become desperate again. It’s definitely a balance.
Cashflow is also a very real thing. If you have bills due and outstanding invoices that haven’t been paid, you can find yourself in a bad predicament.
Always dicuss and decide on payment terms BEFORE the project starts and get it in writing!
MSA & SOW
Here is the Master Service Agreement and Statement of Work template I use. I hired a lawyer a long time ago to create this for me and I’ve made tweaks here and there over the years.
- Master Service Agreement (PDF and Markdown File)
- I use iA Writer’s Metadata features for the variables inside the contract.
An MSA is mostly a standard agreement that says each party is going to do what they say they’re going to do, when they said they would do it, and what happens if they don’t.
An SOW contains the details of each individual project.
- List of deliverables
- Payment terms
Larger clients will often send you their own MSA or SOW for you to sign. NEVER sign a service agreement or SOW blindly. Read the whole thing and push back on anything that doesn’t sit right with you. Trust your gut. It’s OK to ask questions about it before you move forward.
If a client decides to cancel a project because you asked questions about the contract or requested revisions, then you’re most likely better off finding a new client, even if it sucks in the short term. For the record, I’ve never had a client back out during a contract negotiation—assuming we’ve already agreed on overall price and timeline.
Here’s a great thread on the pricing models listed above. Click through to read the full thread.
Also, don’t accept “years experience required” as something that can’t be bent, changed, or manipulated. Everyone hiring is human and has some wiggle room for change of perspective.
It goes down in the DMs…