Skip to content
/ design-ux-ui Public

UX (user experience) Design and Research. An aggregation of notes and projects from various online courses.

32 stars 12 forks Branches Tags Activity
Star
Notifications You must be signed in to change notification settings

coolinmc6/design-ux-ui

BranchesTags

Repository files navigation

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
  • 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 Complete Date
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

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
  • 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
  • Understanding Design Systems
  • 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:
    • 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

Design Language Systems

Learning Design

Product Design and Development

OKR's

Links:

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"

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

Design Thinking 101

Customer Experience Process

General Product Design Process

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

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

About

UX (user experience) Design and Research. An aggregation of notes and projects from various online courses.

Topics

ui-design product-management ux-design ux-ui ux-research

Resources

Readme
Activity

Stars

32 stars

Watchers

3 watching

Forks

12 forks
Report repository

Releases

No releases published

Packages

No packages published