VNUHCM
Bài trước Bài kế tiếp
  • Nội dung học
  • Trợ giúp
    Bạn có thắc mắc khi đang học?
    Hướng dẫn cách học Những câu hỏi thường gặp Email cho giáo vụ
    • Tiếng Việt
    • English
    • Thông tin Thành viên
    • Khoá học đăng ký
    • Đăng xuất
  • Cohota
  • HƯỚNG DẪN HỌC TẬP

  • Xem chi tiết >>
    Bạn đã hoàn thành 0% khoá học
  • HƯỚNG DẪN SINH VIÊN ĐĂNG NHẬP HỆ THỐNG
    • Hướng dẫn đăng nhập
    • Hướng dẫn vào khóa học
  • Introduction
    • Welcome
  • Unit 1: Values
    • Introduction - Unit 1: Values
    • Get Started With Values
    • Play with Values
    • Playground Basics
    • Naming and Identifiers
    • Simulation
    • Strings
    • Constants and Variables
    • Word Games
    • Build a PhotoFrame App
    • Design for People
  • Episode 1: The TV Club
    • Introduction - Episode 1: The TV Club
    • Searching for Content
    • Sharing Personal Information
    • Ordering Online
    • Reflection: Episode 1
  • Unit 2: Algorithms
    • Introduction - Unit 2: Algorithms
    • Get Started with Algorithms
    • Play with Programs
    • Functions
    • Types
    • Parameters and Results
    • Making Decisions
    • BoogieBot
    • Data Visualization
    • Build a QuestionBot App
    • Design an Experience
  • Episode 2: The Viewing Party
    • Introduction - Episode 2: The Viewing Party
    • Accessing the Show
    • Streaming on the Network
    • Reflection: Episode 2
  • Unit 3: Organizing Data
    • Introduction - Unit 3: Organizing Data
    • Get Started with Organizing Data
    • Play with Complex Data
    • Instances, Methods, and Properties
    • Arrays and Loops
    • Structures
    • Enums and Switch
    • Testing Code
    • Processing Data
    • Pixel Art
    • Password Security
    • Visualization Revisited
    • Build a BouncyBall App
    • Design a Prototype
  • Episode 3: Sharing Photos
    • Introduction - Episode 3: Sharing Photos
    • Capturing Images
    • Posting on Social Media
    • Reflection: Episode 3
  • Unit 4: Building Apps
    • Introduction - Unit 4: Building Apps
    • Get Started with App Development
    • Play with App Components
    • Color Picker
    • ChatBot
    • Rock, Paper, Scissors
    • MemeMaker
    • Build an ElementQuiz App
    • Design for Impact
  • Appendix
    • Episode Technical Concepts
    • Glossary
Tổng quan điểm khóa học
Đánh giá

Tiến độ
Tên tiêu chí Trọng số (%) Điểm Tiến độ (%)
Unit 2: Algorithms

Design an Experience

Unit 2: Algorithms|Design

Analyze Technology

In Unit 1, you considered the features that users would be looking for in your app design. The next stage of developing your app is to consider how users will experience your app. Think about a time you’ve used a search engine. Your experience included not only your interaction with the search engine interface, but also the usefulness of the search results. Design isn’t just about how a product looks and feels; it’s also about how it works.

How your app works will depend on the data you’re collecting and the way your program works with that data. Bias—often unintentional and unconscious—can find its way into both aspects of the app.

Consider car safety ratings. These ratings are meant to help shoppers make informed purchase decisions by measuring how safe different cars might be in an accident. But as it turns out, seat belt and crash testing relies heavily on crash dummies modeled on the average male body—which means that the data behind car safety ratings is strongly biased towards the safety of “typical” male drivers and that safety innovations are more effective for “typical” male drivers.

Since the data set that informs car safety ratings is biased, the user experience of being kept safe in a car crash—or not—is also biased. These biases may reflect unconscious assumptions about who drives cars, but ultimately they can have a negative impact on the experiences of anyone who doesn’t match the physical characteristics of a “typical” male.

The algorithm used by a program can also be biased. Imagine a financial institution that adopts a new program for determining the financial risk of potential customers. The program is intended to benefit the bank and its investors by reducing the number of bad loans. The algorithm factors in zip code as a variable, and assigns higher risk to neighborhoods with higher populations of a certain race or gender. While this approach may reduce the risk to the bank and improve outcomes for investors, it may also prevent qualified individuals from accessing loans simply because they live in a certain zip code.

Development of algorithms that include bias—whether or not it’s intentional—raises ethical concerns for many groups in society. As a way of combatting existing human biases, programmers should endeavor to check for—and reduce—bias in the data sets and algorithms they use.

Analyze this:

Think about how bias can affect your experience of an app.

Watch this video from WWDC to learn how Apple designs the overall experience with apps that rely on machine learning. As you watch the video, consider how the developers at Apple have worked to ensure they are fair and inclusive in their data collection and algorithm design.

Think Like a Developer

A crucial step in designing successful computing innovations is understanding the people who will use the innovation. Excellent developers take deep care to understand their users. They may research user behavior or solicit input from actual users—collecting data through surveys, user testing, interviews, or direct observations.

And since different people may have different goals or may approach an innovation differently, it’s important to gather data from a wide range of user audiences. When your design incorporates diverse perspectives, it will improve the experience for all users.

image of diverse people going about their daily lives. Something similar to the image below

When you understand the people, in all their diversity, who will use a computing innovation, you can move on to focusing the innovation’s purpose. Without a clearly defined purpose, your app is unlikely to offer a great user experience. The more deeply you understand the app’s core mission, and the needs and goals of the people who’ll use it, the easier it will be to create and refine your work. When users have expectations that remain unmet, they’ll be disappointed or frustrated. But when their expectations are exceeded, they’ll be surprised and delighted.

Designing a user experience goes beyond understanding its core purpose and its users. Consider the data your app works with and the common tasks users will perform. Are there types of data that are more important than others? How easy is it to see your app’s most important data without hunting for it? How easy and obvious is it to perform the core tasks? What kinds of feedback do users need in order to accomplish their goals? A good app designer has answered all these questions (and more). And as a result, they can prioritize their design elements to build a focused app that’s a delight to use.

A final design consideration is whether you can—or should—use data about users (analytics) to enhance their experience. Once an app is out in the world, the data it collects from its users can provide important insights into their behaviors, goals, and preferences. You might, for example, want to track which screens are visited most often or which buttons are ignored. Or you might want to collect data that users input into the app. Apple provides some built-in analytics for app developers as well.

At the same time, you’ll need to consider what kinds of PII the app might be collecting.

As a company, Apple has strong opinions about data collection, transparency and control, and security. Apple has four key principles around designing for user privacy:

  1. Request consent when your app needs personal data.
  2. Be transparent about how personal data will be used.
  3. Give the user control over their personal data and protect the personal data you collect.
  4. Use the minimum amount of personal data required.

Consider this:

Reflect on your QuestionBot app.

Work through the prompts below to improve users’ experience of the app:

  • What are the typical goals a user may have?
  • What kinds of data are you displaying? What kinds of data are you collecting?
  • What do you know about the kinds of input your users can provide? Is it open feedback, can you limit options, or can you calibrate your app to better understand the user?
  • What goals might users have when using the app, and are there limitations that impede the ability of your app to meet their goals?
  • What kind of feedback can you provide to a user to improve the data you receive and their overall experience? How can you guide them through the input process?
  • How can you correct mistaken input? Can you infer what users mean even if they provide it in the wrong way, such as entering “one” instead of a required integer, “1”? If users are giving incorrect input, can you let them know what they need to provide?
  • Imagine how different kinds of people could be impacted by elements of the design and describe their experiences. For example, if there is an error, the app could simply display an error message, or it could provide haptic feedback such as a vibration for people with low vision.

Try this:

For the app you’re designing, think about the data it works with.

Identify the most important data.

Think about what users need to do, and how they’ll produce and consume your app’s data. Which essential tasks are the most critical to make easy and smooth? (A good, focused app should only have a handful of essential tasks.) In what order should users perform actions to accomplish the essential tasks?

Document the tasks you identified, along with the sequence of actions the user performs to accomplish each one. Indicate where you could provide feedback to improve their experience of the app. Also indicate where and how you might collect data that would help you understand them better.

Plan and Build

Now it’s time to think about how your app user interface and user experience will come together.

Plan this:

Sketch ideas for screens.

First, look back at your essential tasks. Do they suggest a set of screens for your app?

Next, you need to consider how your main screens will look. Refer back to your design mood board for inspiration, and sketch a few screens. With your users in mind, make design notes as you go.

Here’s an example of the initial ideas for the Go Green app. example of Go Green screens with notes

The next step is to show how a user will move through the screens—a storyboard. You can create a storyboard by organizing the screens in a flowchart and indicating the graphic elements that enable users to make choices within the app.

Here’s another example from the Go Green app:

flowchart showing simple plan for Go Green app

Build this:

Create a user experience flowchart.

To create a flowchart like the one above, take photos or screenshots of your screens and add them to Keynote. The flowchart should show how a user can move through your app based on the choices they make.

Look again at your list of essential tasks. How will the user navigate between your app screens to accomplish each task? Have you made them easy to accomplish?

Annotate your storyboard to explain key features of the app, and highlight the accessibility features you’ve incorporated.

Now look at some similar apps. How does their user experience differ to yours? Are there opportunities you’ve missed? Consider the app from the perspective of different users. How does it accommodate diversity? Are there features you could add to your app?

Apple provides resources to support developers to build accessible apps. By adding support for accessibility, developers can accommodate users with low vision, limited motor skills, and other limitations. Check out some of these Apple Developer resources.

Review and Iterate

Simplification is a key idea in the app design process. While it’s fun to design lots of cool features for your app, remember that purpose and focus are much more important. If you’re very clear about purpose, you can simplify your design so your app fits seamlessly into the flow of the user’s activity. Use this review cycle to learn what your users might want to do with your app and to consider how easily they can do those things.

Review this:

Share your storyboard with your peers or mentors.

As they explore your app design, encourage them to ask you How? Why? and What if? questions. You can record their responses or annotate your storyboard with their queries and ideas.

With a partner, take turns examining each other’s designs through the lens of someone who has a disability. (You can consider four broad categories: vision; hearing; physical and motor; and learning and literacy.)

Each of you should adopt a specific persona and explain your requirements when using an app. Then work through the app and give feedback from that person’s point of view. Together, identify ways you could improve the app to make it more inclusive.

After building and reviewing your app storyboard, you may discover major issues with your app design or even with the basic idea behind your app. That’s OK—and not entirely unexpected. App design is an iterative process, and identifying problems and issues can be seen as an opportunity rather than a setback. If you need to, return to the brainstorming phase and use your new insights to revise your app idea. Great apps are the product of extensive ideation, exploration, testing, and revision.

Other Considerations

While every development process involves iterating on designs and revisiting the user experience in response to testing and feedback, the iterative development process takes many forms. For some, it’s linear: a methodical and deliberate approach based on research and testing. Others might use a more exploratory approach, relying partly on intuition, prototyping many different ideas to see which ones work best.

The iterative development process might work differently for a solo developer than for a team effort. Commercial-grade apps often involve many teams working together. Think about how a large project could be broken into smaller projects and how multiple design processes might intersect. Perhaps some teams could focus on specific features, like accessibility and artwork, while others focus on technical solutions.

Consider the dynamics of a large team project. How might smaller project teams know when it’s important to come together and when to work separately? Which teams might choose a deliberate, linear approach versus an exploratory approach? How would they manage and reconcile their different styles of iterative development? Can you think of any team roles or responsibilities that would help minimize bias and harm in the development and design processes?

Báo lỗi