Subjects of Study
The links below are to the parent GitHub repos of completed courses, resources, my own notes, links to articles, etc. about the topics shown below. They are designed to be my "go-to" place for teaching myself the given subject.
Analytics	Computer Science	Product Development	*UX / UI Design*

UX / UI Design

These are my notes on UX (user experience) Research and Design courses, articles, books, and other resources related to UX. It is also a repository for research on Product Design and Development, primarily focused on understanding the various product frameworks of building great products. Here are the main areas of this repo:

Main Table of Contents

Analytics Notes

University of Michigan MicroMasters courses

Courses are based on the EdX Micro Masters program User Experience (UX) Research and Design by the University of Michigan. These are the courses I plan to complete:

#	Course	Materials	Complete Date
1	Introduction to User Experience	My Notes Course Documents	Oct 16, 2018
2	Understanding User Needs	My Notes Course Documents	Oct 24, 2018
3	Principles of Designing for Humans	My Notes Course Documents	Oct 19, 2018
4	Evaluating Designs with Users
5	UX Design: From Concept to Wireframe	My Notes Course Documents	Oct 26, 2018
6	UX Design: From Wireframe to Prototype	My Notes Course Documents
7	UX Research Surveys
8	UX Research at Scale: Analytics and Online Experiments
9	UX (User Experience) Capstone

back to top

Follow-up Work To Do

Introduction to User Experience
- Write down the four components of UX and get the main questions from the slide deck as to what each is trying to solve/account for. Why? I think this will give me a good foundation or frame for everything that UX is. Even if it's primitive, this can be the best substitute for actual "first principles" in UX.
- Write a rubric / cheat sheet for the entire user-testing process from choosing the methodology, writing up the test (i.e. task-writing), to the debrief. Why? This will give me a basic skeleton for which ALL my testing can be understood and placed. It'll allow me to understand where these methodologies fit in and the purpose of each phase of the process.
- Write a rubric / cheat sheet for wording a task (see these lecture notes). Why? I will need to perform user-tests and having this is a foundation will make all tests better.
- Write a rubric / cheat sheet for a debrief. Why? The lecture on the debrief has some great little tips and suggestions that I just need to get on paper. Just take the best ones, organize them in a way that makes sense, and move on.
Principles of Designing for Humans
- Write a more-thorough breakdown of the Heuristics for Design with examples of each. Why? In addition to increasing my own understanding, this could be easily passed on and used as a common set of guideliness that everyone can use to understand a web app or project. These heuristics were designed for the layman to get up-and-running relatively quickly.
- Write a brief summary of the Gestalt Principles based on my notes and the articles below. Why? These principles appear to be foundational knowledge about how humans perceive things that I could learn once and it would be relevant essentially forever.
  - https://www.usertesting.com/blog/gestalt-principles/
  - https://uxplanet.org/gestalt-theory-for-ux-design-principle-of-proximity-e56b136d52d1
Understanding User Needs
- Create a checklist / cheatsheet on conducting a good interview (pre-interview prep, in-interview tips, and post-interview analysis). It doesn't have to be long but a good breakdown by each step. Do this after the task above the user-testing experience. It sounds like the task above from Intro to User Experience is similar. Why?* I can use this as a general guide forever. I'd also like to have something for employees to keep as a guide to create some minimum standards.
UX Design: From Concept to Wireframe
- Create a Toolkit based on the four main parts of design. Describe each of the main parts and how to perform them effectively.

Udemy Courses

#	Course	Materials
1	DESIGN RULES	Notes
2	User Experience Design Fundamentals	Notes
3	UX & Web Design Master Course: Strategy, Design, Development	Notes

Product Design & Development

Product Table of Contents

back to top

Amazon: Working Backwards

Sources:
- Quora: What is Amazon's approach to product development and product management?
- Design Telepathy: Your Complete Guide to Setting Your Product Vision & Value Proposition
- Wener Vogels (Amazon CTO): Working Backwards
"Work Backwards" is a method of product development that has you start with the customer first (or at least the "press release" and why a customer should care) and then work backwards to what you'd need to build it
My summary here is a combination of different sources around how to do this
All versions start with the "Press Release" announcing the product

Version #1

One version is just a press release
Here's a great example outline for a press release:
- Heading - Name the product in a way the reader (i.e. your target customers) will understand.
- Sub-Heading - Describe who the market for the product is and what benefit they get. One sentence only underneath the title.
- Summary - Give a summary of the product and the benefit. Assume the reader will not read anything else so make this paragraph good.
- Problem - Describe the problem your product solves.
- Solution - Describe how your product elegantly solves the problem.
- Quote from You - A quote from a spokesperson in your company.
- How to Get Started - Describe how easy it is to get started.
- Customer Quote - Provide a quote from a hypothetical customer that describes how they experienced the benefit.
- Closing and Call to Action - Wrap it up and give pointers where the reader should go next.
They recommend keeping your press release relatively short and not getting too technical; you want to keep it mainstream. People need to get excited about the product from reading the press release
After the product moves into development, the press release is the guiding light that should be used as inspiration to prevent scope drift or feature bloat / overbuilding of certain features.

Version #2

I haven't fully summarized this method. It requires a deeper understanding of the other three parts. I can revisit this later.
Design Telepathy uses a modified version of this with four main parts:
- #1. Press Release
- #2. FAQ Document
- #3. Map the Customer Experience
- #4. Create a User Manual
The Press Release has similar items as in Amazon's. They also recommend following HubSpot's template for writing a press release
The FAQ gives you the opportunity to get more granular on certain items not answered in the press release
Mapping the customer experience
- See this post: Improve Your Customer’s Experience With Experience Mapping
Creating a User Manual
This document is a template to help set the vision for a product.

back to top | Product Table of Contents

Basecamp: How We Structure Our Work and Teams at Basecamp

Source: How we structure our work and teams at Basecamp
Basecamp works in 6-week cycles with a one or two-week period without scheduled projects where people can roam independently, fix stuff, and pick up pet projects.
They have Big Batch and Small Batch projects
- Big Batch projects are big features or other items that will take up the full six weeks
- Small Batch projects are smaller things, tweaks and minor adjustments that could be a day to two weeks
Basecamp will typically take on 1 or 2 Big Batch projects and/or 4 to 8 Small Batch projects in a six-week cycle
They think that most things can be hammered down to just six weeks - if you think it's "too big", work hard to narrow it down to the best 6-week version possible
- You aren't looking for what it can be, but what does it need to be
Every Big Batch project is assigned a team (they have multiple teams so each team would get a Big Batch project)
Small Batch projects are typically all done by one team
They use teams of three and teams are assembled ad-hoc based on what they want to work on
They don't have Product Managers - designers on the team lead the project but work very closely with the programmers
They don't track time - the scope might change as the project progresses but the deadline doesn't move
New product ideas are pitched via a document sent around to the team. The pitch document (example pitch) format seems pretty open-ended. It has a description of the project, the problem it's fixing, some illustrations showing the problem and solution, etc.
They use pitch documents instead of in-person pitches
- The pitch-person is effectively completely uninterrupted; they can pitch their idea however they want, exactly as they want
- Writing forces you to think things out more
- People can read / digest the pitch on their own time
- They post it to Basecamp as a message and then people can post messages and follow-up questions
The CEO, CTO and Chief Strategist pick the projects that they work on but everything is open to debate.
Their decisions depend on a number of different variables
Once they define the work that will be completed and everything is grouped into Big Batch and Small Batch projects, they have a cycle announcement (example here)

back to top | Product Table of Contents

Design Telepathy's Product Design Process

Source: The Complete Guide to the UX Product Design Process
Here are the main sections:
- Defining Product Vision
- Research and Validation
- Understanding Design Systems
- Rapid Ideation
- Understanding Users and Relationships
- Preparing to Design
- Design and Build
Defining Product Vision
- The Future Press Release
- The Manifesto
- Your Complete Guide to Setting Your Product Vision & Value Proposition
  - great summary of what Design Telepathy thinks on setting the vision for a product / project and understanding your value proposition
  - It is pretty much Amazon's method plus mapping the customer experience and creating a user manual
- Design the Beginning
  - great article, worth reading again; summary below
- The North Star
- Business Model Canvas
  - I've seen something similar (Lean Canvas) and it looks like it would work better as a completely new enterprise as opposed to just a single product. There are some good questions that would naturally come up if you force yourself to complete it quickly; e.g. in 20 minutes.
- Writing Product Vision
  - the focus of this article is making sure that you have clearly articulated the vision for your product / project
  - Here is a good list of questions to answer:
    - Who is going to buy the product? Who is the target customer?
    - Which customer needs will the product address?
    - Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product?
    - How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points?
    - What is the target timeframe and budget to develop and launch the product?
  - A Good Product Vision Is....
    - Clear and stable - the product vision should allow us to see the future product
    - Broad and Engaging - describe a broad and engaging goal that guides development but also allows for creativity
    - Short and Sweet - brief and concise
  - Does your product vision pass the elevator test?
    - can you explain your product in the time it takes to ride up in an elevator?
- Objective-Based Design
  - I haven't had a chance to really dig in - the page didn't load properly for some reason. MUST REVISIT
Research and Validation
- Research Plan
  - The UX Research Plan That Stakeholders Love
    - great overview of what a research plan is and why you should do one.
    - Both "not doing research" and "doing a ton of research" are unattractive options: this is the one-pager that answers it all (kinda)
    - it's the "start" of a research project to set the right expectations, boil down what you know and what you want to learn, and secure buy-in for the UX research by making it a team effort.
    - Title. The title should combine the thing you’re studying and the methodology; for example, “Monster.com field study” or “XYZ Phone data-entry usability test.” Sometimes mentioning the target audience of the study is also appropriate; for example, “Whitehouse.com news page interviews with senior citizens.”
    - Author and stakeholders. State your full name, title and email address on one line. After you get the stakeholders’ buy-in for the plan, add their details as well — the research belongs to everyone now.
    - Date. Update it whenever the plan is updated.
    - Background. Describe what led to this study. Discuss the recent history of the project. Be brief, no more than five lines.
    - Goals. Briefly state the high-level reason (or reasons) for conducting this study. Try to phrase it in one sentence. If that wouldn’t make sense, create a numbered list of very short goal statements. If you have more than three to four goals, you are either aiming too high (meaning you have too many goals) or repeating yourself.
    - Research questions. These are the specifics, the core of your plan. Provide a numbered list of questions that you plan to answer during the study. It is extremely important that your stakeholders understand that you will not necessarily be asking the study participants these questions. As a rule of thumb, have no more than seven to ten questions, preferably around five. Later on, you will construct your study script to answer these questions. An effective way to think about research questions is to imagine that they are the headings in the study’s summary.
    - Methodology. In an academic environment, this section has one primary goal: to provide as many details as other researchers need in order to repeat the exact same study. In practice, the goal of the methodology section is to briefly inform the stakeholders of what will happen, for how long and where.
    - Participants. Provide a list of the primary characteristics of the people you will be recruiting to participate in the study. Have a good reason for each and every characteristic. If you have two participant groups, describe both groups’ characteristics in lists or in a table. Append a draft form that you’ll use to screen participants.
    - Schedule. Inform stakeholders of at least three important dates: when recruiting starts, when the study will take place, and when they can expect results. Large research projects require more scheduling details. For example, if the study involves travel to another city or country, more dates might be required for on-site preparation and meetings or for analysis workshops.
    - Script placeholder. When a full study script is ready, it will appear under this title. Until then, all you need is a heading with a “TBD” indication.
- Asking the Right Questions
- Synthesizing the Data
- User Testing
- Heuristic Evaluations
  - this is designed to find the pure functionality and usability issues in the product
  - user testing looks for behavioral patterns
- Resources
  - 10 Usability Heuristics for User Interface Design
    - I saw these listed from my UMI course. Understanding these on a deeper level
Understanding Design Systems
- Platform Audit
- Ecosystem Mapping
- Competitive and Comparative Audits
- Resources
  - The step-by-step guide to an effective UX audit
Rapid Ideation
- Design Sprints
  - How to assemble your design sprint team
    - great info on getting people into the mood to do a Sprint. Not everyone will see the value; not everyone will buy in. Some interesting info in this about getting people to try it.
Understanding Users and Relationships
- Proto-Personas
- Job Stories
- Object-Oriented UX
Preparing to Design
- Whiteboard flows
- Component Audit
- Resources:
Design and Build
- Design Exploration
- Prototyping

back to top | Product Table of Contents

Facebook: The Three Questions Facebook Uses To Guide Their Product Development

Sources:
- The Three Questions Facebook Uses To Guide Their Product Development
The three questions:
- Question #1: What people problem are we trying to solve?
- Question #2: How do we know this is a real problem?
- Question #3: How will we know if we've solved this problem?
Question #1: What people problem are we trying to solve?
- Write the problem statement in a simple, straightforward way - no technical jargon
- Do not have a solution in mind when writing it - just write what the problem is
- The problem statement shouldn't be about the company winning
- Touch on the why of the problem
- functional, emotional or social

Facebook example — “I want to talk about an interest with other people who are also interested, but I don’t know where to find these people”

Question #2: How do we know this is a real problem?
- what evidence is there, qualitative or quantitative, that this is a problem worth solving?
Question #3: How will we know if we've solved this problem?
- set measurable goals, metrics, and milestones before you launch

back to top | Product Table of Contents

Facebook: Design the Beginning

Source: Design the Beginning
great article, worth reading again
when designing a product, it's easy to start at the middle where the main character already knows about your product.
we always want to just assume that people will see straight through to the potential of this new product/feature/etc. and just "get it"

"Nobody cares about the thing you’ve designed, unless you can get them past the beginning."

The "beginning" is how you introduce something new to a person and how you will get them to understand its value and actually use it every day/week/whatever
Here are some of the questions you should answer BEFORE you start building it:
- Where and how will people first hear about your product or feature?
- What should people understand about your product at a glance, and is that compelling enough to convince them to go through the trouble of trying it out?
- What should people’s first-time experience through your product be, and how do you plan to demonstrate to them its value within the first minute?
- How will you build out the social graph, content inventory, marketplace, etc. if the success of your product is dependent on those things?
- What would compel somebody to come back and use your product a second or third time?
she recommends designing the marketing page (app store submission, website, etc.) and the new user experience (the step-by-step flow for first-time user) first.
these designs don't have to be high-fidelity but they should capture what your product is and can deliver to users
By designing the beginning, you can make sure that:
- your value proposition is clear
- your messaging makes sense and, again, is clear
- the path from sign-up to active user

back to top | Product Table of Contents

Michael Siebel: Product Development Cycle Fundamentals

Source: Product Development Cycle Fundamentals
Some of their (Justin.tv) major problems with product development included:
- Unfocused product meetings that were not written down
- Products were poorly spec'd out or not spec'd out at all
- Too focused on fully-formed products as opposed to MVPs
- Rarely spec'd analytics for new products and thus had no idea how they were performing post-launch
- Development cycles ran months-long
  - they were sick of the new feature by the time it launched so they didn't iterate
- Product roadmap was too long so team members weren't excited to brainstorm new products
- Product decisions were made exclusively by founders in a non-transparent process
Just using the opposite of each of these (before reading the rest of the post), what should a good product cycle do or have?
- Focused product meetings (they have an agenda) with the resulting meeting notes written down and distributed
- Products are carefully spec'd out and understood by everyone working on it
- Build MVPs and then iterate - don't build the whole thing at once
- Identify important metrics related to the product and track them post-launch
- Shorten your product roadmap or reduce how attached your are to it; be responsive to successes in your releases
- Make product decisions in a more open, transparent way
This post is what Michael Siebel used at Socialcam; it's broken down into a couple concrete tips/suggestions
Tip #1: Define Your Development Cycle Length
- development cycle is dictated by your product: iOS apps may need two weeks, web apps maybe a week, hardware could be longer
- The key is to make the cycle short enough so that the team can stay excited and still feel like they can brainstorm new ideas
Tip #2: Determine Your Goal(s) and Identify the Product Lead
- They had one team meeting and it was their product meeting which happened at the first day of the dev cycle
- Socialcam had three main objectives that every product meeting was focused around:
  - increasing content creation
  - increasing new users
  - increasing retention
  - CM Note: those three objectives were decided BEFORE this meeting. Understanding what your team is trying to achieve and having some core objectives is important. Other companies talk about a "North Star" metric that guides all product discussions.
- They'd pick a goal and that would be the focus for the next two weeks
- He isn't explicit about whether the product lead changes or whether it's the same every time but this quote below is good. He goes into more of some of the responsibilities of the Product Lead and some of the behaviors of that person

As the product person on the team my role was to protect and improve the dev cycle and moderate the product meetings to ensure all team members felt comfortable contributing. Oftentimes just getting the opportunity to voice your idea and having it written on the board - even if it isn’t built - massively increases buy-in of the process.

Tip #3: Organized and Inclusive Brainstorm
- They would write ideas down on the whiteboard in one of the following categories:
  - new features / feature iterations
  - maintenance
  - A/B tests
- Everyone was expected to contribute
- No debates or putting down people's ideas
  - Everyone felt free to contribute without fear of judgment
- The product lead is responsible for creating and maintaining this kind of environment.
- Each brainstormed item would be graded by the engineer in the meeting as the following:
  - Easy (several can be done in a day)
  - Medium (half a day for one person)
  - Hard (most of the dev cycle)
- They didn't allow items to last longer than the dev cycle - if it was, it would get broken down into smaller chunks
Tip #4: Building a Consensus
- Once the ideas are written out, they'd pick what they would work on through consensus
- Start with the hard ideas as they could typically only do one and then look at medium and then easy
- As a reminder, each of these ideas has the following:
  - Idea - what the idea
  - Objective - what objective is it satisfying
  - Effort Required - how much time would it take to build (i.e. easy, medium, hard)
- Build a consensus around the work that the team wants to complete
Tip #5: Clear Spec and Clear Measurements of Success
- Spec out of the items on the list in detail and assign each item to a team member(s)
- Spec out the metrics that we need to track to measure effectiveness
- Separate out the need-to-have from the nice-to-have items
- Lastly, they'd take a picture of the whiteboard and erase the board
- They didn't have a product roadmap outside of these product meetings. Every two weeks, they'd start from scratch with the new goal, new analytics data from their last two weeks and in-person user testing that they tried to do at least once a month
- I liked this quote on analytics:

We would never release a feature without releasing the analytics for that feature and understanding what specific measurable result we wanted to create.

Tip #6: Working During the Development Cycle
- Each person has different responsibilities but those responsibilities for the length of the dev cycle were scoped out in the product meeting with very clear specs
- During the last three days of the dev cycle (of a two-week cycle), they would test
- They had an Excel sheet of manual tests for all of the basic functionality
- With each new cycle, they would add tests to that list (for any new features that were build) and then each item on the list would be tested twice
- CM: this sounds like a lot of testing. It sounds like the burden of testing would grow with each cycle if EVERY item was tested each cycle. Maybe just the new features are tested? I could see new features breaking older items but a manual test of each item feels excessive - maybe not.
Summary
- #1: Define Your Development Cycle
  - depends on your product (and team) - find what works for you
  - Remember: the key is to keep it short enough the team is still excited and feels like it can brainstorm new ideas
- #2: Determine Your Goals and Identify Product Lead
  - Pick a goal / objective you'd like to achieve in this development cycle (it should probably come from a list of long-term goals or "North Star" that the team has already decided upon)
  - Pick your Product Lead
- #3: Organized and Inclusive Brainstorm
  - Write down ideas from everyone without debate or critiquing
  - Engineers then classify each idea as easy, medium, or hard
  - At this point, each idea has three main items:
    - the Idea
    - Objective it's satisfying
    - Effort Required / Difficulty in completion
- #4: Building a Consensus
  - By consensus, the team picks what they will work on
- #5: Clear Spec and Clear Measurements of Success
  - Spec out the items to be completed and who was responsible for it
  - Spec out the metrics to track to measure it
  - Take a picture of the whiteboard, erase it, and then get to work
- #6: Working During the Development Cycle
  - People should know what their responsibilities are from #5 - their focus should be on that
  - Last few days of cycle, test items to make sure the features work

back to top | Product Table of Contents

Links to Explore

Building a Product

Product Frameworks
- This looks like the holy grail of all product framework pages. There are a ton of different frameworks here worth exploring.
GV Design Sprints
- The Ultimate (and Free) Tool for Facilitating Design Sprints

Design Language Systems

Learning Design

Product Design and Development

Amazon
- Working Backwards
  - Quora: What is Amazon's approach to product development and product management?
    - the first answer is okay but the answer on "working backwards" is great and is explained in detail in the Quora link and in these articles:
      - Your Complete Guide to Setting Your Product Vision & Value Proposition
      - Working Backwards
- Product Manager Interview
  - Interview with Amazon Product Manager
  - Another Amazon Product Manager Interview
CIRCLES Method
- Intro to the CIRCLES Method™ Product Design Framework
Design Telepathy
- The Complete Guide to the UX Product Design Process
Facebook
- Quora: What is Facebook's product management process?
- The Three Questions Facebook Uses To Guide Their Product Development
Google Sprint
- Quora: What is Google's approach to product development?
Michael Siebel
- Product Development Cycle Fundamentals

OKR's

Links:

Set Goals with OKR's
- How Google sets goals: OKRs
  - good YouTube video that outlines how Google's process but also has some good
  - At FeedBurner, Dick Costolo would say "get all the feeds" - everything employees did had that in mind
  - CEO sets the company's objectives
  - Employees' OKR's were never really
  - Keys to OKRs
    - OKR's are:
      - set quarterly and annually
      - measurable
      - set at personal, team, and company levels
      - publicly available to the entire company
      - graded each quarter
  - Elements of an OKR
    - The Objective is:
      - ambitious
      - feels a tad uncomfortable
    - The Key Results:
      - clearly make the objective achievable
      - are quantifiable
      - lead to objective grading
  - Personal / Team / Company
    - Personal OKRs define what the person is working on
    - Team OKRs define priorities for the team, not just a collection of all individual OKRs
    - Company OKRs are big picture, top-level focus for the entire company
  - Sample Personal OKRs
    - Objective: Accelerate Blogger Revenue Growth
    - Key Results:
      - launch "monetize" to allow one-click ad revenue
      - Implement AdSense Host Channel Placement targting RPM's by xx%
      - Launch 3 revenue-specific experiments to learn what drives revenue growth
      - Finalize PRD (Product Requirements Doc) for Blogger Ad Network, secure eng allocation to build in Q1
    - Objective: Improve Blogger's Reputation
The Guide to Company Objectives and Key Results (OKRs)
How to Write Objective and Key results - Practical Examples
Beginner's Guide to OKR
Steps to successfully set up goals with OKR
The Art of the OKR
https://medium.com/startup-tools/okrs-5afdc298bc28
OKR Examples:
- http://okrexamples.co/company-okr-examples
- https://www.atiim.com/okr-goals-examples/
Personal OKR's
- Personal OKR's

User Research

Questions

What is the difference between Product Design vs. UX Design?

Product Design vs UX Design: what’s the difference?

Quote: "Design will not be just about users. It will also be about the business. As Product Designers, we must drive product solutions that service the goals of both the users and the company."

UX design vs. product design: what is the difference?

both use the "Design Thinking Process"

Product Designer VS UX designer：Which One You Prefer to Be?

The Product Designer handles the overall function and working process of the product. They are the guardians of user needs.
UX Designers are responsible for the function of the user interface and user-friendly experience.

The Evolution of UI/UX Designers Into Product Designers

What is the difference between a Product Manager vs. UX Designer?

Product Manager and UX Designer – What’s the Difference?

coolinmc6/design-ux-ui

ErrorLooks like something went wrong!

About

Topics

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Error
Looks like something went wrong!

Packages