├── .gitattributes ├── README.md ├── UMI-Intro-to-User-Experience ├── Course-Documents │ ├── Interview-Matt-Martin.txt │ ├── L01-What-Is-User-Experience.pdf │ ├── L02-The-UX-Process.pdf │ ├── L03-Components-of-UX.pdf │ ├── L04-Basic-Methods-of-UX-Research.pdf │ ├── L05-User-Testing-Part-01.pdf │ ├── L06-User-Testing-Part-02.pdf │ ├── L07-User-Testing-Part-03.pdf │ ├── L08-UX-Design-Overview.pdf │ ├── L09-Prototypes.pdf │ ├── L10-Sketching.pdf │ ├── L11-A-Brief-Incomplete-History-of-UX.pdf │ └── L12-Course-Summary.pdf └── Notes.md ├── UMI-Principles-of-Designing-for-Humans ├── Course-Documents │ ├── L01-Visual-Perception-Part-1.pdf │ ├── L02-Visual-Perception-Part-2.pdf │ ├── L03-Memory-Part-1.pdf │ ├── L04-Memory-Part-2.pdf │ ├── L05-Seven-Stages-of-Action.pdf │ ├── L06-Gulfs-of-Execution-and-Evaluation.pdf │ ├── L07-Design-Principles.pdf │ ├── L08-Heuristics-for-Design.pdf │ ├── L09-Heuristic1-Visibility-of-System-Status.pdf │ ├── L10-Heuristic2-Match-Between-System-and-Real-World.pdf │ ├── L11-Heuristic3-User-Control-and-Freedom.pdf │ ├── L12-Heuristic4-Consistency-and-Standards.pdf │ ├── L13-Heuristic5-Error-Prevention.pdf │ ├── L14-Heuristic6-Recognition-Over-Recall.pdf │ ├── L15-Heuristic7-Flexibility-and-Efficiency-of-Use.pdf │ ├── L16-Heuristic8-Aesthetic-and-Minimalist-Design.pdf │ ├── L17-Heuristic9-Error-Recovery.pdf │ ├── L18-Heuristic10-Help-and-Documentation.pdf │ ├── L19-Heuristic-Evaluation.pdf │ └── L20-Course-Wrap-up.pdf └── Notes.md ├── UMI-UX-Design-From-Concept-to-Wireframe ├── Course-Documents │ ├── L01-What-is-Design.pdf │ ├── L02-Design-Process-An-Overview.pdf │ ├── L03-Framing-Design-Problems.pdf │ ├── L04-Formative-Research.pdf │ ├── L05-Introduction-to-Ideation.pdf │ ├── L06-Sketching.pdf │ ├── L07-Brainstorming.pdf │ ├── L08-Personas.pdf │ ├── L09-Scenarios.pdf │ ├── L10-Storyboards.pdf │ ├── L11-Design-Rationale.pdf │ ├── design-customer-experience-process.png │ ├── design-in-nutshell.png │ ├── design-thinking-101.png │ ├── design-thinking-process.jpeg │ ├── general-product-design-process.png │ └── sketching-vs-prototype.png └── Notes.md ├── UMI-UX-Design-From-Wireframe-to-Prototype ├── Course-Documents │ ├── L01-Course-Introduction.pdf │ ├── L02-Elements-of-User-Interaction-Data-Input.pdf │ ├── L03-Elements-of-User-Interaction-Output-State-Mode.pdf │ ├── L04-Introduction-to-Prototyping.pdf │ └── L05-Wireframes.pdf └── Notes.md ├── UMI-Understanding-User-Needs ├── Course-Documents │ ├── L01-Introduction-to-User-Needs-Assessment.pdf │ ├── L02-Overview-of-Qualitative-Research.pdf │ ├── L03-User-Needs-Assessment-Mini-Project.pdf │ ├── L04-Semi-Structured-Interviews.pdf │ ├── L05-Components-of-an-Interview-Protocol.pdf │ ├── L06-Good-Practices-for-Interview-Protocols.pdf │ ├── L07-Tips-For-Interviewing.pdf │ ├── L08-Observing-Users.pdf │ ├── L09-Extracting-Data-From-Interview.pdf │ ├── L10-Analyzing-Qualitative-Data.pdf │ ├── L11-Affinity-Walls.pdf │ ├── L12-Variations-on-User-Needs-Assessments.pdf │ └── L13-Conclusion.pdf └── Notes.md ├── Udemy-DESIGN-RULES └── Notes.md ├── Udemy-UX-Design-Fundamentals └── Notes.md ├── Udemy-UX-Web-Design-Master-Course └── Notes.md ├── assets ├── CIRCLES-method-product-design-framework.png ├── How-To-Write-A-Good-PRD.pdf ├── IDF-Achievements-Templates.pdf ├── Product-Vision-Workshop-Template.pdf ├── UX-Laws-infographic.png ├── ask-right-questions.png ├── dschool_bootleg_deck_2018_final_sm.pdf ├── facebook-pm-interview-cheat-sheet.jpg ├── highlight-important-data.png ├── product-manager-cheat-sheet.jpg ├── the-basics-of-ux-design.pdf └── three-legged-stool.png └── cm-docs └── template.md /.gitattributes: -------------------------------------------------------------------------------- 1 | # Auto detect text files and perform LF normalization 2 | * text=auto 3 | -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/Interview-Matt-Martin.txt: -------------------------------------------------------------------------------- 1 | Hi, I'm here today with Matt Martin, experienced architect at Ithaka. 2 | And we're gonna talk about user experience and the user experience field, 3 | with a focus on user experience design, and 4 | what designers contribute to the field of user experience. 5 | So, welcome, and thank you very much for being here. 6 | >> Thank you. 7 | >> So, tell me a little bit about what you're doing at Ithaca right now. 8 | >> Okay. 9 | So, I work on a team with software engineers, quality insurance engineers, 10 | a product manager, and a visual designer, and then myself. 11 | And what I try to do is I setup enough strategy, enough design work 12 | collaboratively with my team, to kinda get that work ready for development. 13 | So, I would say I spent half of my days in meetings, and 14 | half of my days doing design, and it's very collaborative. 15 | So, there is gonna be some times where I'm heads down work doing some designs, or 16 | doing some research. 17 | But then there'll be a lot of times where I'm brainstorming strategy with 18 | my product manager, or working with a user 19 | researcher to make sure that we're gonna set up the right type of user testing. 20 | And then my visual designer, who I collaborate a lot with, is in New York. 21 | So, we'll sometimes do some screen sharing, 22 | where we'll collaborate on a design. 23 | Or I'll just start sketching on a whiteboard, and I'll take pictures of it, 24 | and send it to her. 25 | And say okay, I just created this really quickly. 26 | Can you bring back something to me? 27 | And then we'll kind of collaborate that way. 28 | So, it's like, we have these pods of teams that, like I said, are blinded. 29 | And then some other times, I'll meet with whole UX department. 30 | The other designers, to find out, hey, what are you working on? 31 | And how is it going to influence what I'm doing? 32 | Sometimes I'm doing parts of the site. 33 | Or some of our products that do touch each other. 34 | And sometimes, I'm kinda on my own. 35 | Or it's a product that's not touching other things. 36 | So. 37 | >> Could you give us an example of maybe a project that you've worked on, 38 | and try and take us through how it started, and how it progressed through 39 | the different stages until it became however it ended up? 40 | >> Okay. 41 | So, we needed to do a redesign of the strategy in research, arm of ethical. 42 | So, they had a website that was aging but 43 | not only that, their business model and some of the programs are changed. 44 | So, we needed to do a refresh on the website to kind represent 45 | that new program that they were trying to focus on, and also, 46 | to do a better job of having that website reflect their business objectives. 47 | So. >> Could you maybe just say real 48 | quick what the strategy and research? 49 | >> Yes. >> The strategy and research. 50 | Well, who are the users, and what are they trying to do with this website? 51 | >> So primarily, what the strategy and 52 | research arm does is they work with libraries and higher education, 53 | and they deal with the administrators and librarians to basically get 54 | technology and libraries kinda ready for the future. 55 | >> Okay. >> How does technology influence that? 56 | And one of their programs that they started to promote, and 57 | that started new just last year is called Educational Transformation, which is how 58 | about how is education being transformed, and how can institutions go along with it? 59 | So they do a lot of consulting. 60 | >> Okay. 61 | >> They write a lot of papers, case studies, reports, issue briefs. 62 | And librarians try to get all of that research, cuz they give it away for free. 63 | >> Okay. 64 | In the hopes to sell some of their products, they do survey, 65 | they do site consulting and stuff like that. 66 | >> I see. 67 | >> So, what was happening was is the website was, had a lot of information 68 | there, and have all reports, but wasn't as easy to go from one report to another, and 69 | there wasn't really a way for the products and the reports to kinda intermingle. 70 | >> Okay. >> And so, 71 | it was our goal to figure out, okay, where is the business going? 72 | How is the site working and not working? 73 | And how can we make it work better? 74 | So, what I did was is I interviewed all the directors, and 75 | all the program directors, and the marketing directing there at the S+R, 76 | was what it was called- >> Okay. 77 | >> Ithaka S+R. 78 | >> Okay. 79 | >> Strategy and research, and 80 | I did that with the user researcher, our product manager, and an engineer. 81 | >> Mm-hm. 82 | >> So, while we were doing that, we were taking notes. 83 | And trying to figure out, okay, so this is how they look at their business. 84 | This is how they look at their user. 85 | So, we had a pretty good idea of what to do next. 86 | And next was, let's find out what we're dealing with, and 87 | did the content inventory of the whole site. 88 | We started to look at the analytics of the site to find out how traffic was getting 89 | there, and what was happening, why they were there, and 90 | they where the users were leaving. 91 | >> Mm-hm. 92 | >> Next. 93 | I did a comparative analysis, so I'm looking at all the different 94 | competition that they have throughout the landscape. 95 | >> Mm-hm. >> Inside their industry and 96 | outside their industry, just to see how it happens, 97 | how the branding happens, how the interaction design works. 98 | So, what people are gonna expect when they go to the site. 99 | So that we're not doing anything that's too different, or something that we 100 | can make sure falls in people's expectations when visiting the site. 101 | So once we did all that, in kind of concurrently, 102 | we had the developers starting working on a framework. 103 | So, me and the designer can start thinking ahead, and 104 | we knew that we're gonna have to feed the developers the real full site. 105 | But in the meantime, we wanted to have them just develop a slice of the site. 106 | So, a working version of every single section, but 107 | it didn't go deep with just one kind of like layer. 108 | >> So this would be software, and you are thinking of just having the different 109 | components kinda of in place, so that as you're doing the design, you 110 | could actually have framework to sort of testing out and seeing how it will work. 111 | >> Exactly. 112 | That way there was a foundation there, we can see if things were working, 113 | and we could find out early on that hey, this really doesn't work. 114 | But what we did is, once we started developing, 115 | we could see that it could scale too. 116 | So, while the developers were doing that, I went back to the stakeholders and 117 | said okay, you have a lot of categories here. 118 | You don't have much consistency on topics in the way you organize your research. 119 | So, I set up a workshop to really work on their vocabulary in taxonomy, 120 | just the raw materials of the research. 121 | So that we could develop a good information architecture of the site and 122 | do positive search. 123 | That made sense not only to them, but to the people that they're reaching out to. 124 | >> Mm-hm. 125 | >> Once we did that taxonomy exercise, 126 | we didn't put it in the site until we did a card sorting task with actual users. 127 | >> Mm-hm. 128 | >> So, what that is we put it online, all these different topics and 129 | categories, and had actual librarians come to this program or 130 | site to organize how they saw those topics and categories. 131 | Once we had that data back, then we can tell developers okay, now we figured out 132 | how this is supposed to be chugged and categorize so they can start building it. 133 | In that way, it was scalable and we were able to make sure that 134 | throughout the the whole process, we're getting some input from our users. 135 | So, once we had that slice, 136 | we were able to start filling in the rest of the site. 137 | And we, one of the things, not only did we wanna get librarians and 138 | other visitors to download their reports, but we also wanted people to sign up so 139 | that they would get news of hey, the new report is coming out. 140 | So, we experimented with different placement of where that sign up would be, 141 | and once we found the best place for it. 142 | Based on a smaller set, then it's been released. 143 | Now we've gotten I think, they're, 144 | it's gone up at least 20% as far as the last time I checked. 145 | Because that was. 146 | >> The number of sign ups has gone up by 20% since the previous version. 147 | >> Exactly. 148 | Yep. So it has been a success, and 149 | it really shows just by moving something on a page can really have a huge affect on 150 | the design. 151 | And the sign up rate was amazing. 152 | >> Well let me ask you a couple more question about that. 153 | So, there were a lot of different activities happening at the same time. 154 | >> Yes. >> You had Software development happening. 155 | A number of different research activities. 156 | What kind of things were going on with trying to figure out. 157 | You know what the site was gonna look like, how things were gonna be laid out, 158 | what was connected to. 159 | What kind of things were you doing, 160 | in parallel to kind of work out the design of this Cybertough. 161 | >> So I'm trying to break down the navigation in it to two different. 162 | I guess categories, one was the persistent navigation which is what 163 | you usually see at the top of every page. 164 | It's the global navigation, the big buckets. 165 | But what I spent a lot of time on with the stakeholders, 166 | was the contextual navigation. 167 | How is each object related to one another? 168 | So an object could be an article, 169 | another object could be an event that they're hosting. 170 | And another object could be, 171 | the person that's either writing the paper, or putting on the event. 172 | So that way, I had all these modules that could be interrelated so 173 | that when you're on a page, and you're on an article, 174 | you know who wrote it, and if there's an event coming up. 175 | And they also can point to this article relates to this product that they had, 176 | or this kind of consulting practice that they do. 177 | So that way, no matter when you're on the site, 178 | you're always going to another related event or even another related article. 179 | So you're kinda, instead of just going there, grabbing a paper and leaving, 180 | I set it up so you could explore. 181 | So you don't have to go up to the main navigation as an escape hatch, or 182 | to do the exploration. 183 | It's more in context exploration if you will. 184 | So I spent a lot of time doing that, to make sure that people were staying on 185 | the site, and learning as much as they can and. 186 | Satisfying the user's needs of getting those papers. 187 | But also, trying to help the business objective of, 188 | hey let's get these people working with us and partnering with us. 189 | Does that make sense? 190 | >> It makes sense and so were you doing this through? 191 | I'm just trying to envision like how this happens, right? 192 | So are you sketching? 193 | Are you making mark ups and a graphics program, 194 | are you building interactive versions of it, and how are you working through this? 195 | Right, It's a complicated thing you're trying to do here, 196 | with this contextual navigation. 197 | So how do you kinda go from, 198 | I think this will be a cool idea to this is the right way to do it. 199 | >> Well, I got a big piece of foam core. 200 | >> Okay. >> And I got a bunch of sticky notes. 201 | And what I did was, and the reason I put it on foam core is, I wanted to work 202 | collaboratively with one of the developers to say, okay, this is what I'm thinking. 203 | And then I also wanted to work with a stakeholder that was living in, 204 | she was either in New York at the time or the Carolinas at the time. 205 | So what we did is we put one computer on the board, and 206 | we moved sticky notes around. 207 | Like I kind of seeded it and say, hey this is how I'm envisioning it. 208 | But since she's the marketing director, she's responsible for 209 | a lot of the content, a lot of the editorial work flow. 210 | All the research goes through her, and then gets populated on the site. 211 | So she really had, 212 | she was a subject matter expert on what's happening in the organization, so. 213 | And then I've got the developer there just watching and seeing this, 214 | because he's starting to estimate how much is this development time it's gonna be. 215 | The platform we're putting it on, I think we started with a WordPress site, 216 | wanted to make sure that was feasible. 217 | So that way, because it was sticky notes, it was never set in stone, and 218 | no one thought, it's in a spreadsheet, it's locked in no, it's not locked in. 219 | Let's do a collaborative exercise where we're moving sticky notes around. 220 | That was mobile, so I could move it to a different office, 221 | I could take a picture of it and send it to other people to kinda get. 222 | >> Mobile, because you could just take the foam core and. 223 | >> Yeah. Exactly. 224 | I can move it around and then, once I had those modules and 225 | objects kind of figured out. 226 | >> Mm-hm. 227 | >> I then went into a wire framing vector based OmniGraffle. 228 | >> Okay. >> And 229 | started laying out how these things would look on a page. 230 | But also how they would interact, and how they were sewn together. 231 | >> Mm-hm. 232 | >> And once I had that, I made it a clickable prototype. 233 | Not for users. 234 | I mean, that would've been great if we had that kind of resource and timing. 235 | But we felt we did a good enough job in the strategy phase. 236 | We felt this was good, was really just to show the stakeholders hey, 237 | this is how we're now envisioning your site. 238 | So they kinda had a preview, before we got into look and feel. 239 | Cuz at the same time, our visual designer was, 240 | hired a photographer to get some shots so that it wasn't stock photography. 241 | It was something that was more in line with their brand. 242 | Cuz she also wanted to kinda re-invision the brand. 243 | So she was trying to, she was thinking about different concepts of color and 244 | how that color would work on the site without taking. 245 | Taking too attention away from the articles. 246 | So kind of like, i'm doing the interaction design, 247 | while she's kinda doing the visual and emotional design at the same time. 248 | And so, and we're collaborating to say okay this is what i'm thinking here, and 249 | she's saying "okay this is what i'm thinking here.". 250 | And then we're presenting that you know, what was really great is In previous 251 | engagements, when I wasn't inside and I was at agencies. 252 | It was, like, we saw the client every once in a while. 253 | And we'd have these big deliverable dates. 254 | Where here, we said we want to meet with you at least every other week. 255 | >> Mm-hm. >> To show you our progress. 256 | We're never going to be. 257 | These are never done states. 258 | We're not having you sign off on it. 259 | >> Okay. >> We just 260 | want to show you what we're working on. 261 | >> Mm-hm. >> And have you collaborate with us. 262 | >> Mm-hm. 263 | And I felt that was a really successful way to do it but not, 264 | I think that's a best case scenario. 265 | You don't always have these high level directors of 266 | companies >> Right. 267 | >> that you can talk to twice a week. 268 | >> Right, right. 269 | >> Or I'm sorry, every other week. 270 | >> Right, right, right. 271 | So, but that's very interesting. 272 | So you're thinking very much about creating these artifacts that will, 273 | facilitate certain types of communication, right? 274 | >> Yes. >> Communication was a subject matter 275 | expert, trying to make sure that you get it right. 276 | Communication with the stakeholder to show progress, and 277 | also thinking about what kind of communication you wanna have. 278 | So it tells like you separate out conversations about the interaction 279 | design, from conversations about the look and feel, and the typography, and 280 | the specific images, and the colors and things like that. 281 | So that you can have these, kind of focused conversations. 282 | >> That's exactly right. 283 | I'd try to make sure that I wasn't painting us in any kind of corner, 284 | and allowing the stakeholders to have their say. 285 | >> Mm-hm. But at the same time, 286 | not having people get hung up on, you know, 287 | I don't really like the font or the colors that are happening here. 288 | And they're not paying attention to the interaction design or 289 | some of the content strategy. 290 | So we really did have to divorce certain things, and present certain kinda, 291 | slowly reveal things to people so we could get the right conversation, or 292 | the right kind of feedback. 293 | >> Mm-hm. 294 | So, and sometimes a sticky note, and some crude drawings are just enough. 295 | Just to set the direction. 296 | >> To keep it focused on that particular topic right there. 297 | and not get distracted by these other things. 298 | So it sounds like this story has a happy ending. 299 | You talked about the product that sounds like was released. 300 | You have some data that it's been successful in some ways, 301 | and so congratulations on that. 302 | >> Thank you. 303 | Yes. 304 | >> Excellent. 305 | So I know that before joining Ithaca, how long have you been at Ithaca? 306 | >> Three and a half years. 307 | >> About three and a half years. 308 | But I know from talking to you previously that 309 | You've done a bunch of other things as well. 310 | So I think it would be great to just hear about 311 | what your career has been like and how you got where you are right now. 312 | >> Okay, well I guess we can go back just before I went to graduate school. 313 | I was a photographer and I was in a research hospital. 314 | And we had a lab that was half chemical processes and 315 | half digital processes cuz this was the 1900s. 316 | So 1990s we were still doing a lot with film and chemicals. 317 | But I saw that the digital mediums and computers and especially with 318 | the beginning of the internet or the web photography was changing really fast. 319 | And it was becoming more digital. 320 | That's when I decided to go to graduate school for 321 | human computer interaction at the School for Information. 322 | So while I was there during the summer I got 323 | an internship at an agency actually doing what they called usability engineering, 324 | which was user research and doing design work. 325 | And I worked with visual designers and frontend developers. 326 | This was the year 2000. 327 | So during that time the dot com bubble burst. 328 | So the internship that I was hoping was gonna lead into full time employment 329 | was gone. 330 | So once I graduated from the School of Information I 331 | went to Wayne State University to become a digital librarian. 332 | So at my time at Wayne State it was a wonderful time. 333 | Because we had a grant called the 21st Century Librarian. 334 | So we had money to do special projects and fund graduate students to do the work. 335 | And some of that work was working with the Detroit News Photo Morgue. 336 | So we had images going back from the 1800s up until about 1980 for 337 | digitizing all of those images and associating metadata with those and 338 | then bringing them online for access. 339 | The other fun project was working for the Detroit Historical Museum and 340 | looking at their toy collection, primarily toys from the early 1900s that were 341 | wind-up toys and putting those online just to show people how they work. 342 | We actually got a lot of traffic from industrial designers that saw that and 343 | kinda used that as inspiration for their work. 344 | >> Interesting. 345 | >> While I was a digital librarian I wasn't really doing too much UX work. 346 | I was mainly working with professors or different libraries or 347 | different archives and my graduate students, which was a blast. 348 | But I also really liked to do design, user experienced design. 349 | So I did some freelance for some agencies. 350 | And then one day one of the agencies that I did work for 351 | offered me fulltime employment. 352 | So I started to go down that road. 353 | It was a very large agency. 354 | So it was cool because it was a print agency that was trying to figure out how 355 | to do digital. 356 | So I felt it was a cool kinda time of flux. 357 | But as things progressed I realized that I don't wanna be at a huge agency, 358 | especially an old-school agency. 359 | I wanna be at more of a startup feel. 360 | >> And an agency just to be clear is a company that does projects for 361 | external clients. 362 | So you might have a retailer one day and 363 | a manufacturer the next day and a taxi company the other day. 364 | And you're doing different, I'm making this up. 365 | But you're getting to do a lot of different types 366 | of projects and design work. 367 | >> Absolutely, and that's what was so 368 | fun is I usually had two concurrent projects happening. 369 | One would be for a wireless cell phone company and 370 | trying to figure out how they're gonna sell those products. 371 | And then the other thing might be doing a pitch for some kind of weird branding 372 | thing that we're gonna do like in the physical space and 373 | how does that physical space relate to something that's gonna be on the web. 374 | So it was always one thing was inspiring the other. 375 | And it was always really fast design work. 376 | Worked with a lot of cool people. 377 | But I'm not gonna say it wasn't stressful. 378 | It was a lot of work all the time. 379 | Especially at a big agency you always have these huge clients, the government. 380 | We've got the Navy, the United States Postal Service and then healthcare. 381 | We worked in a lot of different verticals. 382 | So financial services, healthcare, e-commerce. 383 | So you never know where you're gonna be. 384 | But you learn a ton all at once. 385 | But like I said I wanted to into some smaller agency that was more of a startup 386 | and found one where it was they really understood digital. 387 | They actually just were only digital. 388 | They had never done print or anything like that. 389 | But while I was there that's where I really got my e-commerce chops. 390 | Because we had a user research team and a user experience design team. 391 | So what would happen is we had our own usability lab in house. 392 | So when people were going through the e-commerce experience, shopping and then 393 | going through the shopping cart we were able to optimize every step of the way. 394 | And while we were studying and testing that we could between participants, 395 | between users, we could actually change the interface and tweak it so 396 | that we could really start dialing it in and get some of those gotchas out 397 | right away and then start to validate that design as we went through. 398 | >> Okay, so very tight integration between research and design. 399 | >> Yes, though they were, we had separatism. 400 | Cuz before I was like I was my own researcher. 401 | Or I wouldn't be able to do the recruiting. 402 | I would farm that out. 403 | But I would be running my tests. 404 | I would be creating the test, etc., which could have some 405 | ethical implications as far as am I objective when I'm testing my own designs. 406 | So it was good to have some of that was, okay. 407 | I'm not, I have no skin in this game. 408 | I'm just gonna test it for you. 409 | So that was pretty cool. 410 | And where I'm at now we have a user research team that goes out there, 411 | does observations, does ethnographic research. 412 | But also we have a usability lab here at Ithaca. 413 | So we kinda keep it separate, yet we're tightly integrated. 414 | I meet with them probably every other week so 415 | that they stay ahead of my recruiting needs or testing, design needs. 416 | >> So I'm gonna ask you for one parting thought, which is for 417 | folks that are just starting out, maybe just looking at UX or something that 418 | thinking about getting into, maybe thinking about moving towards a career. 419 | Do you have any advice? 420 | Absolutely, look at everything in your environment. 421 | And try to think about why it's there and its purpose. 422 | So I have a child. 423 | And it's great to look at his toys to think about, okay. 424 | What is its purpose? 425 | Does it communicate that purpose and do I like it? 426 | And so it really helps you influence of how you can think of an experience. 427 | Like this glass for instance. 428 | It has a purpose of it has to be a vessel to carry some water. 429 | But there a lot of things you can do to it. 430 | You can add color to it. 431 | You can have different shapes. 432 | But for instance it's not a bigger vessel. 433 | Because you gotta hold it with your hand. 434 | So it's think about that when you're thinking about your phone. 435 | You have to use it with your hand. 436 | And there's a certain amount of interaction with it and experience. 437 | So anyone that's thinking about getting into experience design or 438 | something like that it's fun to just critique things around you. 439 | Because then you can start thinking critically about design and 440 | why people create things. 441 | >> [SOUND] >> And then it really helps you influence. 442 | When you're in the digital realm you can do anything you want when you're not in 443 | the physical realm. 444 | So I like to juxtapose those things together. 445 | >> Excellent, yeah. 446 | So taking a designer eye view of the world 447 | is something that you can just do throughout you entire life. 448 | >> Right, exactly. 449 | And try to focus on the positive things and the things that make you feel good. 450 | Cuz a lot of times I could critic a ton of things that make me frustrated. 451 | And a lot of times that's what a lot of users feel that too. 452 | It's I'm so frustrated and we gotta make this better. 453 | >> So find some positive examples too. 454 | >> Exactly, exactly. >> Excellent, okay. 455 | Well, thank you very much. 456 | This has been great. 457 | And I really appreciate you taking your time to chat with us. 458 | >> Absolutely, thank you. -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L01-What-Is-User-Experience.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L01-What-Is-User-Experience.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L02-The-UX-Process.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L02-The-UX-Process.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L03-Components-of-UX.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L03-Components-of-UX.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L04-Basic-Methods-of-UX-Research.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L04-Basic-Methods-of-UX-Research.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L05-User-Testing-Part-01.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L05-User-Testing-Part-01.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L06-User-Testing-Part-02.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L06-User-Testing-Part-02.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L07-User-Testing-Part-03.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L07-User-Testing-Part-03.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L08-UX-Design-Overview.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L08-UX-Design-Overview.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L09-Prototypes.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L09-Prototypes.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L10-Sketching.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L10-Sketching.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L11-A-Brief-Incomplete-History-of-UX.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L11-A-Brief-Incomplete-History-of-UX.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Course-Documents/L12-Course-Summary.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Intro-to-User-Experience/Course-Documents/L12-Course-Summary.pdf -------------------------------------------------------------------------------- /UMI-Intro-to-User-Experience/Notes.md: -------------------------------------------------------------------------------- 1 | [Design-UX-UI Home](https://github.com/coolinmc6/design-ux-ui) 2 | 3 | 4 | # Introduction to User Experience 5 | 6 | ## Table of Contents 7 | 8 | - [Course Documents](https://github.com/coolinmc6/design-ux-ui/tree/master/UMI-Intro-to-User-Experience/Course-Documents) 9 | - [Course Summary and Key Take-aways](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#course-summary-and-key-take-aways) 10 | + [Basic Summary](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#basic-summary) 11 | + [Most Interesting Parts](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#most-interesting-parts) 12 | - [Part 1: What is UX? What are UX Research and Design](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#part-1-what-is-ux-what-are-ux-research-and-design) 13 | + [Lecture 1: What is User Experience](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l1-what-is-user-experience) 14 | + [Lecture 2: The UX Process](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l2-the-ux-process) 15 | + [Lecture 3: Components of UX](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l3-components-of-ux) 16 | - [Part 2: UX Research Overview - Part 1](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#part-2-ux-research-overview---part-1) 17 | + [Lecture 4: Basic Methods of UX Research](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l4-basic-methods-of-ux-research) 18 | + [Lecture 5: User Testing, Part 1](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l5-user-testing-part-1) 19 | + [Lecture 6: User Testing, Part 2](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l6-user-testing-part-2) 20 | + [Lecture 7: User Testing, Part 3](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l7-user-testing-part-3) 21 | - [Part 3: UX Research Overview - Part 2](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#part-3-ux-research-overview---part-2) 22 | + [Script for Micro-Usability Test Plan](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#script-for-micro-usability-test-plan) 23 | - [Part 4: UX Design Overview - Part 1](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#part-4-ux-design-overview---part-1) 24 | + [Lecture 8: UX Design Overview](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#lecture-8-ux-design-overview) 25 | + [Lecture 9: Prototypes](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#lecture-9-prototypes) 26 | + [Lecture 10: Sketching](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#lecture-10-sketching) 27 | - [Part 5: UX Design Overview - Part 2](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#part-5-ux-design-overview---part-2) 28 | + [Lecture 11: A Brief Incomplete History of UX](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#lecture-11-a-brief-incomplete-history-of-ux) 29 | + [Lecture 12: Course Summary](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#lecture-12-course-summary) 30 | 31 | 32 | ## Course Summary and Key Take-aways 33 | 34 | ### Basic Summary 35 | 36 | - *User experience* can be a difficult concept to understand because it's easy to have a feel for what makes *good UX* (i.e. useful, helpful, easy to learn, fun, etc.) and what makes *bad UX* (i.e. stressful, confusing, ugly, etc.) 37 | - But getting UX correct is hard 38 | - User experience generally defined is **the experience people have when they interact with your** 39 | **product** 40 | - This broad definition covers many areas BESIDES just using the product (i.e. acquiring the product, learning it, fixing the product, etc.) 41 | - One of the key take-aways of the course is that you can make UX easier if you do these four things: 42 | + 1. Follow an **iterative**, prototyping process 43 | + 2. Apply **user-centered** research and design methods 44 | + 3. **Understand** a bit about human behavior 45 | + 4. Apply **common sense** 46 | - For the first one, understanding that you must **iterate** is important. The general UX Process is: 47 | - Assess (what should I build?) then... 48 | - Design (what should it look like/how should it function?), then... 49 | - Build (build it and test it with users) 50 | - Understanding user-centered research and design methods can be further broken down into two parts: 51 | - *UX Research*: Interviews, Observations, Surveys, User Testing, Inspection Methods 52 | - *UX Design*: Personas/Scenarios/User Stories, Sketching and Ideation, Storyboarding, Mapping and Navigation Design, Comparative Research, Prototyping 53 | - There are certain things about how people work that are 'known' and can be learned: 54 | - What can people perceived? How they extract information from visual stimuli? 55 | - How do people do things? 56 | - How does emotion play a role? 57 | 58 | [back to top](#top) 59 | 60 | ### Most Interesting Parts 61 | 62 | - Understanding the [Components of UX](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l3-components-of-ux) provides a good baseline but feels very intuitive. The benefit to this list of items is that I won't have to derive it; to just get started, go through those four components (value, usability, desirability, and adoptability) and see how my product does in each one of those. 63 | + CM: I believe there are some questions for each component in the [course documents](https://github.com/coolinmc6/design-ux-ui/tree/master/UMI-Intro-to-User-Experience/Course-Documents) 64 | - The [Basic Methods of UX Research](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l4-basic-methods-of-ux-research) include Ask, Observe, and Inspect. This is a super-broad classification that, again, feels very intuitive. All three make sense but I can probably build my knowledge of each one (i.e. best practices for each) 65 | - The "Ask" category of research feels most basic but there are probably some best practices with surveys that I could easily learn and build upon 66 | - The "Observe" category of research involves the two main areas that I was most interested in before doing this class: User Testing (which is covered [here](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l5-user-testing-part-1), [here](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l6-user-testing-part-2), [here](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#l7-user-testing-part-3), and [here](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#script-for-micro-usability-test-plan)) and User Analytics which we didn't really touch 67 | + I must come back to this because the user testing parts have great info on how to do user tests, how to set it up and talk to users ("we are testing the system, not you"), close-ended vs. open-ended tasks, writing up a task list for participants, and the debrief. 68 | + I should spend just one hour and just get down on paper a basic "process" for how I would write up a task list, gather and talk to test users, talk to the users and administer the test, and then debrief. Even if it's just like 5-10 bullets for each, just to get a "process" down 69 | - The [UX Design](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#lecture-8-ux-design-overview) section starts with a few definitions of the word "design" that are clearly trying to get us to think of design beyond just what it looks like but rather **how it works** 70 | - The UX Design process is also pretty familiar because I've ready many blog posts, articles, books on these things but it's good to see a list and breakdown by "step" in the [process](#design-process) 71 | - The discussion of [Prototypes](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#lecture-9-prototypes) and [Sketching](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#lecture-10-sketching) are good but also very intuitive. The most interesting part was the ["lateral thinking"](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Intro-to-User-Experience/Notes.md#lateral-thinking) suggestion during the Generation phase in sketching. 72 | 73 | [back to top](#top) 74 | 75 | ### Learning Objectives 76 | 77 | - Learn about the skills needed for UX research and design 78 | - Understand how UX researchers discover and assess user needs and assess possible designs 79 | - Learn how to conduct a micro-usability test 80 | - Understand how UX designers use sketching and prototyping to develop design concepts 81 | - Understand how to incorporate a user-centered focus into the design process 82 | 83 | [back to top](#top) 84 | 85 | ## Part 1: What is UX? What are UX Research and Design? 86 | 87 | ### L1: What is User Experience? 88 | 89 | - What is Good UX? 90 | + usefule 91 | + helpful 92 | + easy to learn 93 | + accessible 94 | + attractive 95 | + fun 96 | + connected 97 | + delightful 98 | - What is a Bad UX? 99 | + Stressful 100 | + Confusing 101 | + Ugly 102 | + Distracting 103 | + Inefficient 104 | + Tedious 105 | + Condescending 106 | + Inconsiderate 107 | + Frustrating 108 | - Why does it matter? 109 | + A successful experience is the overlap of "what users want to do" and "what you want your users to do" 110 | - The Whole User Experience 111 | + UX = the experience people have when they interact with your product 112 | * using the product 113 | * choosing the product 114 | * acquiring the product 115 | * learning how to use the product 116 | * fixing the product 117 | * upgrading the product 118 | * etc. 119 | - Why is UX hard? 120 | + You are not the user? 121 | * you don't represent ALL users 122 | + Computers are *weird* 123 | * translating what is easy for computers into something that is easy for humans 124 | + Software is (usually) complex 125 | - How to Make UX Easy 126 | + Follow an interative prototyping process 127 | + Apply user-centered research and design methods 128 | + Understand a bit about human behavior 129 | + Apply common sense 130 | 131 | [back to top](#top) 132 | 133 | ### L2: The UX Process 134 | 135 | - How to Make UX Easy 136 | + Follow an interative prototyping process 137 | + Apply user-centered research and design methods 138 | + Understand a bit about human behavior 139 | + Apply common sense 140 | - Fail Fast 141 | + you won't get it right 142 | + get it wrong quickly and as often as possilbe 143 | + Assess => Design => Build => Assess (again) and so on 144 | * circular 145 | - the "Spiral Model" 146 | - UX Research in the "Assess" phase 147 | - UX Design in the "Design" phase 148 | * Key Methods: UX Research 149 | - Interviews 150 | - Observations 151 | - Surveys 152 | - User Testing 153 | - Inspection Methods 154 | * Key Methods: UX Design 155 | - Personas, Scenarios, User Stories 156 | - Sketching and Ideation 157 | - Storyboarding 158 | - Mapping and Navigation Design 159 | - Comparative Research 160 | - Lo-, Mid-, and Hi-Fidelity Prototyping 161 | * Understand How People Work 162 | - What can people perceive? 163 | + how do they extract information from visual stimuli 164 | - How do people do things? 165 | - How does emotion play a role? 166 | * Common Sense 167 | 168 | [back to top](#top) 169 | 170 | ### L3: Components of UX 171 | 172 | - Good and Bad UX 173 | - Components of UX 174 | + Value, Usability, Adoptability, Desirability 175 | + Value 176 | + Usability 177 | * can users do what they need to do? 178 | + Desirability 179 | * Is it fun, attractive and pleasant to use? 180 | + Adoptability 181 | * How easy is it to start using the device? 182 | * example: DuoLingo => start learning right away. 183 | - Assessing UX: Questions 184 | + Value 185 | * What do users need? 186 | * Does this design fulfill the need? 187 | + Usability 188 | * How do they do it now? 189 | - UX is not just about usability, attractiveness, etc. 190 | - Let the process be your guide; ask questions and iterate 191 | - **Homework:** 192 | + Discuss 1 example of good UX and 1 example of bad UX. Answer these questions: 193 | + What was your goal of using the interface? 194 | + What action did you intend to perform? 195 | + What features of the interface made it easy or difficult to perform the action? 196 | + How would you make it better if it was a bad design? 197 | 198 | 199 | [back to top](#top) 200 | 201 | ## Part 2: UX Research Overview - Part 1 202 | 203 | ### L4: Basic Methods of UX Research 204 | 205 | - Three basic methods of UX Research 206 | + Ask 207 | + Observe 208 | + Inspect 209 | - Ask 210 | + interviews 211 | + surveys 212 | * questions distributed to focus groups, diary studies, experience sampling 213 | - Observe 214 | + Ethnographic obsesrvations 215 | + User testing 216 | * ask them to perform specific tasks to see how they use the product 217 | + Usage Analytics 218 | * analyze large scale traces of system usage 219 | - Inspection Methods 220 | + guideline-based 221 | + Walkthroughs 222 | + Comparative Analysis 223 | - Combo: Watch and Ask 224 | + User testing 225 | + Contextual Interviews 226 | * ask questions while observing "natural" activities 227 | - When to use What? 228 | + Ask when: 229 | * observation is infeasible (infrequent, long, private) 230 | * values and motivations are key 231 | * (Surveys) Large numbers and high certainty are needed 232 | + Observer when: 233 | * Self-report will miss information (memory, tacit knowledge) 234 | * Process and communication are important 235 | * (Analytics) Large numbres and high certainty are needed 236 | + Inspect when: 237 | * you have a product to inspect 238 | 239 | [back to top](#top) 240 | 241 | ### L5: User Testing, Part 1 242 | 243 | - What is User Testing 244 | + Watch representative users try to accomplish importants tasks using a product 245 | + AKA "usability testing" 246 | - Why User Testing? 247 | + You learn a LOT from watching people use a system 248 | * What works and what doesn't 249 | * Why things work and don't 250 | * User needs you missed 251 | + Why not just use your own experience? 252 | * You know too much about the sytem, AND... 253 | * You know too little the users and their thinking 254 | - Basic Idea 255 | + Find potential users 256 | + Ask them to do some stuff 257 | + Observe 258 | + Ask some questions (debrief) 259 | + Write down what you learned 260 | - Potential Users 261 | + People who fall within the target audience 262 | * attitudes 263 | * behaviors 264 | * characteristics 265 | + NOT current users 266 | * OK if current users of the system but not for selected tasks 267 | - Tasks (what you ask them to do) 268 | + i.e. for Amazon 269 | * buy a coffee maker 270 | * write a book review 271 | - Choosing tasks 272 | + pick taks that most users need to do 273 | + Close-ended tasks 274 | * have a clear end point 275 | * have a verifiable outcome 276 | * Often has an expected path 277 | + Open-ended Tasks 278 | * Allow user to judge when complete 279 | * May not be verifiable 280 | * Allow following alternate paths 281 | * Examples: 282 | - find some books that you might like to read on vacation 283 | - CM: find some skills that you'd like to learn 284 | + Which are Better? 285 | * Close-Ended 286 | - less natural 287 | - control for motivation 288 | - control for interpretation 289 | - Assess for success 290 | * Open-Ended 291 | - More natural 292 | - varying motivation 293 | - Varying interpretation 294 | - Success is unknown 295 | * You can use both!! 296 | * Maybe use close-ended tasks initially to see that people can use it 297 | + Task Sets 298 | * Progress from easier to harder 299 | * Cover a range of critical task types (browse, search, buy) 300 | * Can include open and close-ended tasks 301 | * be careful to avoid "ordering effects" 302 | - if your tasks are set in a sequential or quasi-sequential order, they'd have help doing something that they normally wouldn't have 303 | 304 | [back to top](#top) 305 | 306 | ### L6: User Testing, Part 2 307 | 308 | - Task Wording 309 | + don't lead the witness 310 | * Not good: "Put three books in your shopping cart and buy them using standard shipping" 311 | * Better: "Choose three books and buy them" 312 | + Avoid ambiguity 313 | * Not good: "Use a list to find a gift for your 10-year old nephew" 314 | * Better: "A friend told you about Amazon's list feature. Use an Amazon list" 315 | + Include context and motivation 316 | * Not good: "Buy a book and have it shipped by Monday" 317 | * Better: "Colleagues from Japan are coming into town and you need a book on Japanese business practices by Monday to brush up on business etiquette" 318 | + Pilot Test 319 | * it's very hard to get right on the first try 320 | * Try the tasks out 321 | - Yourself!! 322 | - with a friend or two 323 | - Think Aloud 324 | + participants to say (out loud) what they are thinking 325 | + Thinking includes 326 | * looking for something 327 | * Reading text (have them read aloud) 328 | * Hypothesizing about how the system might work 329 | * Interpreting system options 330 | * Interpreting system feedback 331 | * Explaining decisions 332 | * Feeling frustrated, happy 333 | + Advantages 334 | * hear how the user thinks about the task 335 | * learn what the user actually sees and notices 336 | * hear how the user interprets options, feedback 337 | + Disadvantages 338 | * timing will not be realistic 339 | * attention to detail will not be quite realistic 340 | * need to determine "rules of engagement" for questions, mistakes, etc. 341 | - are you not going to act like a normal person and just NOT answer them? State that up front 342 | 343 | [back to top](#top) 344 | 345 | ### L7: User Testing, Part 3 346 | 347 | - Debrief (after tasks) 348 | + Review problems, get more information 349 | + Ask about usefulness, value 350 | + Ask about perceived usability, aesthetics, credibility 351 | + compare to known alternatives 352 | - Making Sense of the Test 353 | + Capture "critical incidents" 354 | * errors 355 | * expressions of frustration 356 | * breakdowns 357 | - something took a really long time but should've been quick 358 | - roundabout processes 359 | * pleasant surprises 360 | + Assess success/failure 361 | * usually a spectrum 362 | + Capture overall reaction & reaction to specific aspects 363 | + Link incidents, success/failure, and subjective reaction 364 | - Learning from the Test 365 | + Quick! Write it down! 366 | + Critical Incidents and WHY they happened 367 | * mental model mismatches 368 | * misinterpretations 369 | * invalid assumptions made by the system 370 | * missing user needs 371 | * too little flexibility 372 | * too little guidance 373 | + Here are some more high-level questions for them? 374 | * What is your overall impression of *the product*? 375 | * Do you think that *the product* would be useful for you, personally? Why or why not? 376 | * If no: who do you think it would be useful for? Why? 377 | * What do you like best about *the product*? 378 | * What do you think needs to be improved? 379 | + Follow-up with some questions about the specific product that is relevant to THEM as a person. Here is an example of some of those questions using Doodle as the product: 380 | * How often do you schedule meetings with other people? 381 | * How do you usually go about scheduling such meetings? 382 | * Have you ever used any sites or apps that you think are similar to Doodle? Which ones, and how much experience have you had with them? 383 | * How many hours per week would you estimate that you spend online? 384 | + Problems => Severity: impact on... 385 | * success/failure 386 | - did the problems affect the success or failure of the task? Some problems are show-stoppers and others are not 387 | * subjective experience 388 | - how did they problems affect their experience? Did it completely ruin it? 389 | * product goals 390 | - did they use the product in a different way than you expected? 391 | + Other UX factors 392 | * usefulness 393 | * desirability 394 | * credibility 395 | + Wrap up your de-brief with a summary of the following items: 396 | * Participants: who they were / kind of users they were 397 | * Basic Results: how well did the test go, did they succeed? Did all participants succeed? Any partial or complete failures? 398 | * Findings and Recommendations: 399 | - report major problems and try to diagnose the causes 400 | - Focus on the few significant observations, not a long list of minor things 401 | - What worked well? What didn't? What were the most confusing / frustrating parts? 402 | - Support findings with your EVIDENCE 403 | - One Other VERY IMPORTANT Thing 404 | + participation is voluntary 405 | + participants can stop at any time 406 | + you are testing the system, not the participant 407 | + you need to let the participants know this 408 | * make them feel comfortable! The system is being tested, which means that they're struggles are really the struggles of the system 409 | - What's "Micro" About This? 410 | + relaxed recruiting 411 | * people close enough to target audience to be able to imagine 412 | * A.K.A. "Hallway" usability test 413 | + Fewer tasks 414 | * < 30 minutes rather than 60-90 minutes 415 | + Little or no data collection 416 | * no recording 417 | * no questionnaires 418 | * no logging 419 | + Off-the-cuff analysis 420 | 421 | - For the assignment, I need to prepare two test scripts (or one script with two versions): 422 | + Moderator Script - one for MY reference with the tasks, my notes and tips, etc. 423 | + Participant Script - this contains ONLY the tasks to be shared with the participant 424 | - Make sure the assignments are timed; you don't have to rush through them 425 | - Debrief 426 | + write down your notes about their performance 427 | 428 | 429 | 430 | [back to top](#top) 431 | 432 | ## Part 3: UX Research Overview - Part 2 433 | 434 | ### Script for Micro-Usability Test Plan 435 | 436 | #### Preamble 437 | Hi, my name is Stanley, 438 | 439 | 440 | Thank you so much for coming. How are you today? Today we’d like you to help us understand how well the site Cars.com help people explore and find cars they want. So, we’d like you to do a couple of tasks using the site and collect your feedback. Specifically we’d like to know what you think about the site, and what works and doesn’t work for you. Your feedback will help us learn how we can improve the site. 441 | 442 | 443 | Before we start, here are several things I’d like you to know. First of all, we’re testing the site but not you. There’s nothing you can do wrong. So don’t worry about making any mistakes. If you cannot get something to work, or you think there’s anything broken or wrong or weird or confusing, it is not your fault but the system’s fault. Please let us know exactly what you think about the site. You can be honest. You won’t hurt anyone’s feelings if you say something bad about it. This is actually why we are bringing you here today to let us know which part of the site doesn’t do a good job. 444 | 445 | 446 | I’ll tell you what tasks to do using the site. After you start, please try to focus on the tasks, but I may ask you a few questions during test. You can also ask me questions, but I may not be able to answer all of them, because we’re trying to observe what people do when there’s no one sitting next to them. But I’ll try to answer questions you still have when we are done. 447 | 448 | 449 | As we go along, I’m going to ask you to think aloud, which means that you speak all of your thoughts while you’re using the site, for example: what you’re looking at, what you’re trying to do, what you’re doing and thinking, why you’re doing and thinking that way. If you can’t find a way to complete a task and you think you’re stuck, let me know and you can move on to the next one. For each task you’re asked to do, tell me “I’m done” when you think you are done. 450 | 451 | 452 | **Do you have any questions for me before we begin?** 453 | 454 | #### Pre-Test Questions 455 | 456 | Before we look at the site, I’d like to ask you just a few quick questions. 457 | 458 | 1. First, what’s your occupation? 459 | 460 | 2. Roughly how many hours a week would you say you spend using the Internet, including email and messaging? 461 | 462 | 3. How often do you shop online, and what types of products do you purchase online? 463 | 464 | 4. Can you tell us a couple of your favorite sites for shopping? 465 | 466 | **Now I’m going to ask your experience of purchasing vehicles.** 467 | 468 | 1. How many vehicles have you owned 469 | 470 | 2. How many times have you purchased vehicles online? 471 | 472 | 3. What factors do you consider when you buy a vehicle? 473 | 474 | **Follow up: which factor is most important to you?** 475 | 476 | 1. How far are you willing to travel to a dealer to buy a automobile? 477 | 478 | 479 | **Read Description (20 seconds)** 480 | 481 | Now I’m going to ask you to do some specific tasks. I’ll read each one out loud and here’s a printed copy for your reference. 482 | 483 | And again, it’d be much helpful if you can think out loud as you go along. 484 | 485 | #### Task 1: (10 minutes) 486 | 487 | A family member of yours asks if you can find a car for her using Cars.com because she has been very busy recently. She wants to buy a used Honda Civic that: 488 | 489 | - Is not older than 3 years 490 | - Uses automatic transmission 491 | - Is under $20,000 US dollars 492 | - Is either grey, white, or black. 493 | - She also doesn’t want to travel too far away from home, and she wants the car to be as cheap as possible. 494 | 495 | **Find two cars based on her preference.** 496 | 497 | Great thanks, here’s the the second thing I’d like you to do 498 | 499 | #### Task 2: (10 minutes) 500 | 501 | You are in the market for a new car. You have saved $4000 for a down payment and have determined that you can afford a monthly payment of at most $400 towards a five-year car loan. Figure out the maximum price you can afford for a new car. 502 | 503 | #### Task 3: (15 minutes) 504 | 505 | You want to buy a new car using Cars.com that fits into your budget (as determined in the previous task). Use Cars.com to find a car for yourself, using using your own criteria, such as price, appearance, and engine. Find at least two cars that you’re interested in and put them in your list so that you can compare them later. 506 | 507 | #### Task 4 (optional) 508 | 509 | You have saved two cars, and now you want to compare the cars. Choose one you like the most. and plan your visit to the dealer(s) on this weekend that sells the car. In addition, find out what other cars are also available at the dealers. 510 | 511 | #### Debriefing (1-2 minutes) 512 | That was great. Thank you for the feedback, We have learned so much from you. Now I’m going to wrap up with a couple of questions” 513 | 514 | 1. Which part of the site did you find difficult or easy to use for the tasks? 515 | 516 | 2. Is there anything on the interface that didn't make sense to you, or is confusing to you? 517 | 518 | 3. I noticed that you… (fill in with questions around what you noticed about their actions) 519 | 520 | 4. What were you thinking when you… (fill in with questions around what) 521 | 522 | **Do you have any final comments or questions?** 523 | 524 | .. 525 | 526 | OK Thank you so much again for your time and participation. If you have any other thoughts or ideas coming up, please let me know. 527 | 528 | ### Interview with UX Researcher Lija Hogan 529 | 530 | - watched 531 | 532 | [back to top](#top) 533 | 534 | ## Part 4: UX Design Overview - Part 1 535 | 536 | ### Lecture 8: UX Design Overview 537 | 538 | - What is Design? 539 | + it's not just what it looks like; design is how it works 540 | + Design is a plan for arranging elements in such a way to best accomplish a particular purpose 541 | - What is design? 542 | + a plan 543 | + arranging elements 544 | + a purpose 545 | + what it looks like / feels like 546 | - What is design? 547 | + Design is *solving problems* 548 | + Design is as much a matter of finding problems as solving them 549 | - The Design Process 550 | + Understand the problem 551 | + Generate Possible Solutions 552 | + Analyze and Select 553 | + Embody the solutions (i.e. build a prototype) 554 | + Assess (find new problems) 555 | - 50 Problems in 50 Days 556 | + [http://50problems50days.com/](http://50problems50days.com/) 557 | - What is special about UX Design? 558 | + Experiences are interactive 559 | * time-based 560 | * action-response rules 561 | * Action: command options (things that users can do) 562 | * Response: information presentation 563 | * Complex system behavior (focus on usability) 564 | + Context is Critical 565 | * other interactions 566 | - The UX Design Process 567 | 568 | |Step|Actions| 569 | |:---:|:---:| 570 | |Understand the problem|Study users: tasks and context| 571 | |Generate Possible Solutions|Sketch, storyboard, wireframe| 572 | |Analyze and Select|Apply UX criteria| 573 | |Embody the solutions|build prototype| 574 | |Assess (find new problems)|Apply UX research methods| 575 | 576 | - ...and Repeat! 577 | 578 | [back to top](#top) 579 | 580 | ### Lecture 9: Prototypes 581 | 582 | - A prototype is... 583 | + a representation of a design made before the final solution exists 584 | - Why prototype? 585 | + Reification => make our ideas concrete 586 | + Reflection 587 | + Communication 588 | + Assessment 589 | - Prototypes have many forms 590 | + a "representation of a design" can mean many things 591 | + lower-fidelity prototypes are obviously cheaper; start lo-fi and work up 592 | - Lo-fi Prototypes 593 | + Address 594 | * functionality 595 | * basic organization 596 | * task flow and converage 597 | + Ignore 598 | * graphics 599 | * programming 600 | * real data 601 | - Mid-fi Prototypes 602 | + Address 603 | * all the same as Lo-fi plus... 604 | * layout 605 | * interactivity 606 | * navigation 607 | + Ignore 608 | * graphics 609 | * programming 610 | * real data 611 | - Hi-fi Prototypes 612 | + Address 613 | * Mid and Lo-fiedlity plus... 614 | * graphic design 615 | * interaction details 616 | * realistic data 617 | + Ignore 618 | * backend programming 619 | * complete functional coverage 620 | - Economic principle of prototyping 621 | + the best prototype is th eone that, in the simplest and most efficient way, makes the possiblities of a design idea visible and measureable 622 | - Premature Commitment 623 | + Looking to avoid investing resources (time, money) in a dead end 624 | + Problems 625 | * waste money and effort 626 | * exhause project resources/timeline, stuck with a bad design 627 | * cognitive and emotional commitments hard to undo 628 | - Lo-fi prototyping maximizes the number of times you get to refine your design before going to production 629 | - Lo-fi prototypes are not precious so people are more likely to give honest feedback 630 | 631 | 632 | [back to top](#top) 633 | 634 | ### Lecture 10: Sketching 635 | 636 | - Qualities of a sketch 637 | + quick 638 | + timely 639 | + inexpensive 640 | + disposable 641 | + plentiful 642 | + minimal detail 643 | + allow ambiguity 644 | - Sketching is not just making sketches; it's about discussing the sketches as well 645 | - Why sketch? 646 | + Reflect on those sketches 647 | + Explore 648 | + Communicate quickly 649 | - How to sketch 650 | + Use pencil and paper (whiteboard OK) 651 | + Go fast 652 | + Don't perfect 653 | + Make lots of them 654 | + You do NOT have to be "good at drawing" 655 | - What to sketch 656 | + The problem 657 | * How would someone experience this problem? 658 | + The solution 659 | * What would it look like for the problem to be solved? 660 | * How would a system help solve the problem? 661 | - Read about Bill Buxton on sketching 662 | - Opposing Processes in Design 663 | - Phases of Generation and Convergence 664 | - Generation: Create a LOT of sketches 665 | + Quantity over quality 666 | + Build, don't critique 667 | + Apply "lateral thinking" 668 | * the solving of problems by an indirect and creative approach, typically through viewing the problem in a new and unusual light. 669 | * Is a technique of problem solving by approaching problems indirectly at diverse angles instead of concentrating on one approach at length. 670 | * Idea generation and problem solving technique in which new concepts are created by looking at things in novel ways 671 | * Edward de Bono - lateral thinking 672 | - Convergence 673 | + Synthesize 674 | * bring those ideas together; distill 675 | + Apply criteria 676 | + Critique 677 | + Eliminate some ideas, promote others 678 | - Sketchers' Block: Ideation 679 | + Don't stop 680 | + Brainstorm to get ideas 681 | + Matrix techniques => Morphological Analysis 682 | - Ideation Technique: the Worst Idea 683 | + use when stuck 684 | + think of the worst ideas you can for solving the problem 685 | + use these for inspiration 686 | - Go sketch 687 | + quick 688 | + imperfect 689 | + Quanity > Quality 690 | + Generate rathern than convergence 691 | + Lateral thinking 692 | 693 | [back to top](#top) 694 | 695 | ## Part 5: UX Design Overview - Part 2 696 | 697 | ### Interview: UX Designer Matt Martin 698 | 699 | 700 | 701 | ### Lecture 11: A Brief Incomplete History of UX 702 | 703 | - Human Computer Interaction, 704 | - The Birth of HCI (Human Computer Interaction): Early 80's 705 | + computer use by non-programmers 706 | + graphical user interface (GUI) 707 | + 1982 - First CHI Conference in Gaithersburg, MD (907 attendees) 708 | * CHI = pronounced "kai" 709 | - 1980's Practice: Usability and UI Design 710 | + to learn the practice: 711 | * attend CHI 712 | * do one of a few random classes around the country (CS and psych) 713 | + Books: 714 | * User Centered System 715 | * Psychology of Everyday Things 716 | - the Design of Everyday Things 717 | - Usability as a Software Engineering Issue 718 | + Usability Testing 719 | * often performed at the end of development to validate the product 720 | + UI Design 721 | * putting a "pretty face" on software whose functionality was pretty much already setup 722 | - The Internet Changes Everything 723 | + 1988 - WWW "invented" by Tim Berners-Lee 724 | * specification to allow pages to be linked together 725 | + 1991 - The first web page 726 | + 1993 - Mosaic web browser released 727 | + 1995 - Internet commerce allowed 728 | * Amazon.com was released 729 | + 1997 - 2000 - the dot com bubble 730 | + Suddenly a LOT more people were dealing with this stuff 731 | * more companies 732 | * more end users 733 | * ALL doing more stuff 734 | - Mow everyone is paying attention 735 | + 10's of thousands of jobs 736 | + 1000's of new "web designers" 737 | + UI Design and Usability engineering not enough 738 | - Hello, Interaction Design 739 | + Bill Verplank 740 | + Bill Moggridge 741 | + both were industrial designers by trade 742 | + Captured the shift 743 | * beyond user interface design 744 | * beyond usability engineering 745 | * beyond human-computer interaction 746 | * beyond graphical/industrial design 747 | * beyond software engineering 748 | - 2000's: From Sites to Apps to Services 749 | + Computing as a way of life, not a special activity 750 | + Computing as part of an ongoing relationship with customers 751 | + Merging of usability and interaction design with: 752 | * marketing and branding 753 | * market research 754 | * product strategy 755 | * physical design 756 | + Recognition of User Experience as a central concern for products, brands and enterprises 757 | - User Experience Today 758 | + Now seen as strategically important 759 | + common set of concerns and basic approaches 760 | + Increasing Specialization 761 | 762 | 763 | 764 | 765 | 766 | 767 | 768 | 769 | 770 | 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | 779 | 780 | 781 | 782 | 783 | 784 | 785 | 786 | 787 | 788 | 789 |
UX ResearchUX Design
Qualitative UX ResearchVisual Design
Quantitative UX ResearchInteraction Design
Information Architecture
Project Management
UX Strategy
790 | 791 | - In a nutshell 792 | + the history of UX is the history of user-centered design 793 | + terminology changes but the focus remains and evolves 794 | + specialization is common but the big picture is essential 795 | + UX is increasingly important to business and everything we do 796 | 797 | [back to top](#top) 798 | 799 | ### Lecture 12: Course Summary 800 | 801 | - Course Summary 802 | + UX is important 803 | + UX doesn't come easu 804 | - How to make UX easy 805 | + follow an iterative prototyping process 806 | + apply user-centered research and design methods 807 | + understand ab it about human behavior 808 | + apply common sense 809 | - What Next? 810 | + Deeper into UX Research 811 | * undestanding user needs 812 | * formal user testing 813 | * inspection methods 814 | * large-scale methods 815 | - web analytics, A/B testing 816 | + Deeper into UX Design 817 | * building prototypes 818 | * representing users and tasks 819 | * specifying system behavior 820 | + Putting it all together 821 | * Combining UX Research and UX Design in a single project 822 | - The MicroMasters 823 | + 1 - Introduction to User Experience (this course) 824 | + 2 - Understanding User Needs 825 | + 3 - Principles of Designing for Humans 826 | + 4 - Evaluating Designs with Users 827 | + 5 - UX Design: From Concept to Wireframe 828 | + 6 - UX Design: From Wireframe to Prototype 829 | + 7 - UX Research Surveys 830 | + 8 - UX Research at Scale: Analytics and Online Experiments 831 | + 9 - UX Capstone 832 | 833 | 834 | [back to top](#top) 835 | 836 | 837 | 838 | 839 | 840 | 841 | 842 | 843 | 844 | 845 | 846 | 847 | 848 | 849 | 850 | 851 | 852 | 853 | 854 | 855 | 856 | 857 | 858 | 859 | 860 | 861 | 862 | 863 | 864 | 865 | 866 | 867 | 868 | 869 | 870 | 871 | 872 | 873 | -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L01-Visual-Perception-Part-1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L01-Visual-Perception-Part-1.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L02-Visual-Perception-Part-2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L02-Visual-Perception-Part-2.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L03-Memory-Part-1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L03-Memory-Part-1.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L04-Memory-Part-2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L04-Memory-Part-2.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L05-Seven-Stages-of-Action.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L05-Seven-Stages-of-Action.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L06-Gulfs-of-Execution-and-Evaluation.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L06-Gulfs-of-Execution-and-Evaluation.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L07-Design-Principles.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L07-Design-Principles.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L08-Heuristics-for-Design.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L08-Heuristics-for-Design.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L09-Heuristic1-Visibility-of-System-Status.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L09-Heuristic1-Visibility-of-System-Status.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L10-Heuristic2-Match-Between-System-and-Real-World.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L10-Heuristic2-Match-Between-System-and-Real-World.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L11-Heuristic3-User-Control-and-Freedom.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L11-Heuristic3-User-Control-and-Freedom.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L12-Heuristic4-Consistency-and-Standards.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L12-Heuristic4-Consistency-and-Standards.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L13-Heuristic5-Error-Prevention.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L13-Heuristic5-Error-Prevention.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L14-Heuristic6-Recognition-Over-Recall.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L14-Heuristic6-Recognition-Over-Recall.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L15-Heuristic7-Flexibility-and-Efficiency-of-Use.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L15-Heuristic7-Flexibility-and-Efficiency-of-Use.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L16-Heuristic8-Aesthetic-and-Minimalist-Design.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L16-Heuristic8-Aesthetic-and-Minimalist-Design.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L17-Heuristic9-Error-Recovery.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L17-Heuristic9-Error-Recovery.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L18-Heuristic10-Help-and-Documentation.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L18-Heuristic10-Help-and-Documentation.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L19-Heuristic-Evaluation.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L19-Heuristic-Evaluation.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Course-Documents/L20-Course-Wrap-up.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Principles-of-Designing-for-Humans/Course-Documents/L20-Course-Wrap-up.pdf -------------------------------------------------------------------------------- /UMI-Principles-of-Designing-for-Humans/Notes.md: -------------------------------------------------------------------------------- 1 | [Design-UX-UI Home](https://github.com/coolinmc6/design-ux-ui) 2 | 3 | 4 | # Principles of Designing for Humans 5 | 6 | ## Table of Contents 7 | 8 | - [Course Documents](https://github.com/coolinmc6/design-ux-ui/tree/master/UMI-Principles-of-Designing-for-Humans/Course-Documents) 9 | - [Course Summary and Key Take-aways](#course-summary-and-key-take-aways) 10 | + [Basic Summary](#course-summary) 11 | + [Recommended Resources](#recommended-resources) 12 | - [How do People Perceive Information?](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#how-do-people-perceive-information) 13 | + [Visual Perception - Part 1](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l1-visual-perception-part-1) 14 | + [Visual Perception - Part 2](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l2-visual-perception-part-2) 15 | + [Memory - Part 1](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l3-memory-part-1) 16 | + [Section Summary and Quiz](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#section-summary-and-quiz) 17 | - [How Do People Act in the World?](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#how-do-people-act-in-the-world) 18 | + [Seven Stages of Action](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l5-seven-stages-of-action) 19 | + [Gulfs of Execution and Evaluation](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l6-gulfs-of-execution-and-evaluation) 20 | + [Design Principles](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l7-design-principles) 21 | - [Design Heuristics](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#design-heuristics) 22 | + [Heuristics for Design](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l8-heuristics-for-design) 23 | + [Heuristic #1: Visibility of System Status](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l9-heuristic-1-visibility-of-system-status) 24 | + [Heuristic #2: Match Between System and Real World](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l10-heuristic-2-match-between-system-and-real-world) 25 | + [Heuristic #3: User Control and Freedom](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l11-heuristic-3-user-control-and-freedom) 26 | + [Heuristic #4: Consistency and Standards](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l12-heuristic-4-consistency-and-standards) 27 | + [Heuristic #5: Error Prevention](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l13-heuristic-5-error-prevention) 28 | + [Heuristic #6: Recognition Over Recall](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l14-heuristic-6-recognition-over-recall) 29 | + [Heuristic #7: Flexibility and Efficency of Use](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l15-heuristic-7-flexibility-and-efficency-of-use) 30 | + [Heuristic #8: Aesthetic and Minimalist Design](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l16-heuristic-8-aesthetic-and-minimalist-design) 31 | + [Heuristic #9: Error Recovery](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l17-heuristic-9-error-recovery) 32 | + [Heuristic #10: Help and Documentation](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l18-heuristic-10-help-and-documentation) 33 | - [Heuristic Evaluation and Course Wrap-up](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#heuristic-evaluation-and-course-wrap-up) 34 | + [Heuristic Evaluation](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l19-heuristic-evaluation) 35 | + [Course Wrap-up](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l20-course-wrap-up--next-steps) 36 | 37 | ## Course Summary and Key Take-aways 38 | 39 | ### Course Summary 40 | 41 | - The course opens with some information about how humans perceive information and then with how we remember / learn something. This is important because we have our five senses (sight, hearing, touch, smell, taste) but with a website, understanding how we visually perceive something is incredibly important because **most information is conveyed visually**. 42 | - There are [three stages of perception](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l2-visual-perception-part-2): 43 | + Features (colors, shapes, lines) 44 | + Patterns 45 | + Gestalt Principles (interpreting those patterns as objects) 46 | * The Gestalt Princples are also known as the [principles of grouping](https://en.wikipedia.org/wiki/Principles_of_grouping) or *Gestalt laws of grouping* 47 | * Here is a good intro article I should take a look at to understand how to use the Gestalt principles: 48 | * [https://www.usertesting.com/blog/gestalt-principles/](https://www.usertesting.com/blog/gestalt-principles/) 49 | * [https://uxplanet.org/gestalt-theory-for-ux-design-principle-of-proximity-e56b136d52d1](https://uxplanet.org/gestalt-theory-for-ux-design-principle-of-proximity-e56b136d52d1) 50 | - A good foundation for understanding the journey from your senses to memory: 51 | 1. Sensory Register => requires your attention; only a small amount of what **could** be perceived is actually perceived 52 | 2. Perception => that which is perceived is available for thought, but only **briefly** 53 | 3. Short-term Memory => your short-term memory can only hold 7 +/- 2 items and not everything is committed to long-term memory 54 | 4. Long-term Memory => to learn something (i.e. commit to long-term memory), it must be associated with what you already know OR repeated 55 | - Transferring this knowledge to user experience, there are a couple key points we should remember: 56 | + avoid asking users to memorize stuff 57 | * provide menu options and autocomplete 58 | + leverage consistency, standards and best practices from other areas that you **know** they will be know 59 | * i.e. Google Sheets/Docs/etc. has same menu bar (mostly) across all apps 60 | + use metaphors to help their understanding (i.e. a shopping cart, trash can, etc.) 61 | - The [Seven Stages of Action](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l5-seven-stages-of-action) is an interesting framework for understanding how people do things 62 | - There are a list of [Design Principles](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l7-design-principles) worth looking over. It would probably be useful to go through these again but the [Heuristics for Design](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l8-heuristics-for-design) should be my immediate focus. **I really think that learning these and understanding examples of each would provide a good foundation to understanding how effective an app works**. 63 | - Here are the 10 Heuristics: 64 | 1. [Visibility of system status](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l9-heuristic-1-visibility-of-system-status) 65 | 1. [match between system and the real world](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l10-heuristic-2-match-between-system-and-real-world) 66 | 1. [User control and freedom](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l11-heuristic-3-user-control-and-freedom) 67 | 1. [Consistency and standards](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l12-heuristic-4-consistency-and-standards) 68 | 1. [Error prevention](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l13-heuristic-5-error-prevention) 69 | 1. [Recognition rather than recall](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l14-heuristic-6-recognition-over-recall) 70 | 1. [Flexibility and efficiency of use](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l15-heuristic-7-flexibility-and-efficency-of-use) 71 | 1. [Aesthetic and minimalist design](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l16-heuristic-8-aesthetic-and-minimalist-design) 72 | 1. [Help users recognize, diagnose and recover from errors](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l17-heuristic-9-error-recovery) 73 | 1. [Help and documentation](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l18-heuristic-10-help-and-documentation) 74 | - Lastly, the course ends with an example [Heuristic Evaluation](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Principles-of-Designing-for-Humans/Notes.md#l19-heuristic-evaluation) that would provide a quick and easy way to evaluate an app or website. 75 | 76 | ### Recommended Resources 77 | 78 | - Don Norman: The Design of Everyday Things 79 | - Jeff Johnson: Designing with the Mind in Mind 80 | - Steve Krug: Don't Make Me Think 81 | - Observing the User Experience 82 | - Don Norman: Emotional Design 83 | - Adny Polaine: Service Design: From Insight to Inspiration 84 | 85 | [back to top](#top) 86 | 87 | ## How do People Perceive Information? 88 | 89 | ### L1: Visual Perception, Part 1 90 | 91 | - Principles 92 | + make important info & actions visible 93 | + Leverage "the read" 94 | * i.e. the F-shape pattern 95 | + When evaluating, ask yourself, "did they see it?" 96 | 97 | ### L2: Visual Perception, Part 2 98 | 99 | - Three stages 100 | + features (colors, shapes, lines) 101 | + patterns 102 | + interpret those patterns as objects 103 | - Feature Detection 104 | + Color => we see this instantly 105 | + Value => light to dark 106 | + Angles => 107 | + Slope 108 | + Length 109 | + Tectures => smooth, bumpy, etc. 110 | + Motion 111 | + Feature detection happens very quickly 112 | + Allows "pop-out" of certain distinc colors, shapes, etc. 113 | + Supports subsequent stages: 114 | * patterns and objects 115 | - First Stage: Feature Detection 116 | - Second Stage: Patterns 117 | - Pattern Identification: Gestalt Principles 118 | + Proximity 119 | + Closure and continuation 120 | * think of the incomplete circle 121 | + symmetry 122 | + similarity 123 | + common area 124 | * objects within a closed area 125 | + common fate 126 | - Principles 127 | + Use "pop out" (primitive features) to attract attention 128 | + Use Gestalt principles to associate like items 129 | + Use Gestalt principles to organize for skippability 130 | - Zappos page: 131 | + boots are photographed in the same orientation to make it easy to compare 132 | + breaks the similarity to allow people to navigate around the page and focus on the things they want to focus on 133 | - 134 | 135 | [back to top](#top) 136 | 137 | ### L3: Memory, Part 1 138 | 139 | - From the senses to memory: 140 | + Sensory Register => Perception => Short-term Memory => Long-term Memory 141 | + Sensory Register 142 | * requires attention 143 | * a small amount of what is available is actually perceived 144 | + Perception 145 | * whatever is perceived is avaiable for thought - but only briefly 146 | + Short term memory 147 | * relatively to small amount of information is "learned" (committed from short-term to long-term memory) 148 | + focusing on short-term memory in this lecture 149 | - Short-term Memory 150 | + limited capacity 151 | * the "magic number" 7 +/- 2 items (Miller's Law) 152 | * Maybe more like 4 +/- 1 153 | + Information that is not retained is lost 154 | * "Retained" means "committed to long-term memory" 155 | - Principles 156 | + Keep lists of options short 157 | + Give users tools for reducing options 158 | + Don't expect users to remember stuff 159 | 160 | [back to top](#top) 161 | 162 | ### L4: Memory, Part 2 163 | 164 | - Long Term Memory 165 | + anything remembered for more than a few seconds 166 | + must be "copied" from short-term to long-term 167 | - Transfer to Long-Term Memory 168 | + Association 169 | * associated with something that you already know 170 | + Repetition 171 | - Memorization 172 | + "Elaborative rehearsal" 173 | * expending effort to commit something to long-term memory 174 | - Associative vs. Elaborative 175 | + Which is easier for a user? **Associative** 176 | + Which is most likely to be remembered? **Associative** 177 | - Likelihood of Remembering 178 | + Strength of association 179 | + Recency 180 | + Frequency 181 | - Principles 182 | + Learning will work better if learner can fit into a schema 183 | * use metaphors 184 | * leverage standards and consistency 185 | * Avoid asking users to memorize stuff 186 | + Prefer recognition over recall 187 | - Leverage Consistency and Standards 188 | + Think of Google Docs, Google Sheets, and Microsoft Word => they all have common / similar menu structures 189 | - Avoid asking users to memorize stuff 190 | + complicated password requirements 191 | - Prioritize recognition over recall 192 | + provide menu options (i.e. autocomplete options when searching) 193 | 194 | ### Section Summary and Quiz 195 | 196 | - Human visual processing: 197 | + primitive visual features (color, contrast, angle, length, and slope of lines, texture, motion) 198 | + gestalt principles for pattern-forming (proximity, closure and continuation, symmetry, similarity, common fate, common area) 199 | - Memory 200 | - characteristics of short-term memory (size and duration) 201 | - characteristics of long-term memory (association, schema, recall, elaborative rehearsal) 202 | * Quiz Answers: 203 | - The “central vision” portion of the human field of view, in which people can read text and recognize details in images, is approximately 5 degrees 204 | - Primitive visual features include: 205 | + angle of intersection 206 | + shade / contrast 207 | + motion 208 | - NOT included: 209 | + proximity 210 | - **schema**: a collection of associated concepts in long-term memory 211 | 212 | [back to top](#top) 213 | 214 | ## How Do People Act in the World? 215 | 216 | ### L5: Seven Stages of Action 217 | 218 | - Don Norman's "Design of Everyday Things" 219 | - Seven stages of action 220 | + Forming the goal 221 | + Forming the intention 222 | + Selects the action 223 | + executing the action 224 | + perceiving the state of the world (post action) 225 | + interpret the state of the world 226 | + evaluating the outcome 227 | + (implied 8th step: update their goal => did their action change what they wanted it to do) 228 | 229 | [back to top](#top) 230 | 231 | ### L6: Gulfs of Execution and Evaluation 232 | 233 | - Gulfs of Execution are on the left side of the Seven states of action 234 | + forming the intention 235 | + selecting the action 236 | + executing the action 237 | - Gulfs of Execution 238 | + perceiving the state of the world 239 | + interpret state of the world 240 | + evaluating the outcome 241 | - Gulf of Execution: Bridging 242 | + think of the push bar on a door 243 | + bad example: wordy signs on a door indicate which side of the door to push 244 | - Briding the Gulfs 245 | + Understand 246 | * users' goals 247 | * how they think about accomplishing them 248 | + Make sure likely actions are: 249 | * visible when needed 250 | * make sense 251 | + Make sure the results of actions 252 | * are visible 253 | * make sense 254 | 255 | [back to top](#top) 256 | 257 | ### L7: Design Principles 258 | 259 | - Discoverability 260 | + Discoverability is how we bridge the Gulfs of Execution and Evaluation 261 | + Users need to be able to discover 262 | * what a system can do 263 | * how to operate it 264 | + Execution: users can figure out what actions are possible 265 | + Evaluation: users can discover whether actions were successful 266 | - Supporting Discoverability 267 | + Affordances 268 | + Signifiers 269 | + Feedback 270 | + Constraints 271 | + Conceptual Models 272 | - Affordances 273 | + an "affordance" is a feature of an object or environment that indicates the possibility of action 274 | + think of a doorknob 275 | + or a button 276 | * Signifier 277 | - An indication of "what" action will occur and, in many cases, where the action can occur 278 | - think of a sign 279 | + i.e. two buttons, one green, one red; green says "start", red says "stop" 280 | + or a walking path in a field 281 | * Affordances and Signifiers: Great Together 282 | - Affordances if done well, can communicate intuitively 283 | - Signifiers are often necessary when many actions are possible 284 | - Conventions and standards can reduce need for affordance 285 | * Feedback 286 | - users need to know that the system recieved their input 287 | - users need to know what the system did with their input 288 | * Constraints 289 | - Unavailable actions should be disabled 290 | - Limit the total number of options will make selection easier 291 | * Conceptual Models 292 | - conceptual models support *simulation of future actions* 293 | + anticipate what will happen for things they haven't done yet 294 | - appropriate use of affordances, signifiers, feedback and constrains leads to formation of *accurate conceptual models* 295 | * Support Formation of Conceptual Models 296 | - the originals: 297 | + Affordances 298 | * Signifiers 299 | * Feedback 300 | * Constraints 301 | * Conceptual Models 302 | + new ones: 303 | * Consistency 304 | * Metaphors 305 | - Metaphors 306 | + folder or file => represents documents 307 | + trash carn => delete a file or folder, etc. 308 | + shopping cart => 309 | 310 | ### Section Wrap-up Notes 311 | 312 | - **Affordance**: A feature of an environment or system that, by its shape and appearance, suggests to a person that a particular action could be taken 313 | - **Signifier**: A feature of an environment or system that communicates through verbiage or imagery what will happen if an action is taken 314 | 315 | [back to top](#top) 316 | 317 | ## Design Heuristics 318 | 319 | ### L8: Heuristics for Design 320 | 321 | - From Knowledge to GUidelines 322 | + Important to understand 323 | * how people perceive 324 | * how people remember 325 | * how people act to pursue goals 326 | + How can system designs use this knowledge to improve UX? 327 | * A: "Guidelines" 328 | - Example page of guidelines for government web pages: [https://webstandards.hhs.gov/guidelines/](https://webstandards.hhs.gov/guidelines/) 329 | + one drawback to the above usability guidelines is that they aren't applicable to every site or scenario 330 | + another is that super-detailed guidelines 331 | - Guidelines 332 | + There are many out there 333 | + you could any set 334 | + Choosing guidelines: 335 | * are they well-supported and focused on user experience? 336 | * Do they cover all the important best practices? 337 | * Do they apply to your platform/situation? 338 | * Are they easy to use? 339 | - Jakob Nielsen's 10 Heuristics 340 | + "Heuristic" means "rule of thumb" 341 | * slightly more general than a "guideline" 342 | + Derived from a sustematic review of usability problems 343 | + intended to be a small, complete and usable set 344 | + able to be taught in a few hours 345 | + well-supported by theories of perception and cognition 346 | - 10 Heuristics 347 | 1. Visibility of system status 348 | 2. match between system and the real world 349 | 3. User control and freedom 350 | 4. Consistency and standards 351 | 5. Error prevention 352 | 6. Recognition rather than recall 353 | 7. Flexibility and efficiency of use 354 | 8. Aesthetic and minimalist design 355 | 9. Help users recognize, diagnose and recover from errors 356 | 10. Help and documentation 357 | 358 | [back to top](#top) 359 | 360 | ### L9: Heuristic #1: Visibility of System Status 361 | 362 | - Visibility of System Status 363 | + the system should always keep users informed about what is going on, through appropriate feedback within a reasonable time 364 | + Why? 365 | * knowing what actions are available bridges the Gulf of Execution 366 | * Knowing how the system responded bridges the Gulf of Evaluation 367 | * Echoes Norman's principles of Feedback and Constraints 368 | + It manifests in a number of ways throughout the system: 369 | * Feedback 370 | * General Availability 371 | + Feedback 372 | * simple things like underlining a link when you hover over it 373 | * If you mark conversations as "read" in Gmail, you get a little message that says that 374 | * Available actions: if you can't do a certain action but the button is there, the button is disabled 375 | + General Availability 376 | * is it busy or loading? Show a loading image 377 | * Show a progress bar if you need more time 378 | * How users react to delay: 379 | - Less than 100 milliseconds: "instantaneous" 380 | - Up to 1.0 second: tolerable but delay is noticeable 381 | - Up to 10 seconds: annoying, but willing to wait if it's worth it 382 | - More than 10 seconds: focus lost, users will move on to something else 383 | * Guidelines 384 | - strive for less than 100 ms 385 | - up to 1 second, no indicator needed 386 | - 1- 10 seconds, use a wait cursor 387 | - Over 10 seconds, complete in background 388 | 389 | 390 | [back to top](#top) 391 | 392 | ### L10: Heuristic #2: Match Between System and Real World 393 | 394 | - The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. 395 | - Why? 396 | + Take advantage of users' existing *schema* 397 | + Leverage perceived affordances and signifiers that suggest actions 398 | + Reduce difficulty of forming effective conceptual models 399 | - Language 400 | - Order of operations 401 | + create document -> write something -> save doc -> give it a name -> choose folder 402 | - Metaphor 403 | + shopping cart 404 | + file 405 | - The systems we create should match the real world as best as we can so that users can understand and use it effectively 406 | 407 | 408 | [back to top](#top) 409 | 410 | ### L11: Heuristic #3: User Control and Freedom 411 | 412 | - Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo 413 | - Why? 414 | + mistakes are inevitable 415 | + Support the 7 stages of action by allowing reformulated goals 416 | + Users employ trial and error to learn a new system 417 | - Emergency exits: 418 | + "Stop Installation" 419 | + "undo" or "redo" buttons 420 | - Users need the freedom to make mistakes and recover from their mistakes 421 | 422 | [back to top](#top) 423 | 424 | ### L12: Heuristic #4: Consistency and Standards 425 | 426 | - Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. 427 | - Why? 428 | + Leverage users' schemas => allow them to use patterns of information/systems and apply that to your system 429 | + present a coherent conceptual model 430 | - Consistency of language, layout, and behavior 431 | + "Search" vs. "Submit query" 432 | + "Save" vs. "Commit" 433 | + "Create" vs. "New..." 434 | + Example: Amazon 435 | * different items are presented in similar ways: main picture, price on the right, description below, etc. 436 | + Consistency across products 437 | * Think Google Docs Suite 438 | - Platform Standards 439 | + think of how poor FlatPak's website was (navigation in particular) 440 | 441 | 442 | [back to top](#top) 443 | 444 | ### L13: Heuristic #5: Error Prevention 445 | 446 | - Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. 447 | - Why? 448 | + mistakes are common 449 | + people don't see or read everything on the screen 450 | + people make mistakes when typing, clicking, etc. 451 | - Provide constraints 452 | + ex: enter a birthdate (if you don't state the format, you could get a lot of errors) 453 | + ex: live error messages as they are typing 454 | - Confirmation of Risky Actions 455 | + "Are you sure you want to permanently delete these items?" 456 | + prevent errors that are likely to occur 457 | 458 | 459 | [back to top](#top) 460 | 461 | ### L14: Heuristic #6: Recognition Over Recall 462 | 463 | - Minimize the user's memory load by making objects, actions and options visible. The user should not have to remember information from one part of the dialogue to another. Instruction for use of the system should be visible or easily retrievable whenever appropriate. 464 | - A familiar stimulus triggers retrieval from long-term memory 465 | - Recall forces users to: 466 | + recreate chain of associations themselves, or 467 | + forcefully learn through elaborative rehearsal 468 | - Recall will fail unless remembered actions are 469 | + frequent 470 | + Recent 471 | + Strongly associated 472 | - Direct Manipulation 473 | + direct manipulation shows all options that we'd want to do (i.e. animate an item in a powerpoint slide) 474 | - Where does recall come up? 475 | + textual commands like in a terminal window 476 | + passwords 477 | + speech UI's 478 | * Siri gives a list of things that you can ask it / "her" 479 | 480 | [back to top](#top) 481 | 482 | ### L15: Heuristic #7: Flexibility and Efficency of Use 483 | 484 | - Accelerators - unseen by the novice user - may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. 485 | - Why? 486 | + recall is bad for new/infrequent users but can be **fast** for experts 487 | + Different users have different goals, allow them to customize 488 | * but don't force them to! 489 | - Accelerators (i.e. keyboard shortcuts) 490 | - Shortcuts and Bookmarks => browsers do this often 491 | 492 | [back to top](#top) 493 | 494 | ### L16: Heuristic #8: Aesthetic and Minimalist Design 495 | 496 | - Dialogues should not contain information that is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. 497 | - Why? 498 | + visual clutter makes it harder to find and focus on desired actions 499 | + Good use of color, shape, motion, and gestalt principles guide the eye 500 | + The more there is to see, the less of it users will actually see 501 | - Google: nothing but a search bar 502 | - Use Gestalt principles for non-linear reading 503 | 504 | [back to top](#top) 505 | 506 | ### L17: Heuristic #9: Error Recovery 507 | 508 | - Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. 509 | - Why? 510 | + #9 - is a special case of 1, 2, 3 and 5 511 | + #1 - Give Feedback 512 | + #2 - Speak the users' language 513 | + #3 - Allow users to undo and escape mistakes 514 | + #5 - Prevent and detect errors 515 | 516 | [back to top](#top) 517 | 518 | ### L18: Heuristic #10: Help and Documentation 519 | 520 | - Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. 521 | - Why? 522 | + Your UI may not be as self-explanatory as you thought 523 | + Structure to support Gulf of Execution 524 | * easy to search 525 | * contain list of actions 526 | * focused on user's tasks 527 | - Contextual Help 528 | + help that is specific to the task they are trying to perform 529 | 530 | ### Random Items 531 | 532 | - Look at [http://www.webpagesthatsuck.com/](http://www.webpagesthatsuck.com/); there are some great examples of bad websites 533 | 534 | [back to top](#top) 535 | 536 | 537 | ## Heuristic Evaluation and Course Wrap-up 538 | 539 | ### L19: Heuristic Evaluation 540 | 541 | - a Heuristic Evaluation is designed to be a quick way to look at your user experience 542 | - It is an "inspection" method where you do a systematic "close read" of your user interface and then apply the heuristics to find and explain problems 543 | - Here is the basic methodology (very intuitive / not groundbreaking): 544 | + choose a set of screens/interactions for focus 545 | + step through, applying heuristics to find potential problems 546 | + Write down all violations, big and small 547 | + assess the severity of each problem 548 | + create prioritized list of problems to fix 549 | - Problem Severity: 550 | + 1 = cosmetic, no real usability impact 551 | + 2 = minor problem, fix if there is time 552 | + 3 = major problem, important to fix 553 | + 4 = catstophe, MUST fix 554 | - In the example, they list a few key parts: 555 | + Finding / Violation: what is the problem that you see 556 | + Severity: 1 - 4 557 | + Heuristic Violated: Visibility of system status 558 | + Recommendation 559 | - Prioritizing 560 | + Highlight the top 5-10 problems 561 | + Ranked in decreasing order of severity 562 | + Use heuristics to explain WHY they matter 563 | - he recommends getting multiple evaluators; each additional evaluator up to around 5 adds meaningful insight into the app and can find more "true" problems 564 | - heuristic evaluation is cheap and fast; doesn't "use up" potential users 565 | - user testing is more realistic, finds more problems, and allows you to assess other UX qualities besides just usability 566 | - CM: 567 | + if I were to do this myself, I'd need to have the 10 Heuristics on a single piece of paper with: 568 | * the general definition 569 | * key bullets breaking that down 570 | * examples of common items that violate this heuristic 571 | + After creating the rubric, I could create a spreadsheet as he has in the example with four main boxes: 572 | * Description of the issue 573 | * System Location 574 | * Heuristics Violated 575 | * Severity 576 | 577 | [back to top](#top) 578 | 579 | ### L20: Course Wrap-Up & Next Steps 580 | 581 | - If UX has four components, this course has focused on the "Usability" component 582 | + the other three are "Value", "Adoptability", "Desirability" 583 | - Books: 584 | - Don Norman: The Design of Everyday Things 585 | - Jeff Johnson: Designing with the Mind in Mind 586 | - Steve Krug: Don't Make Me Think 587 | * Value: Understanding User Needs 588 | - no magic solutions 589 | - UX research methods 590 | - Book: 591 | + Observing the User Experience 592 | * Desirability 593 | - Emotion Design 594 | - Book: 595 | + Don Normal: Emotional Design 596 | - Three levels of emotional response 597 | + visceral - fast, primitve 598 | + behavioral - based on use 599 | + reflective - based on associations 600 | + Aesthetics and Experience 601 | * Experience is an "inseparable, meaningful whole" 602 | * experience becomes relevant through remembered stories 603 | * there's more to experience than product features 604 | * recommended article 605 | - [User Experience and Experience Design](https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed/user-experience-and-experience-design) 606 | + Designing Relationships: Service Design 607 | * Book: 608 | - Service Design 609 | * products vs relationships 610 | * the "customer journey" 611 | * multiple "touchpoints" 612 | + Adopability 613 | * accessibility => how easy it for everyone to use 614 | - big area, worthy of its own course 615 | - even the subfield of web accessibility is big and evolving. 616 | - [World Wide Access: Accessible Web Design](http://www.washington.edu/doit/videos/index.php?vid=35) 617 | + Designing for Humans 618 | * understand perception and cofnition 619 | * understand design principles for usable systems 620 | 621 | 622 | [back to top](#top) 623 | 624 | 625 | 626 | 627 | 628 | 629 | 630 | 631 | 632 | 633 | 634 | 635 | 636 | 637 | 638 | 639 | 640 | 641 | 642 | 643 | 644 | 645 | 646 | 647 | 648 | 649 | 650 | 651 | 652 | 653 | 654 | 655 | 656 | 657 | 658 | 659 | 660 | 661 | 662 | 663 | 664 | 665 | -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L01-What-is-Design.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L01-What-is-Design.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L02-Design-Process-An-Overview.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L02-Design-Process-An-Overview.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L03-Framing-Design-Problems.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L03-Framing-Design-Problems.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L04-Formative-Research.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L04-Formative-Research.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L05-Introduction-to-Ideation.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L05-Introduction-to-Ideation.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L06-Sketching.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L06-Sketching.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L07-Brainstorming.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L07-Brainstorming.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L08-Personas.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L08-Personas.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L09-Scenarios.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L09-Scenarios.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L10-Storyboards.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L10-Storyboards.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L11-Design-Rationale.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/L11-Design-Rationale.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/design-customer-experience-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/design-customer-experience-process.png -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/design-in-nutshell.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/design-in-nutshell.png -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/design-thinking-101.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/design-thinking-101.png -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/design-thinking-process.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/design-thinking-process.jpeg -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/general-product-design-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/general-product-design-process.png -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/sketching-vs-prototype.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/sketching-vs-prototype.png -------------------------------------------------------------------------------- /UMI-UX-Design-From-Concept-to-Wireframe/Notes.md: -------------------------------------------------------------------------------- 1 | [Design-UX-UI Home](https://github.com/coolinmc6/design-ux-ui) 2 | 3 | 4 | # UX Design: From Concept to Wireframe 5 | 6 | ## Table of Contents 7 | 8 | - [Course Documents](https://github.com/coolinmc6/design-ux-ui/tree/master/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents) 9 | - [Course Summary and Key Take-aways](#course-summary-and-key-take-aways) 10 | + [Basic Summary](#course-summary) 11 | + [Most Interesting Parts](#my-key-takeaways) 12 | - [Course Syllabus and Learning Objectives](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#course-syllabus-and-learning-objectives) 13 | - [Introduction to the Design Process](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#introduction-to-the-design-process) 14 | + [What is Design](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l1-what-is-design) 15 | + [Design Process - An Overview](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l2-design-process---an-overview) 16 | + [Framing Design Problems](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l3-framing-design-problems) 17 | + [Formative Research](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l4-formative-research) 18 | - [Ideation](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#ideation) 19 | + [Introduction to Ideation](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l5-introdution-to-ideation) 20 | + [Sketching](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l6-sketching) 21 | + [Brainstorming](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l7-brainstorming) 22 | - [Design Constraints and Making Choices](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#design-constraints-and-making-choices) 23 | + [Personas](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l8-personas) 24 | + [Scenarios](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l9-scenarios) 25 | + [Storyboards](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l10-storyboards) 26 | + [Design Rationale](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l11-design-rationale) 27 | 28 | ## Course Summary and Key Take-aways 29 | 30 | ### Course Summary 31 | 32 | - The course opens with several definitions of design highlighting one of biggest misconceptions about design that it is NOT just what it looks like. There are several [design quotes](#design-quotes) worth taking a look at 33 | - There are three main parts of designing anything that you must understand: 34 | + Purpose: what is the function of the object? 35 | + Context: in what situations will it be used? 36 | + Constraints: what determines how this thing can be made and used? 37 | - I also really like the [core design skills](#core-design-skills) as a good framework for what a designer should be able to do 38 | + **TASK:** create a toolkit around these skills. What tools have I learned (i.e. brainstorming, sketching, etc.) that can help in each of these? Lecture 2 has a great breakdown of those items [here](#design-in-a-nutshell) 39 | - Lecture 2 shows all those items (pretty much as I want it per the task above) and reiterates a lesson I've heard in all of these lectures is that **design is iterative**. It is messy and ambiguous and you have to get used to that 40 | - [Framing Design Problems](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l3-framing-design-problems) 41 | + a design frame is what the designer considers important and will focus on when doing the work / solving the design problem 42 | + There are two main items that must be kept in mind: 43 | * **Scope**: How big is the problem you are focusing? 44 | - is this a complete change of the previous "system" or are you fixing one aspect? 45 | * **Design Space**: What can vary in how you are thinking about the problem? 46 | - what are the variables that can change per type of user or solution? 47 | - [Formative Research](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l4-formative-research) discusses how to research. It's another good list of **all** the methods used to learn about user needs, both formal and informal. 48 | - The [Ideation](#l5-introdution-to-ideation) lecture had a good explanation and introduction to the main methods of coming up with ideas. The notes on [sketching](#l6-sketching) were good and probably something I should do more but I really liked seeing IDEO's [Rules for Brainstorming](#rules-for-brainstorming) and should keep them in mind for this toolkit 49 | - I've read about [Personas](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Notes.md#l8-personas) and I would probably benefit from re-reading my notes on this. They make sense on paper but would like to do more with them. 50 | - [Scenarios](#l9-scenarios) and [Storyboards](#l10-storyboards) are different means to the same end. Storyboards provide a bit more physical context and might paint a fuller picture but it sounds like only one or the other is employed in the design process, not both. 51 | 52 | [back to top](#top) 53 | 54 | 55 | ## Course Syllabus and Learning Objectives 56 | 57 | - By the end of this course, learners will be able to: 58 | + Explain how designers approach complex problems 59 | + Describe the iterative nature of the design process and its main components 60 | + Recognize the central role of ideation and gain experience in sketching 61 | + Create personas, scenarios, and storyboards 62 | + Evaluate systematically tradeoffs of alternative ways you can design a component of a system 63 | - Design is a skill not just "knowledge"; you get better at design **by designing**. 64 | 65 | ## Introduction to the Design Process 66 | 67 | ### L1: What is Design? 68 | 69 | - Wicked problems... 70 | + are ill-defined / underspecified 71 | + don't have a right or wrong solution 72 | + are context-dependent 73 | + Don't have a clear test for solutions 74 | - "Design is how it works" - Steve Jobs 75 | - "Design is a plan for arranging elements in such a way as to best accomplish a particular purpose." - Charles Eames 76 | - **Purpose:** what is the function of this object? 77 | - "...every design problems begins with an effort to achieve fitness between two entities: the form in question and its context" - Christopher Alexander 78 | - **Context:** in what situations does this thing intend to be used? 79 | - **Constraints:** what determines how this thing can be made and used? 80 | - Design is about creating things that fulfill their purpose well while adhering to constraints 81 | - Core design skills 82 | + to frame, or reframe, the problem and the objective 83 | + to create and envision alternatives 84 | + to select from those alternatives 85 | * articulate trade-offs of other solutions, etc. 86 | + to visualize and prototype the intended solution 87 | + to synthesize a solution that brings all those together 88 | - **Interaction design** applies design skills to the creation of interfaces for computational artifacts 89 | 90 | [back to top](#top) 91 | 92 | ### L2: Design Process - An Overview 93 | 94 | - Design is not just creative genius; design is a process 95 | - Design Process (In a Nutshell) 96 | 97 | 98 | 99 | ![Design in a nutshell](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/design-in-nutshell.png) 100 | 101 | - Design is an iterative process and it is messy! Get comfortable with ambiguity 102 | 103 | [back to top](#top) 104 | 105 | ### L3: Framing Design Problems 106 | 107 | - **goal:** formulate the problem and understand important constraints a solution needs to satisfy 108 | - A frame is an active perspective that both describes and perpetually changes the situation 109 | - Frame describes aspects of the design problem the designer considers to be important and will focus on 110 | + you are trying to learn what's in and what's out 111 | + Weight Loss App example 112 | * which will behaviors will target? 113 | * Who is the population? 114 | * Would this be time-limited or ongoing? 115 | - **Scope**: How big is the problem you are trying to focus on? 116 | + Weight Loss App 117 | * Affect all behaviors? 118 | * Comprehensive weight loss support or just one part of it? 119 | - **Design Space**: what can vary in how you are thinking about the problem? 120 | + More narrowly defined: 121 | 122 | > the **Design Space** is the range of alternative ways that a design solution can work. **Design space** refers to the dimensions on which a design solution can vary: size, complexity, intended population, etc. 123 | 124 | 125 | - Designers use the notion of the design space to articulate classes of design solutions they should consider and the tradeoffs they should analyze. 126 | + Weight Loss App: 127 | * population 128 | * level of motivational readiness 129 | * weight-loss behaviors 130 | * situations where the system is used 131 | * types of technology 132 | - No design problem exists fully formed. A key job a designer is to specify the exact problem that needs to be solved 133 | - Problem framing is an **iterative process** 134 | - project timeline changes, budget gets cut, designer's understanding of the problem changes 135 | 136 | 137 | [back to top](#top) 138 | 139 | ### L4: Formative Research 140 | 141 | - **Goals:** 142 | + understand the existing context and domain 143 | + identify targets for design improvements 144 | - Methods: formal and informal 145 | + Formal Methods 146 | * interviews 147 | * surveys 148 | * participatory design grouops 149 | * systematic observations 150 | * shadowing 151 | * task analytsis 152 | * process mapping 153 | * etc. 154 | + Formal Methods are: 155 | * effective and data-rich 156 | * slow 157 | + Informal Methods 158 | * informal observations 159 | * targeted conversations with key stakeholders 160 | * Foraging on information about the domain 161 | * Asking social network for bug lists 162 | + Informal methods 163 | * tend to be quick, cheap, but you can miss important aspects of the problem (unless you are very good) 164 | - Whichever trajectory 165 | + collect a lot of stuff 166 | + put your materials together 167 | + immerse yourself in them 168 | - Finding Inspiration 169 | + "Nothing is original. Steal from anywhere that resonates with inspiration or fuels your imagination." 170 | + take notes and sketch 171 | - Bug List 172 | + find examples of other technologies that address your problem 173 | + Try them 174 | + Compile list of frictions and frustrations that you discover in those tools 175 | + Come up with ways of addressing those limitations 176 | - Other Sources of Inspiration 177 | + Tech that solves a related problem 178 | + Non-tech solutions for your problem 179 | + Your population's context, habits, culture, infrastructure 180 | + Elegant artefacts and processes 181 | + Anything else that strikes your fancy! 182 | 183 | [back to top](#top) 184 | 185 | ### Quiz 1: 186 | 187 | - Design is "compromise": 188 | + The issue is not that designers do low-quality work. It’s that most real-world design problems are complex enough that they often involve conflicting constraints — constraints that pull the design solution in different directions. A designer has to balance those conflicting demands, and this balancing usually means that some aspects of the design end up being done in a way that the designer wouldn’t have chosen if the constraints were not present. 189 | 190 | 191 | [back to top](#top) 192 | 193 | ## Ideation 194 | 195 | ### L5: Introdution to Ideation 196 | 197 | - **Goal:** Generate a lot of concepts from which you can generate a high-quality solution 198 | + large body of evidence showing that you if you start with a large set of different ideas, the final product is better 199 | - Basic Rules of Ideation 200 | + Make ideas cheap! 201 | * generate ideas as quickly as possible which ALLOWS us to quickly throw them away as well 202 | * fill in just enough details to get a sense of the idea 203 | + Generate both variations of an idea and very different ideas 204 | + Don't worry about idea quality or feasibility 205 | - **Ideation Outcome:** dozens or even hundreds of ideas 206 | - Tools for Ideation 207 | + sketching 208 | + Brainstorming 209 | + Mindmapping 210 | * concept is put in center of sheet 211 | + Timed idea generation (generate as many ideas as possible) 212 | + Generate a minimum of X ideas (i.e. 40) 213 | + The goal of this is to visualize and think about the problem in many different ways and you can use a number of tools to do that 214 | 215 | [back to top](#top) 216 | 217 | ### L6: Sketching 218 | 219 | - "Sketching is not only the archetypal activity of design. It has been thus for centuries." 220 | - Sketching is about generating and communicating ideas 221 | - Sketch Attributes 222 | + **quick** 223 | + timely 224 | + **inexpensive** 225 | + disposable 226 | + plentiful 227 | + clear vocabulary 228 | + distinct gesture 229 | + **minimal details** 230 | + appropriate level of refinement 231 | + suggest and explore 232 | + ambiguity 233 | - Sketches don't have to be beautiful to be useful 234 | - Sketch vs. Prototype Summary: 235 | 236 | ![Sketch vs. Prototype Summary](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Concept-to-Wireframe/Course-Documents/sketching-vs-prototype.png) 237 | 238 | - There are many different types of sketches 239 | + some are just for communicating sketch 240 | + **thinking sketches generate large numbers of ideas** 241 | + technical sketches are used in engineering 242 | + Presentation sketches have more polish 243 | + Emotive sketch are designed to be later stages of design 244 | - Recommends getting a design notebook 245 | 246 | [back to top](#top) 247 | 248 | ### L7: Brainstorming 249 | 250 | - IDEO Rules for Brainstorming 251 | + Have a clear problem statement 252 | + Have clear rules (i.e. go for quantity) 253 | + Number the ideas 254 | + Build on ideas 255 | + Make ideas visible 256 | + Get physical (sketch, mind-map, make, act out) 257 | - Traps to Avoid 258 | + criticizing ideas; 259 | + Rule: don't criticize ideas, every idea is valid 260 | + Taking turns (or trying to make the process less messy) 261 | * Rule: let it be a bit chaotic, have people jump in when they have an idea 262 | + Getting sucked into developing an idea in depth 263 | * Rule: don't go too far down one idea 264 | + Going too far on tangent 265 | * Rule: don't go off-topic / off-scope 266 | + Stopping to do research 267 | * Rule: keep going for more ideas 268 | - How to Keep Moving 269 | + Brainstorm solutions to pain points 270 | + Determine steps in process, brainstorm on those 271 | + Identify loci for innovation 272 | + Identify solutions for different users 273 | + Have a facilitator 274 | - Brainstorming Facilitator 275 | + Make sure people don't go on excessive tangents 276 | + Notice when session participants feel stuck or have hit a dead end, redirect session by bringing up a new topic 277 | + To keep in check the critiquing of ideas 278 | + Prevent participants from diving too deeply into the ideas 279 | - Rapid Brainstorming with Structure Example 280 | + I. Brainstorm a list of 10 objects associated with snow and cold weather 281 | * write these objects along the top of a large piece of paper 282 | + II. Brainstorm 10 controls or techniques for controlling those objects 283 | * Write these objects along the left side of the paper 284 | + Populate as much of the matrix as you can in 10 minutes 285 | + Don't worry about whether the idea is good or not 286 | - Reward yourself after brainstorming; it's very hard 287 | 288 | [back to top](#top) 289 | 290 | ## Design Constraints and Making Choices 291 | 292 | ### L8: Personas 293 | 294 | - The purpose of personas is to build concrete image of users that designers can design toward 295 | - They are based on all the research, skecthing, conversations, etc. 296 | - Personas are fictional characters that represent key types of technology's intended users that were discovered through formative work. 297 | - Key Characteristics of Personas 298 | + Based on data 299 | * they are based on formative research 300 | + Embody goals, traits, behaviors and context that could influence if and how the technology is used 301 | + Represent distinct classes of intended users 302 | - Persona Example 303 | + Picture 304 | + Demographics: age, occupation, location, life stage (married? children?) 305 | + Goals and Motivators 306 | + goals related to technology and motivators the could be leveraged or act as barriers 307 | * career-oriented? being a parent? novelty (unique about her), etc. 308 | + Behaviors and Constraints 309 | * routines an dother behaviors (e.g. work practices) that create opportunities or barriers for technology 310 | * weather? access to technology? personal traits (i.e. need structure / routine), hectic schedule? 311 | + Context 312 | * living and working environments and other aspects of physical and social context that may affect technology use 313 | - You would be constantly checking your design ideas to ask: would this work for this Mary? Would this work for John? 314 | - Benefits of Personas 315 | + personalize and summarize a lot of data 316 | + Provide a mental shortcut for design considerations 317 | + Allow discussion of and agreement on who intended users are 318 | + Easy to understand by non-designers 319 | + Help check tendencies to design for oneself or the "elastic user" 320 | - Some final considerations 321 | + personas should feel "real" - they should accurately summarize available data 322 | + They should focus on common rather than idiosyncratic traits/characteristics 323 | + Content should be relevant 324 | * family situation might not be relevant for design of a workplace technology 325 | 326 | [back to top](#top) 327 | 328 | ### L9: Scenarios 329 | 330 | - Scenarios are short stories about specific users who are using technology being designed to accomplish specific goals in a specific context 331 | - Scenarios bridge findings about user needs and ideas about how a technology may support those needs 332 | - Why use scenarios? 333 | + support reflection during the design process 334 | + open-ended and easily revised 335 | + anchor design discussion 336 | - Elements of a Scenario: 337 | + **Setting**: situation (state of the system, context of use) in which activity occurs 338 | + **Agent**(s): people performing the activity described in the scenario 339 | + **Goals**: objectives agents are trying to accomplish 340 | + **Actions**: activities that agents do to accomplish their goals 341 | + **Events**: things that happen to users while doing the activities in the scenario 342 | - Types of Scenarios 343 | + problem scenarios: describe features of the current situation 344 | * the users' current problem and what they are trying to accomplish 345 | + goal or task-based scenarios: what the user wants to do 346 | + activity scenarios: transformt he current practice into new design features 347 | + full scale task scenarios: steps to accomplish a task 348 | + information scenarios: how users perceive, interpret and make sense of information 349 | + interaction scenarios: physical actions and system responses that respond to users' tasks 350 | + When to use 351 | * problem scenarios are typically done first to understand the problem they are trying to sovle 352 | - Some final considerations 353 | + you don't need to be a great writer; provide enough detail to understand the scenario 354 | + scenarios should be quick; more rough scenarios 355 | + scenarios are process artifacts. Do only as much as is helpful 356 | + scenarios can help uncover unwanted technology effects 357 | 358 | 359 | [back to top](#top) 360 | 361 | ### L10: Storyboards 362 | 363 | - A storyboard is a series of sketches that visually conveys how a user engages in an activity that involves the technology that is being developed. 364 | - Why storyboards (if you have scenarios)? 365 | + they help you think more deeply about: 366 | * environments where the system is used 367 | * physical constraints 368 | * user's motivation and emotion 369 | * relationships among multiple people 370 | - Elements of a Storyboard 371 | + Zoom: how wide/narrow is the focus of the frame? 372 | + Angle: from whose point of view is the content in the frame? User's? Observer's? 373 | + Detail: what is the frame focused on? 374 | + Emotion: what emotion is the user expressing? 375 | + Setting: Where does the action take place? 376 | - Storyboarding considerations 377 | + How many panels are needed? 378 | + What interactions will be represented? 379 | + How will time be represented? 380 | + How will the user ("character") fit? 381 | + What text will be used? 382 | - Some final thoughts 383 | + You don't need to be a great artist to draw useful storboards 384 | + storyboarding quickly allows you create more storyboards 385 | + storyboards most helpful for conveying physical environment, emotion, and relationships 386 | + Play to your strengths - often either a scenario OR a storyboard will work 387 | 388 | [back to top](#top) 389 | 390 | ### L11: Design Rationale 391 | 392 | - Design rationale is articulation and analysis of tradeoffs of different alternatives to guide design 393 | - Goals: to understand the design options, their pros and cons, and to make principled decisions about which design options to pursue 394 | - Questions, Options, Criteria 395 | + A feature is represented by multiple possible options which answer a particular question 396 | + Criteria help articulate their tradeoffs and guide the choice of which option(s) to go with 397 | - Questions: 398 | + provide structure to the design space 399 | + Help uncover and define alternatives 400 | - Options 401 | + Different potential design answers to the same question 402 | * e.g. How should consumed food be entered into the food log? 403 | - Criteria 404 | + Required and desirable properties the design should satisfy 405 | + Differ in importance and generality 406 | + Help determine reasons for decisions 407 | - Sources of Criteria 408 | + Formative work with target users 409 | + Usability broadly construed 410 | * integration with daily routines, privacy, social acceptability, user expectations, etc. 411 | + Previous studies 412 | + Behaviorial studies 413 | + Requirements from other parts of the design 414 | - Things to Consider 415 | + There might not be one clear answer 416 | + It's important to know the most important criteria 417 | + A design decision can affect many other aspects of the project 418 | + Empirical data (from surveys, focus groups, small studies) can inform design decisions 419 | - SUmmary 420 | + deciding which option to pursue is a key design activity 421 | + design decisions need to be intentional and reasoned 422 | + QOC (Question-Option-Criteria) enables designers to make decisions in a systematic way 423 | 424 | [back to top](#top) -------------------------------------------------------------------------------- /UMI-UX-Design-From-Wireframe-to-Prototype/Course-Documents/L01-Course-Introduction.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Wireframe-to-Prototype/Course-Documents/L01-Course-Introduction.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Wireframe-to-Prototype/Course-Documents/L02-Elements-of-User-Interaction-Data-Input.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Wireframe-to-Prototype/Course-Documents/L02-Elements-of-User-Interaction-Data-Input.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Wireframe-to-Prototype/Course-Documents/L03-Elements-of-User-Interaction-Output-State-Mode.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Wireframe-to-Prototype/Course-Documents/L03-Elements-of-User-Interaction-Output-State-Mode.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Wireframe-to-Prototype/Course-Documents/L04-Introduction-to-Prototyping.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Wireframe-to-Prototype/Course-Documents/L04-Introduction-to-Prototyping.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Wireframe-to-Prototype/Course-Documents/L05-Wireframes.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-UX-Design-From-Wireframe-to-Prototype/Course-Documents/L05-Wireframes.pdf -------------------------------------------------------------------------------- /UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md: -------------------------------------------------------------------------------- 1 | [Design-UX-UI Home](https://github.com/coolinmc6/design-ux-ui) 2 | 3 | 4 | # UX Design: From Wireframe to Prototype 5 | 6 | ## Table of Contents 7 | 8 | - [Course Documents](https://github.com/coolinmc6/design-ux-ui/tree/master/UMI-UX-Design-From-Wireframe-to-Prototype/Course-Documents) 9 | - [Course Summary and Key Take-aways](#course-summary-and-key-take-aways) 10 | + [Basic Summary](#course-summary) 11 | + [Most Interesting Parts](#my-key-takeaways) 12 | - [Course Syllabus](#course-syllabus-and-learning-objectives) 13 | - [Building Blocks of User Interaction](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#building-blocks-of-user-interaction) 14 | + [Course Introduction](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#l1-course-introduction) 15 | + [Elements of User Interaction: Data Input](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#l2-elements-of-user-interaction-data-input) 16 | + [Elements of User Interaction: Output, State, and Mode](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#l3-elements-of-user-interaction-output-state-and-mode) 17 | + [Introduction to Prototyping](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#l4-introduction-to-prototyping) 18 | - [Low to Hi-Fidelity Prototyping](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#low-to-hi-fidelity-prototyping) 19 | + [Wireframes](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#l5-wireframes) 20 | + [Low-Fidelity Interactive Prototypes](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#l6-low-fidelity-interactive-prototypes) 21 | + [Testing Lo-Fi Prototypes](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#l7-testing-lo-fi-prototypes) 22 | + [Adding Realism to Prototypes](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#l8-adding-realism-to-prototypes) 23 | - [Conceptual Issues in Prototyping and Design](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#conceptual-issues-in-prototyping-and-design) 24 | + [Key Design Concepts](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-UX-Design-From-Wireframe-to-Prototype/Notes.md#l9-key-design-concepts) 25 | 26 | ## Course Summary and Key Take-aways 27 | 28 | ### Course Summary 29 | 30 | ### My Key Takeaways 31 | 32 | [back to top](#top) 33 | 34 | ## Course Syllabus and Learning Objectives 35 | 36 | - Learning Objectives: 37 | + Analyze factors that influence the design of user input and feedback in an interactive system 38 | + Describe different types of prototype, and what kinds of questions each type of prototype is intended to answer 39 | + Create and evaluate low-fidelity prototypes 40 | + Recognize the importance of good choice of defaults 41 | + Reason critically about the broader impacts of the systems that they are designing 42 | 43 | [back to top](#top) 44 | 45 | ## Building Blocks of User Interaction 46 | 47 | ### L1: Course Introduction 48 | 49 | - Prototyping can be wireframes, lo-fi prototypes, mock-ups, mid-fi prototypes 50 | - Prototyping translates findings from formative work into concrete designs that can be tested, revised, and refined prior to implementation of the final system 51 | 52 | [back to top](#top) 53 | 54 | ### L2: Elements of User Interaction: Data Input 55 | 56 | - Input: data that needs to be entered into the program to enable it to perform desired tasks 57 | - Two types of input: 58 | + user-entered input 59 | * GUI elements => buttons, icons, menus, switches 60 | * Self-report data => free-text, structured forms, voice input, taking a picture 61 | + passive input 62 | * sensor readings => location, camera, microphone, accelerometer 63 | * Data from other applications => calendar, pictures, health data 64 | * Information from internet => web app data (FitBit, Yelp, etc.), Weather, RSS feeds 65 | - Input Design Considerations 66 | + what granularity of data is needed? 67 | + When / how often is the data needed? 68 | + In what state is the user when input is needed? (Driving? loud environment?) 69 | + what is the value vs. the burden of obtaining the data 70 | - Consequences of Input Design 71 | + format, granularity, and frequency of input set limits on what application can do 72 | + User experience greatly affected by input design 73 | 74 | [back to top](#top) 75 | 76 | ### L3: Elements of User Interaction: Output, State, and Mode 77 | 78 | - Output: information that the system presents to the user in order to accomplish its indended funciton 79 | - Output structure: the format in which it is presented 80 | - Output content: what information is presented 81 | - Output Structure 82 | + Modality 83 | * visual (screen-based, ambient) 84 | * Audio 85 | * Haptic 86 | + Format 87 | * Number 88 | * text 89 | * list 90 | * graph 91 | * push notification 92 | + Location 93 | * in-app 94 | * wearable 95 | * phone lock screen 96 | - Output Design Considerations 97 | + What exactly does the user need to know to perform the task? 98 | + When/how often will the user interact with the information? 99 | + In what state will the user be when presented with the information? 100 | + What is the user's current knowledge base? 101 | - State: current values of system inputs and the set of rules that determine what kind of output the system will produce 102 | - Mode: element of state, usually user-controllable, that consistently determines how information is presented 103 | + sustem-wide modes: ringer on/off, airplane mode, do not disturb, night shift 104 | - Summary 105 | + UX design involves designing inputs, outputs, and rules that translate inputs to desired outputs 106 | + Design of both inputs and outputs must consider when, where, and how user will need to interact with the system 107 | + Visibility of state help users understand why the system behaves the way it does 108 | 109 | 110 | [back to top](#top) 111 | 112 | ### L4: Introduction to Prototyping 113 | 114 | - Interaction design prototype: a representation of a design, made before the final solution exists 115 | - Why Prototype? 116 | + you often don't know exactly how the system should work 117 | + engineering and software development are expensive and time-consuming 118 | - Prototyping enables testing of and receiving feedback on: 119 | + overall design concepts 120 | + functionality of different components of a system 121 | + user interactions 122 | + layouts 123 | + fine-grain design details like fonts and color schemes 124 | - Each protoype is intended to answer one or more questions to help designers make decisions needed to advance their design 125 | - Types of Prototype 126 | + storyboard 127 | + sketch 128 | + wireframe - visual representation of individual screens of the system 129 | + interactive prototype - captures multiple states of a design, transitions among them 130 | - Prototype Fidelity 131 | + more polished prototypes make users feel like it's already set in stone and that they are commenting on smaller things like font sizes, colors, etc. 132 | - Prototyping maximizes the number of times you get to revise and refine your design before committing to code 133 | 134 | [back to top](#top) 135 | 136 | ## Low to Hi-Fidelity Prototyping 137 | 138 | ### L5: Wireframes 139 | 140 | - Wireframe: a visual representation of the screens of an interactive application that shows layout, types of information that are displayed, and elements of pointer-based navigation 141 | - Questions Wireframes can Answer 142 | + Do screens capture right chunks of system functionality? 143 | + Are the components of a wireframe the right things to have on a single screen? 144 | + Does the screen capture the right way those components should be presented to the user? 145 | + Does the overall layout of components make sense? 146 | + Do screens provide the right navigational elements? 147 | - Questions Wireframes Do Not Answer 148 | + What is the state required to generate this output? 149 | + How should content be ordered? 150 | + How does the user transition among multiple screens? 151 | + What is the right visual design for the screen? 152 | + What non-visual output is the system producing? 153 | - How to Wireframe 154 | + sketching on pen and paper 155 | + Desktop and Web Apps 156 | * Balsamiq 157 | - When to Create Wireframes? 158 | + When the designer understands a chunk of functionality and wants to get feedback 159 | + When there are several ways somethign can be presented to users and the designer needs to choose among them 160 | + When developers need to start planning system backend 161 | - Summary 162 | + wireframes are basic building blocks of UX prototypes 163 | + they can test early concepts of functionality, rpesentation of interactive components, and layout 164 | + They support gathering of feedback before full system has been thought through 165 | + They are fast to create and cheap to discard 166 | - 167 | 168 | [back to top](#top) 169 | 170 | ### L6: Low-Fidelity Interactive Prototypes 171 | 172 | [back to top](#top) 173 | 174 | ### L7: Testing Lo-fi Prototypes 175 | 176 | [back to top](#top) 177 | 178 | ### L8: Adding Realism to Prototypes 179 | 180 | [back to top](#top) 181 | 182 | ## Conceptual Issues in Prototyping and Design 183 | 184 | ### L9: Key Design Concepts 185 | 186 | [back to top](#top) 187 | 188 | ### L10: Defaults 189 | 190 | [back to top](#top) 191 | 192 | ### L11: Reflective Design 193 | 194 | [back to top](#top) 195 | 196 | ### L12: New Direction in UX Design 197 | 198 | [back to top](#top) -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L01-Introduction-to-User-Needs-Assessment.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L01-Introduction-to-User-Needs-Assessment.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L02-Overview-of-Qualitative-Research.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L02-Overview-of-Qualitative-Research.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L03-User-Needs-Assessment-Mini-Project.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L03-User-Needs-Assessment-Mini-Project.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L04-Semi-Structured-Interviews.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L04-Semi-Structured-Interviews.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L05-Components-of-an-Interview-Protocol.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L05-Components-of-an-Interview-Protocol.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L06-Good-Practices-for-Interview-Protocols.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L06-Good-Practices-for-Interview-Protocols.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L07-Tips-For-Interviewing.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L07-Tips-For-Interviewing.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L08-Observing-Users.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L08-Observing-Users.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L09-Extracting-Data-From-Interview.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L09-Extracting-Data-From-Interview.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L10-Analyzing-Qualitative-Data.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L10-Analyzing-Qualitative-Data.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L11-Affinity-Walls.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L11-Affinity-Walls.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L12-Variations-on-User-Needs-Assessments.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L12-Variations-on-User-Needs-Assessments.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Course-Documents/L13-Conclusion.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/UMI-Understanding-User-Needs/Course-Documents/L13-Conclusion.pdf -------------------------------------------------------------------------------- /UMI-Understanding-User-Needs/Notes.md: -------------------------------------------------------------------------------- 1 | [Design-UX-UI Home](https://github.com/coolinmc6/design-ux-ui) 2 | 3 | 4 | # Understanding User Needs 5 | 6 | ## Table of Contents 7 | 8 | - [Course Documents](https://github.com/coolinmc6/design-ux-ui/tree/master/UMI-Understanding-User-Needs/Course-Documents) 9 | - [Course Summary and Key Take-aways](#course-summary-and-key-take-aways) 10 | + [Basic Summary](#course-summary) 11 | - [Introduction and Qualitative Research Overview](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#introduction-and-qualitative-research-overview) 12 | + [Introduction to User Needs Assessment](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l1-introduction-to-user-needs-assessment) 13 | + [Overview of Qualitative Research](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l2-overview-of-qualitative-research) 14 | - [Interview Protocols](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#interview-protocols) 15 | + [Semi-Structured Interviews](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l4-semi-structured-interviews) 16 | + [Components of an Interview Protocol](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l5-components-of-an-interview-protocol) 17 | + [Good Practices for Interview Protocols](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l6-good-practices-for-interview-protocols) 18 | + [Interview Protocol Template](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#interview-protocol-template) 19 | - [Interviews, Observations, and Data Extraction](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#interviews-observations-and-data-extraction) 20 | + [Tips for Interviewing](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l7-tips-for-interviewing) 21 | + [Observing Users](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l8-observing-users) 22 | + [Extracting Data from Interview](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l9-extracting-data-from-interview) 23 | - [Affinity Walls and Analysis](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#affinity-walls-and-analysis) 24 | + [Analyzing Qualitative Data](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l10-analyzing-qualitative-data) 25 | + [Affinity Walls](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l11-affinity-walls) 26 | 27 | ## Course Summary and Key Take-aways 28 | 29 | ### Course Summary 30 | 31 | - There are a number of reason you'd do a user needs assessment but it's generally because you want to understand: 32 | + **why** people want to use a product/service 33 | + **how** people actually use product/service 34 | + **see** what people like/dislike about a product/service 35 | + **hear what else** people might want 36 | - User **needs** can be actual needs, wants, preferences, quirks, etc. 37 | - Qualitative research is non-numerical, direct interaction with people and context, and not designed to be considered aggregate, large-scale descriptions of user behavior 38 | - This course focused on [semi-structured interviews](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l4-semi-structured-interviews) with a good chunk feeling very intuitive. 39 | - There is a good section on [interview protocols](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l5-components-of-an-interview-protocol) but feels very intuitive. It feels like this information could be condensed into a good checklist / cheat sheet of items to do before an interview. 40 | - Some of the best tips on conducting an interview: 41 | + Ask open-ended questions to really engage the user 42 | + Don't be leading them to a certain place and don't judge! Users need to feel that the system is being tested, not their intelligence 43 | + Closed-ended questions aren't great 44 | + Overly abstract or generalized (i.e. "what do you normally do when..."); you want to be concrete 45 | + **Be Prepared.** In general, being prepared and understanding who you're interviewing and having your questions ready will go a long way (again, not rocket science but good to remember) 46 | - Post-interview, it's best to take notes immediately. The idea behind [affinity notes](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l9-extracting-data-from-interview) and the [affinity wall](https://github.com/coolinmc6/design-ux-ui/blob/master/UMI-Understanding-User-Needs/Notes.md#l11-affinity-walls) is really cool. 47 | - The short slide about qualitative data and learning was interesting: 48 | + You can condense information by clustering, sorting, finding patterns, and relating things to each other 49 | + Condensing information *is* understanding 50 | + Understanding *is* intelligence 51 | 52 | [back to top](#top) 53 | 54 | ## Introduction and Qualitative Research Overview 55 | 56 | ### L1: Introduction to User Needs Assessment 57 | 58 | - Why do a user needs assessment? 59 | + To understand why people would want to use a product or service 60 | + To learn how people actually use or don't use a product or service 61 | + To see what people like or dislike about a product or service 62 | + To hear what *else* people might want from a product or service 63 | - When to do a user needs assessment? 64 | + Before an design phase 65 | * before designing something new 66 | * before a re-design 67 | + Any time questions or problems arise? 68 | * What causes users to want our service? 69 | * Why don't customers go beyond the home page? 70 | * What frustrates users of our product? 71 | * How could we improve the client's experience? 72 | - "Needs" are not always urgent 73 | + Origin of "needs assessment" 74 | * 1960's 75 | * Roger Kaufman 76 | + In UX, "needs" = needs, wants, preferences, quirks 77 | * often focused on a product or service 78 | * pros and cons to taking a broader view 79 | - Course Focus: Qualitative Research 80 | + Methodologies taught in this course: 81 | * Interviews 82 | * Observations 83 | * Affinity diagrams 84 | + Strengths of qualitative research: 85 | * in-depth 86 | * broad range 87 | * hypothesis generation 88 | * causal explanations 89 | - What this Course Does NOT Cover 90 | + Other methodologies like: 91 | * work models 92 | * personals 93 | * market research 94 | * surveys 95 | * log analysis 96 | * document analysis 97 | 98 | ### L2: Overview of Qualitative Research 99 | 100 | - Quantitative research helps to understand... 101 | + overall trends 102 | + existing product or service 103 | + issues you can anticipate 104 | - It is less useful for... 105 | + detailed understanding 106 | + new possibilities 107 | + unanticipated 108 | - Qualitative Research 109 | + Characterized by... 110 | * non-numerical data 111 | * direct interaction with people and contexts 112 | * richness and detail 113 | + Strengths of qualitative research 114 | * in-depth 115 | * broad range 116 | * hypothesis generation 117 | * causal explanations 118 | - Qualitative Vs. Quantitative: 119 | + Qualitative research generates hypotheses that can be verified with quantitative research. 120 | + Qualitative research offers potential explanations for outcomes from quantitative research. 121 | + Qualitative research tends to provide close-up, in-depth description while quantitative research tends to provide aggregate, large-scale description. 122 | - Data gathering: 123 | + **interviews** 124 | + **field oservations** 125 | + participant observations 126 | + focus groups 127 | - Data analysis 128 | + Coding 129 | + content analytsis 130 | + **thematic analysis** 131 | + **recursive abstraction** 132 | **bold:** focus for this course 133 | 134 | - Quatitative Research Caveats 135 | + not best for questions such as: 136 | * What proportion of users do X? 137 | * Would usage increase if we did Y instead of Z 138 | * Does program V cause effect W? 139 | + Weaknesses 140 | * no numerical data or analysis 141 | * relative comparisons 142 | + Qualitative Research => you are trying to get the rich detail of particular uses 143 | 144 | ### L3: User Needs Assessment: Mini-Project 145 | 146 | - I won't be doing this 147 | 148 | 149 | 150 | [back to top](#top) 151 | 152 | ## Interview Protocols 153 | 154 | ### L4: Semi-Structured Interviews 155 | 156 | - Types of Interviews 157 | + Group vs. **Individual** 158 | + Remote vs **In-person** 159 | + Degree of structure 160 | * structured 161 | * **semi-structured** 162 | * unstructured 163 | - Semi-structured -> balancing what you know about the project but more free-form conversation 164 | + balance between: 165 | * researcher's interests and focus 166 | * open, free-form discussion 167 | + There is often a script or interview protocol 168 | + conversational style 169 | + expect to go OFF-script 170 | - Interviews for Needs Assessment 171 | + Who 172 | * user / potential user 173 | * "typical" member of the group 174 | + Where 175 | * where the participant normally uses product or service (or might do so) 176 | * where participant feels comfortable 177 | + When 178 | * scheduled in advance 179 | * mutually convenient time 180 | * when participant normally uses the product or service 181 | 182 | [back to top](#top) 183 | 184 | ### L5: Components of an Interview Protocol 185 | 186 | - Components of an Interview Protocol 187 | + Overarching question 188 | + Introduction 189 | + Main Interview* 190 | * background / warm-up questions 191 | * core questions 192 | + Observation* 193 | * think-aloud protocol 194 | * observation questions 195 | + Conclusion 196 | + * => one set for every type of interview participant 197 | - Overarching Question 198 | + this is the big question you are trying to answer 199 | + keep it in mind throughout protocol development and actual interview 200 | + you will not necessarily ask the interview participant this question directly 201 | - Introduction 202 | + script for you to explain process to interview participant: 203 | * self-intro 204 | * goals of interview 205 | * duration 206 | * overview of components 207 | * confidentiality 208 | * voluntary 209 | * permissions => if necessary (waiver, release, audio recording release, etc.) 210 | - Main Interview 211 | + Background / warm-up questions 212 | * short 213 | * simple 214 | * close-ended 215 | + Core questions 216 | * open-ended 217 | * conversational 218 | * focused on overarching question 219 | - Observation 220 | + Think-aloud protocol 221 | * encourage participant to verbally explain what they are thinking and doing 222 | * awkward at first but it gets easier 223 | + Observation questions 224 | * prompts to perform tasks 225 | * questions you can anticipate 226 | * focused on overarching questions 227 | - Conclusion 228 | + script for the end of the interview and observation: 229 | * "anything you'd like to add?" 230 | * Thank you 231 | * Follow-up plans 232 | - additional questions 233 | - report back 234 | * Your contact information 235 | * "Any questions?" 236 | * Thank you, again! 237 | - Note 238 | + these are guidlines; no hard rules 239 | + most important: interview ethics 240 | + second most important: is your key question being answered? 241 | 242 | [back to top](#top) 243 | 244 | ### L6: Good Practices for Interview Protocols 245 | 246 | - Interviewing as Science and Art 247 | + Preparation 248 | * interview participant background 249 | * topic background 250 | * interview protocol 251 | * overarching question 252 | + Improvisation 253 | * rapport with interview participant 254 | * attention to the unexpected 255 | * unscripted questions 256 | * focus on overarching question 257 | - Good Questions 258 | + Open-ended 259 | * why did you... 260 | * How did you go about... 261 | * Can you tell me about... 262 | * Why do you think that is? 263 | * How did you handle that situation? 264 | + ask questions in which you really engage the user to tell you as much as they can about the situation 265 | + specific, concrete 266 | * "tell me about the last time that you did..." 267 | + Non-leading, judgment free 268 | * what option do you prefer? 269 | * What do you think was the reason for that? 270 | * How did you try to address the problem? 271 | + Not So Good Questions 272 | + Closed-ended 273 | * Do you like X? 274 | * How many times a week do you? 275 | * What is your favorite...? 276 | * sometimes they are appropriate but they shouldn't dominate the protocol 277 | + Abstract, generalized 278 | * what do you normally do when...? 279 | * what is the typical way in which? 280 | * Thesea ren't good because humans aren't good at accurately describing what they do or have done. 281 | + Leading, judgmental 282 | * Do you prefer X over Y? 283 | * Was it because of a bad process that the task was difficult? 284 | * Why didn't you use a feature Z? 285 | - Organization and Flow 286 | + Cluster related questions together 287 | + Within each cluster, arrange them in a meaningful order: 288 | * chronological 289 | * narrative 290 | * broad to narrow, or narrow to broad 291 | + Arrange clusters in a meaningful order 292 | + Save any sensitive questions for the end 293 | - Follow-up Questions 294 | + Under each core question, add follow-up questions 295 | * use bulleted list 296 | + Follow-up question types: 297 | * Generic: "Why?" "How did that happen?" "Tell me more." 298 | * Prompts for specific issues: "Did you think about X? or Y?" 299 | * Repetition: "Could you tell me about another time..." 300 | + Think through the order of these, as well 301 | + You may not ask all of these follow-ups 302 | - Final thoughts 303 | + goal of protocol 304 | * preparation 305 | * guide during interview 306 | + Memorize the overall flow of the protocol 307 | + You will not read protocol questions one after the other 308 | 309 | [back to top](#top) 310 | 311 | ### Interview Protocol Template 312 | 313 | This interview protocol was developed for a 15-minute interview with a user of GPS mapping applications, seeking to understand unusual or unexpected things about their usage habits. 314 | 315 | #### Protocol 316 | ##### [Overarching Question] 317 | 318 | What unusual or unexpected uses of GPS does the participant make when navigating from one place to another, especially in the context of informing new or improved GPS features? 319 | 320 | ##### [Introduction] 321 | 322 | Hi, my name is Kentaro Toyama, and I’m here to understand better how you use GPS technology, particularly for navigating from one point to another. This interview will take about 10-15 minutes, during which time we’ll go through some questions. Throughout, I’d like you to treat me as if you’re describing the situation to someone who isn’t familiar with GPS devices. I’m here to learn from you. 323 | 324 | A couple of things before we start. To the extent possible, I will take your comments to be confidential. My research team and I will aggregate all the comments from several interviews we’re conducting so that your comments are not easily traced to you. If we quote you in our final report, we will do so without identifying your name or specific role. If there’s anything you really don’t want on the record, even if it’s anonymized, please let me know that, too. Also, this interview is entirely voluntary on your part – if for any reason you want to stop, please let me know. We can end the interview at that point with no repercussions for you of any kind. I can also throw out anything you’ve told me until that point. 325 | 326 | Do you have any questions for me? All right, then, let’s proceed. 327 | 328 | ##### [Once the interview gets underway…] 329 | 330 | Oh, and by the way, do you mind if I take an audio recording? This is just so that I don’t miss anything – no one other than the research team will have access to the recording. Thanks. 331 | 332 | ##### [Warm up] 333 | 334 | How often do you use GPS for navigating? 335 | 336 | In general, are you happy with GPS technologies? 337 | 338 | ##### [Recent use of GPS] 339 | 340 | I’d like you to think back to the most recent time when you used a GPS to navigate from one place to another. Can you tell me a bit about that trip? 341 | 342 | ##### [Follow up, if they don’t include in their response] 343 | 344 | 1. When did the trip take place? From where to where did you go? Roughly how long was the trip? 345 | 1. When exactly did you turn the GPS on? 346 | 1. How did you input the destination location? [E.g., by address, by landmark, etc.] 347 | 1. Did you have to interact with the GPS once you set the destination, and if so, when and why? 348 | 1. Did you have other passengers, and did any help with navigation? 349 | 1. Do you remember turning the GPS off, and if so when was that? 350 | 1. Did anything unusual happen on that trip? 351 | 1. Would you say that that was a typical trip? If not, what was unusual about it? 352 | 353 | [Repeat above, for other trips, if fruitful.] 354 | 355 | ##### [Unusual trip – if nothing interesting comes up above] 356 | 357 | Now, I’d like you to think about a recent trip that was unusual or uncommon for you. For example, if you were on vacation, or in an accident, or part of a group of drivers going to the same location, and so on. 358 | 359 | - Can you think of anything like that? 360 | - What made the trip unusual? 361 | - Did you use a GPS device? And if so, did the unusual nature of the trip change how you used the GPS? 362 | - Who was in the car with you, and did they help with navigation? 363 | 364 | ##### [Other questions] 365 | 366 | One of the things I’m most interested in are situations under which the GPS is used in an unusual way. Can you think of any instances when you used the GPS in a way that isn’t typical? 367 | 368 | - [Use follow-up questions from above.] 369 | - Is there anything else that might be relevant – unusual uses of GPS, for example? 370 | 371 | ##### [Conclusion] 372 | 373 | Thank you – those are all the questions I have for you. If anything else occurs to you after I leave, please don’t hesitate to let me know by email. I may be in touch with you again to ask a few follow-up questions. If you’d like, I can send a version of the report that we’ll write based on this interview. Do you have any questions? Thanks again! 374 | 375 | 376 | [back to top](#top) 377 | 378 | ## Interviews, Observations, and Data Extraction 379 | 380 | ### Sample Interview 381 | 382 | 383 | [back to top](#top) 384 | 385 | ### L7: Tips for Interviewing 386 | 387 | - Memorize the overflow / prep for the interview 388 | + participant background 389 | + interview protocol 390 | - Rapport with Interview 391 | + make them feel comfortable 392 | + do not jump right in 393 | + start with small talk 394 | + Adopt a Learning Mindset 395 | * they are the expert 396 | * Observe 397 | * Adapt 398 | * Listen 399 | * **They** are the expert in their experience; you need to understand what they do and how they have tried to solve the problem 400 | + Follow Interesting Threads 401 | * Advanced prep pays off but willing to abandon the script if needed 402 | * Ask follow-up questions until satisfied 403 | * Listen for unexpected but relevant things 404 | - improvise unscripted follow-up questions 405 | + Note-taking 406 | * take notes with pen and paper; devices can create a barrier 407 | * print a list of questions with gaps for your notes 408 | + Write down: 409 | * key points in short phrases 410 | * things that audio recording can't capture (like facial expressions, physical context) 411 | * Follow-up questions 412 | + Practice Interviewing 413 | * maintain conversational tone 414 | * keep overarching question in mind 415 | * Be curious! 416 | 417 | [back to top](#top) 418 | 419 | ### L8: Observing Users 420 | 421 | - Observation Review 422 | + think aloud protocol 423 | + observation questions 424 | - Observation starts even before the interview 425 | - Observation Tips 426 | + Ask participant to perform relevant tasks 427 | + Think Aloud Protocol 428 | * what are you doing onw? why are you doing that? 429 | + Take good notes on think aloud protocol 430 | * what are the unexpected things? 431 | - pauses 432 | - missteps / multiple steps 433 | - detours 434 | - intentional detours 435 | * Ask questions if you don't understand the motivation for something 436 | - Similar to interviews 437 | + maintain conversational tone 438 | + keep overarching question in mind 439 | + be curious 440 | + practice it 441 | 442 | 443 | [back to top](#top) 444 | 445 | ### Sample Think-Aloud Protocol 446 | 447 | - watched 448 | 449 | [back to top](#top) 450 | 451 | ### L9: Extracting Data from Interview 452 | 453 | - From Notes to Qualitative Data 454 | + As soon as possible after an interview, write down affinity notes 455 | * an affinity note is: 456 | - a sticky note 457 | - a participant code (type and number: C01, G04, M02) 458 | - statement or question 459 | - from notes or audio recordings and relevant to the user needs assessment 460 | + Include.... 461 | * factural statement 462 | * participant quotes 463 | * observations, as statements 464 | * interpretations 465 | * Questions 466 | + Tips: 467 | * make each note understandable on its own 468 | * be concrete but concise 469 | * one affinity note per minute of interview 470 | + Interpretations 471 | * repeating themes 472 | * contradictions or conflicts 473 | * key findings 474 | * root issues 475 | * anything else 476 | + Good Quotes: 477 | * unexpected 478 | * representative 479 | + 480 | 481 | [back to top](#top) 482 | 483 | 484 | ## Affinity Walls and Analysis 485 | 486 | ### L10: Analyzing Qualitative Data 487 | 488 | - The **Secret** to intelligence 489 | + By clustering, sorting, finding patterns, and relating things to each other, you can condense information 490 | - condensing is understanding 491 | - understanding is intelligence! 492 | 493 | [back to top](#top) 494 | 495 | ### L11: Affinity Walls 496 | 497 | - Affinity Wall Guidelines 498 | + at first, make clusters quickly 499 | + move notes around as you see new patterns 500 | + don't get too attached to clusters 501 | + Aim for clusters of 3-7 notes 502 | * break up if more than 7 notes 503 | * merge if less than 3 notes 504 | + Writing the next-level notes is the crux: 505 | * summarize the knowledge in the cluster 506 | * summary should be a full sentence and make sense on its own 507 | * balance abstraction and precision 508 | + Stop creating level when summaries become uninformative 509 | 510 | 511 | [back to top](#top) 512 | 513 | 514 | ### L12: Variations on User Needs Assessments 515 | 516 | - watched 517 | 518 | ### Conclusion 519 | 520 | - watched 521 | 522 | 523 | [back to top](#top) 524 | 525 | 526 | 527 | 528 | 529 | 530 | 531 | 532 | -------------------------------------------------------------------------------- /Udemy-DESIGN-RULES/Notes.md: -------------------------------------------------------------------------------- 1 | [Design-UX-UI Home](https://github.com/coolinmc6/design-ux-ui) - [Udemy Courses List](https://github.com/coolinmc6/design-ux-ui#udemy-courses) 2 | 3 | 4 | # Design Rules 5 | 6 | ## Table of Contents 7 | 8 | - [Course Documents](#) 9 | - [Course Summary and Key Take-aways](#course-summary-and-key-take-aways) 10 | + [Basic Summary](#course-summary) 11 | + [Most Interesting Parts](#my-key-takeaways) 12 | - [Course Syllabus](#course-syllabus-and-learning-objectives) 13 | 14 | ## Course Summary and Key Take-aways 15 | 16 | ### Course Summary 17 | 18 | **UI Design Mantras** 19 | 20 | - UI Design Mantra #1: Design is Design is Design 21 | - UI Design Mantra #2: Stop Solving Other People's Problems 22 | - UI Design Mantra #3: Form Doesn't (and Shouldn't) Follow Function 23 | - UI Design Mantra #4: Force Evolves Form 24 | - UI Design Mantra #5: On Small Screens, Less is More 25 | - UI Design Mantra #6: Balance creates visual order and signals relationships 26 | - UI Design Mantra #7: Visual rhythm speeds comprehension and use. 27 | - UI Design Mantra #8: Good design is held together by harmony. 28 | - UI Design Mantra #9: Dominance directs user focus. 29 | - UI Design Mantra #10: Align everything with everything else. 30 | - UI Design Mantra #11: Group and organize related content with proximity. 31 | - UI Design Mantra #12: Use color to communicate and influence interaction. 32 | - UI Design Mantra #13: Choose color based on associations, emotions, and brand. 33 | - UI Design Mantra #14: Contrast always wins. 34 | - 35 | - UI Design Mantra #16: Icons must be recognizable and memorable. 36 | - UI Design Mantra #17: Context of use dictates visual form. 37 | 38 | 39 | ### My Key Takeaways 40 | 41 | [back to top](#top) 42 | 43 | ## Course Syllabus and Learning Objectives 44 | 45 | [back to top](#top) 46 | 47 | ## Ground Rules: What You Need to Know Upfront 48 | 49 | ### Design is Design is Design 50 | 51 | - "If you can design one thing, you can design *everything*." - Massimo Vignelli 52 | - design is **solving problems**. Not drawing pictures 53 | - Design is a problem-solving discipline 54 | + does the design serve the purpose of its existence? 55 | + how should it be perceived (and received) by the viewer/audience 56 | + what does that matter to anyone? 57 | - "If you don't have a good solution, yo don't have a good problem." 58 | + what is it supposed to do? 59 | + You need to properly define the problem 60 | - The principles of **good graphic design** are the same principles that dictate **good UI design** 61 | - nothing in UI design should be arbitrary or "just because it looks cool" 62 | - design is design is design. 63 | - It doesn't matter, they're all the same; you are always starting by figuring out what people are trying to accomplish 64 | * **UI Design Mantra #1: Design is Design is Design** 65 | 66 | [back to top](#top) 67 | 68 | ### Stop Solving Other People's Problems 69 | 70 | - don't look at themes 71 | + themes look nice - but they offer no explanation of what, how and why 72 | * they don't tell us anything about the problems they were solving to create them 73 | - Do you start the design process by looking at the work of other designers 74 | + don't look for inspiration 75 | * you will only find someone else's solution to someone else's problem 76 | * the problem you have to solve belongs exclusively to you, your client and your users 77 | * "Do not seek to follow in the footsteps of the wise. Seek what they sought. 78 | + Don't look at trends 79 | * flat design has become a widespread trend 80 | - designers are adopting th elook without considering whether it's appropriate for the situation or whether people understand what they see 81 | - flat design without visual affordances makes it difficult for the user to understand what they're seeing is interactive 82 | + Design vs decoration 83 | * designer = things hard about the appropriateness of the visual decisions they make, and those decisions are informed by research, investigation and fact 84 | - context of use 85 | * decorator = relies on his/her instincts as to what looks good and what doesn't. Most designers who've never learned the timeless principles of design are in this category 86 | + **UI Design Mantra #2: Stop Solving Other People's Problems** 87 | 88 | [back to top](#top) 89 | 90 | ### Form Doesn't (and Shouldn't) Follow Function? 91 | 92 | - On the surface, "form follows function" seems to make a lot of sense 93 | - In terms of UI design, it's applied like this: 94 | + "gather" the product's requirements from the client, then 95 | + Determine the aesthetics of the UI based on those requirements 96 | + it's not that simple 97 | - "Form follows function" has been: 98 | + co-opted 99 | + misinterpreted 100 | + misapplied 101 | - In order to understand it, understand how it came to be: 102 | + Louis Sullivan start it all in 1986 103 | + Sullivan was a rebel, bucking the forms of buildings still based on ancient Greek and Roman architecture 104 | + Believed new form for buildings was needed 105 | + Frank Lloyd Wright: form and function should be one 106 | + Guggenheim museum is a spiral so that people could easily see the art 107 | + Adolf Loos was againsg ornamentation 108 | + Walt Gropius founded bauhaus: architecture beigns where the engineering ends 109 | * Bauhaus was a school of multidisciplinary design 110 | * Form had to reflect the function of the product 111 | * Bauhaus was the foundation for modern graphic design 112 | - connection between color and shape 113 | - clean, powerful typography 114 | - spatial relationships and integration of shape, colo, and typography 115 | - core principles of visual design such as harmony, balance, rhythm, proportion, symmetry and synthesis 116 | + modern graphic design is the foundation of US Design 117 | + Universal Principles of Design = get this book! 118 | - **UI Design Mantra #3: Form Doesn't (and Shouldn't) Follow Function** 119 | 120 | [back to top](#top) 121 | 122 | ### Balancing Form and Function: Prescription vs. Description 123 | 124 | - the thing that will make you a great designer is your understanding of the "why" you are making the visual decisions you make 125 | - Description 126 | + beauty results from purity of function (not ornamentation) 127 | + this derives from the believe that form follows function in nature 128 | - Prescription 129 | + aesthetic considerations should be secondary to functional considerations 130 | + **This is the one that's gotten us into so much trouble** 131 | - Description 132 | + Nature => variations in form allow some species to succeed, survive and flourish 133 | + Product Design => variations in form of products compete for sales 134 | - Prescription 135 | + Dogma => prioritize functionality over all other design considerations 136 | * insist aesthetic considerations in design should be secondary to functional considerations 137 | + Product Design => designers and developer are led to ask a very wrong question: what elements here don't specifically serve a function - and should be removed? 138 | - Logically.... 139 | - if the form of a design was ruled solely by its function, then every functional item would have one and only one design solution 140 | - every element would ultimately have the same design 141 | 142 | [back to top](#top) 143 | 144 | ### Why Form Follows Function is NOT a UI Design Prescription 145 | 146 | - Reality Check #1 - Users are most often frustrated and confused when confronted with visual form that strictly reflects technical function 147 | - Design according to implementation 148 | + Implementation Model (reflects technology) vs. Mental Model (user's understanding) 149 | - Do you really need to know the mechanics of how something works in order to use it? 150 | + Answer: **NO** 151 | - As users, we don't care how it works 152 | + our focus is on the experience 153 | + we have a mental model that predicts the experience and tells us what we can expect 154 | + When the UI sticks close to our mental model, it's easier 155 | - Reality Check #2: Form should be determined by success criteria - not by function or personal aesthetic preferences 156 | + be interested in outcomes, not features 157 | + Form follows function only works in situations where something only has one function 158 | + convenience trumps best practice all the time 159 | - What visually communicates value? 160 | - Reality Check #3: Function is onlly a single, isolated aspect of what drives and influences form 161 | 162 | [back to top](#top) 163 | 164 | ### Every Force Evloves Form (So Don't Follow the Prescription) 165 | 166 | - Every force evolves a form 167 | - what really drives form? 168 | + audience needs 169 | + client desires 170 | + ethical obligations 171 | + aesthetic inclinations 172 | + technology constraints 173 | + cultural presuppositions 174 | + functional requirements 175 | + material properties 176 | + available time 177 | + available budget 178 | + available resources 179 | - The form of a digital product is a balance between: 180 | + UI design 181 | + information architecture 182 | + front-end HTML/CSS 183 | + middle tier logic 184 | + backend data structures 185 | + programming and processes 186 | - Don't use form follows function as a prescription 187 | + focus on the relative importance of form and function 188 | - Allow the **description** of "form follows function" to guide your efforts 189 | - **UI Design Mantra #4: Force Evolves Form** 190 | 191 | [back to top](#top) 192 | 193 | ### Less is More: Small Screens, Big Challenges 194 | 195 | - research has shows that visual complexity can obstruct a user's perception within 50 milliseconds of exposure 196 | - if it looks too complex we assume it's hard to user (or at least time-consuming) 197 | - but this isn't about simplicity for simplicity's sake 198 | - but don't get too far 199 | + common UI elements: buttons, menus, common actions, are a very significant part of what makes a site or app useful 200 | - Hiding elements can be costly 201 | + icons without labels are worse than labels alone 202 | - Expecting users to discover interactions through trial and error is a recipe for disaster 203 | 204 | [back to top](#top) 205 | 206 | ### Five Rules for Effective UI Design on Small Screens 207 | 208 | - #1. Focus on context of use 209 | + when are people using the app/site? 210 | + are they stressed? bored? busy? lost? 211 | + the available features and functions - and the way they work - should fit the situation 212 | - #2. Simplify, simplify, simplify 213 | + each screen should contain one primary action 214 | + every screen should provide something useful, meaningful, and valuable 215 | + abandon the idea that the number of screen (or steps) matters. It doesn't 216 | - #3. Design for thumbs? 217 | + most people rely on one or both thumbs to interact on phones 218 | - #4. Design for fat fingers 219 | + minimum 48px in diameter 220 | + anything smaller makes it hard to tap easily and accurately 221 | + provide ample space between targets so users don't accidentally tap the wrong target 222 | - #5. Minimize the need to type 223 | + it's a slow, error-prone process 224 | + keep forms short and simple 225 | + use auto-complete and personalized data where possible 226 | - **UI Design Mantra #5: On Small Screens, Less is More** 227 | 228 | [back to top](#top) 229 | 230 | ## Organizing Visual Information 231 | 232 | ### Balance: Creating Visual Order 233 | 234 | - Balancing any layout arranging positive elements and negative elements so that no one area of the design overpowers the others (unless it's supposed to) 235 | - everything works and fits together 236 | - when a design is unbalanced, the individual elements compete with the whole 237 | - Think of the Smashing website => grouping items to remove the number of "visual elements" that a user must "digest" 238 | 239 | [back to top](#top) 240 | 241 | ### Case Studies: Improving Balance in the User Interface 242 | 243 | - Balance creates order + signals relationships 244 | + Drudge Report 245 | * making the three columns equal width 246 | * adding more space between the links 247 | * adding white space added some order 248 | * negative space can create the divider; you don't need the vertical line 249 | - In a content-heavy layout, balancing negative an dpositive space is mission-critical 250 | + htis allows the user to quickly scan, identify and group related visual elements 251 | + negative space works to signal visual hierarchy - using size, weight and alignment 252 | + its boundaires work to define and group visual information 253 | - **UI Design Mantra #6: Balance creates visual order and signals relationships** 254 | 255 | [back to top](#top) 256 | 257 | ### Rhythm: Establishing and Reinforcing Comprehension 258 | 259 | - Rhythm occurs when the intervals between elements are predictable - and similar in size, shape and length 260 | - When elements repeat at regular intervals, the visual rhythm speeds identification and the user's ability to quickly: 261 | + infer what the elements are 262 | + understand what they do 263 | + two or or more of anything implies related structure 264 | + if you create structure, you also have to control it 265 | - **UI Design Mantra #7: Visual rhythm speeds comprehension and use.** 266 | 267 | [back to top](#top) 268 | 269 | ### Harmony: Shaping the Parts Into a Whole 270 | 271 | - harmony - when visual elements are in harmony, they relate to and complement each other 272 | - harmony is a big part of what holds individual elements together visually, to form a greater, cohesive whole 273 | - Harmony comes largely from rhythm and from repetition 274 | - Repetition re-emphasizes visual elements, connecting and creating areas of attention 275 | 276 | [back to top](#top) 277 | 278 | 279 | ### Using Harmony to Create Directional Flow 280 | 281 | - Harmony is directional 282 | 283 | [back to top](#top) 284 | 285 | ### Case Study: Using Harmony for Better Form Design 286 | 287 | - First Name and Last Name are same width and their combined width is equivalent to the other inputs below it 288 | - the Submit button is a purposeful anomaly 289 | - the height of the inputs and buttons are the same 290 | - vertical distance between the input fields is the same but the Submit button has a shorter vertical distance between it and the bottom input 291 | - label and input styles repeated create **consistent visual intervals** 292 | - **UI Design Mantra #8: Good design is held together by harmony.** 293 | 294 | [back to top](#top) 295 | 296 | ### Dominance: Directing (and Maintaining) User Focus 297 | 298 | - Dominance 299 | + What's the first thing you see? 300 | + Where is your attention drawn? 301 | + Dominance is achieved by emphasizing one or more visual elements 302 | + This creates a focal point where most people will instinctively go at first glance 303 | + Dominance creates an entry point in the design; a starting point from which you can lead the viewer to other parts of the screen 304 | - Dominance enables and directs flow 305 | + from a primary dominant design, flow is achieved by creating elements with secondary and tertiary dominance; in other words: **hierarchy** 306 | + dominance relies on contrast - clear differences in the visual field 307 | + by creating a dominant element, you reveal what's most important in your design 308 | + you show people where to look first 309 | 310 | [back to top](#top) 311 | 312 | ### Using Dominance to Increase Focus - and Decrease Cognitive Effort 313 | 314 | - Dominance enables and directs flow 315 | + when there's no clear dominance between elements, they compete with each other 316 | + without a dominant element onscreen, users have to work to find their own entry point 317 | + we're write to conserve effort, which means the least amount of work may be moving on to another design/screen/site/app 318 | + something that's "too busy" lacks a dominant element 319 | 320 | [back to top](#top) 321 | 322 | ### Creating Dominance with Size, Negative Space and Contrast 323 | 324 | - more contrast = more dominance 325 | + contrast > size 326 | - more negative space = more dominance 327 | - **UI Design Mantra #9: Dominance directs user focus.** 328 | 329 | [back to top](#top) 330 | 331 | ### Alignment: Leading the Eye Across the Screen 332 | 333 | - Alignment is the most important visual design principle but is often the most borken 334 | - you don't always have to put a lines and boxes around items 335 | + get in the habit of not putting a line or a stroke between items 336 | 337 | [back to top](#top) 338 | 339 | ### Case Studies: The Power of Alignment 340 | 341 | - aligning elements that are related by context creates visual order 342 | - **UI Design Mantra #10: Align everything with everything else.** 343 | 344 | [back to top](#top) 345 | 346 | ### Proximity: Showing and Communicating Visual Relationships 347 | 348 | - Proximity is the distance between visual elements 349 | - We use it to signal relationships between those elements 350 | - elements visually close to each other are perceived as a single group, related by context of use 351 | - unrelated items are visually separated, far from each other 352 | - proximity describes relationships 353 | - proximity often beats color and contrast 354 | 355 | [back to top](#top) 356 | 357 | ### Using Proximity to Make Cofnition Faster 358 | 359 | - proximity makes cognition faster 360 | - proximity makes browsing easier 361 | - **UI Design Mantra #11: Group and organize related content with proximity.** 362 | 363 | [back to top](#top) 364 | 365 | 366 | ## Using Color and Contrast Appropriately 367 | 368 | ### Color: Getting Attention and Communicating Emotion 369 | 370 | - color matters 371 | + color gets attention 372 | + color stires emotional reponse and suggests associated meaning 373 | + to prevent confusion in meaning, color has to be used consistently 374 | + to get the desired emotional response, color has to be used appropriately 375 | + think of the red dot to highlight a particular screen 376 | - color communicates 377 | + the right colors draw the eye to the most important areas on the screen 378 | + color can maximize readability and minimize optical fatigue 379 | + color delivers symbolic meanings that support and enhance the visual experience of a design 380 | + color pleases the eye and sustains visual interest 381 | 382 | [back to top](#top) 383 | 384 | 385 | ### How Color Influences Interaction 386 | 387 | - For Twitter, notice that the back button, the hashtag, the link - they're all blue to indicate that they are taking you somewhere 388 | + the heart is red because it's a different kind of interaction 389 | - **Color creates connection, continuity** 390 | - color implies meaning 391 | + color is subjective; our perceptions and biases affect what it says (and does) to us 392 | + Some colors have universal appeal; others are specific to geography, culture and experience 393 | - color should highlight, not determine 394 | + color should never be the sole differentiator of things in the UI 395 | + it should highlight and guide 396 | + for extended screen use situations, use light, muted background color 397 | + bright, saturated color should only be used as visual accents 398 | 399 | 400 | 401 | [back to top](#top) 402 | 403 | 404 | ### A Word on Color Theory - and Using Color Correctly 405 | 406 | - color theory is useful 407 | + but it's also a real pain 408 | + you're never going to understand to have the time you need to fully understand color theory, much less apply it during a project 409 | + look up: Color Wheel and Color Theory 410 | - Are you using color correctly? 411 | + are colors used sparingly? 412 | + do your colors reinforce and interfere with hierarchy and content? 413 | + is the color scheme used consistenly? 414 | + is color use functional, or just decorative? 415 | + does functionality depend on color? 416 | * if I can't see that color properly, will it affect how I use the app 417 | + Would this be just as functional for someone who's color blind? 418 | - **UI Design Mantra #12: Use color to communicate and influence interaction.** 419 | 420 | [back to top](#top) 421 | 422 | 423 | 424 | ### How to Choose the Right Color for your UI: Common Associations 425 | 426 | - consider common associations 427 | - Black - authority and power; timeless; cool; brooding; counter culture (arts & music) 428 | - White - innocence and purity; cleanliness and sterility; surrender and peace; 429 | - Red - Alarm and urgency; attention; intensity; speed; warning of danger; love 430 | - Black, white and red are the highest degree of contrast 431 | - Pink - romance, gratitude; grace;admiration; harmony; compassion; female 432 | - Blue - peaceful, tranquil; sk; ocean; business; technology; innovation; male 433 | - Green - nature, organic; calming; refreshing; relaxing (hospital "green" rooms) 434 | - Yellow - optimism, happiness; warmth (sunlight); positivity; joy, hope; 435 | - Purple - royalty; wealth; luxury; sophistication; considered feminine and romantic 436 | - Brown - nature; Earth; home, friendship; richness; genuineness; solidity 437 | 438 | 439 | [back to top](#top) 440 | 441 | 442 | ### How to Choose the Right Color for your UI: Emotional Impact 443 | 444 | - Red 445 | + seeing red has psychological impact: it's been proven to increase blood circulation, breathing, metabolism 446 | + Red elements demand to be noticed, scream for attention 447 | + red also signifies importance and priority, like a to-do list 448 | - Blue 449 | - Blue tends to have a calming, inviting eggect, due to associations with sky and water 450 | - It also communicates trust (banks, tech) 451 | - symbolized reliability and trust 452 | - lighter blues are open and friendly; darker shades suggest security 453 | * Green 454 | - green is often associated with nature, success, growth and money 455 | - green sits right between warm and cool, making it well-balanced 456 | - it also feels fresh, new, and, in western culture, signifies all is OK 457 | 458 | [back to top](#top) 459 | 460 | ### How to Choose the Right for your UI: From the World Around You 461 | 462 | - Everything you see contains the four color variations required for good UI: 463 | + shadows 464 | + midtones 465 | + highlights 466 | + accents 467 | - CM - from the examples, the shadow, midtone and highlights (darkest to lightest) are all in the same "family" of color and then the accent is picked to call out items 468 | 469 | [back to top](#top) 470 | 471 | ### How to Choose the Right for your UI: From Brand Colors 472 | 473 | - Most organizations have a brand color scheme they'll want to start with (usually at least a logo) 474 | - most logos are too color saturated 475 | - vibrant, saturated colors cause eye strain 476 | - HSB - Hue-Saturation-Brightness 477 | - Reduce saturation to more tolerable levels (i.e. 80's/90's down to 50's) 478 | - **UI Design Mantra #13: Choose color based on associations, emotions, and brand.** 479 | 480 | [back to top](#top) 481 | 482 | ### The Power of Contrast 483 | 484 | - Contrast wins over color 485 | - Your eyes look for contrast naturally 486 | 487 | [back to top](#top) 488 | 489 | ### Using Contrast to Improve Readability, Attention and Focus 490 | 491 | - Contrast enables readbility 492 | + text is easily readable when start, complementary colors are used 493 | + a design where text is the brightest element can reduce strain by focusing attention 494 | + The fact that colors are complementary doesn't mean contrast is appropriate 495 | - Contrast draws attention 496 | + areas of highest contrast draw the user's attention 497 | + constrast should be applied according to the importance of a particular element 498 | + primary content or actions should have the most contrast 499 | - Contrast directs focus 500 | + wherever you apply the most contrast is where the user's attention will be drawn 501 | + if that element isn't the most important thing, you're directing the user's focus in the wrong place 502 | + design with contrast purposefully keeps the user's focus where it needs to be 503 | + the core content or action should have the most contrast 504 | + secondary content and actions (and everything else) should have lower contrast by degrees 505 | 506 | [back to top](#top) 507 | 508 | ### Three Essential Functions of Contrast in UI Design 509 | 510 | - Contrast performs 3 essential functions: 511 | + 1. Contrast draws the user's attention to the essential components of the interface 512 | + 2. Contrasts helps the user understand relationships between onscreen elements 513 | + 3. Contrast communicates hierarchy and signifies importance within and across multiple sets of visual information 514 | - **UI Design Mantra #14: Contrast always wins.** 515 | 516 | [back to top](#top) 517 | 518 | ### How to Determine Appropriate Color and Contrast 519 | 520 | - color and contrast depend on context 521 | - how do we tell if contrast is appropriate 522 | 523 | [back to top](#top) 524 | 525 | 526 | ## Designing with Typography and Imagery 527 | 528 | ### Typography 101: It's About Much More Than Choosing a Font! 529 | 530 | - typography has one plain duty before it and that is to convey information in writing. 531 | 532 | ### Creating Emotional Impact with Typography 533 | 534 | - Typography creates emotional impact 535 | - typography serves functional purpose 536 | - Appropriate typography choices create: 537 | + readability 538 | + accessibility 539 | + usability 540 | + visual balance 541 | 542 | ### Choosing a Font Isn't Typography: The Importance of Pattern Recognition 543 | 544 | - Choosing a font isn't typography 545 | + anyone can choose a font 546 | + not everyone knows how to treat text as visual design - utilizing size, weight, space and style combinations - to establish visual order, signal relationships and enhance understanding 547 | - pattern recognition 548 | 549 | 550 | [back to top](#top) 551 | 552 | ### The Importance of Proper Alignment 553 | 554 | - alignment 555 | - "rag-right" => not justified 556 | - center-aligned text has a different starting place for each line: paragraphs should never be center-aligned 557 | * kerning 558 | - kerning - the space between letters 559 | - kerning is critical to legibility, readability, and comprehension 560 | * leading 561 | - pronounced like the metal not like a "leader" 562 | - leading is the space between lines of text 563 | - in terms of UI design, we call it line height 564 | - increasing the leading makes text easier to scane and read, which makes comprehension a lot faster as well 565 | - it also serves to visually group text 566 | 567 | [back to top](#top) 568 | 569 | ### Seven Rules for Great Typography 570 | 571 | - 1. 2 typefaces max 572 | + that means no more than 2 font families 573 | + character widths and weights of each font should be complementary to the other 574 | + Avenir and Georgia have similar character widths; that creates visual harmony 575 | + At the same time, font pairings need to have some visual difference; otherwise, there's no reason to use the second font 576 | - 2. Limit line width 577 | + when line lengths are too wide, the eye has to work a lot hard to "track" the text - following and finding the beginning of the next line 578 | + this makes reading and comprehension much more difficult (and slower) 579 | + Limit 60 characters per line - desktop 580 | + 30-40 characters per line - mobile 581 | - 3. Choose readability 582 | + the typefaces you choose have to be readable at all sizes (headings, body, buttons, labels, data, etc.) 583 | + your typefaces should have enough height that letterforms don't degrade at small sizes 584 | - 4. Choose legibility 585 | + make sure all letterforms are clearly distinguishable in your typeface 586 | + beware of L's that look like I's 587 | + some fonts have poorly specified kerning 588 | - 5. Use space between paragraphs 589 | + visual breaks between paragaphs give the eyes a place to rest 590 | - 6. Align text elements in layout using baselines 591 | - 7. Use styles to visually differentiate content 592 | + when choosing a typeface, you want one with at least: regular, italic and bold 593 | + Use those styles in your design to differentiates between types of content 594 | + example: 595 | * heading is largest and bold 596 | * sub-head is larger than body and italicized 597 | * body is regular style and normal size 598 | 599 | [back to top](#top) 600 | 601 | ### Five Rules for Choosing Imagery 602 | 603 | - 1. Make sure it serves a purpose 604 | + and make sure you understand what that purpose is 605 | + what message will it send? 606 | + what emotions will it evoke 607 | + how will it support/reinforce the content? 608 | + how will it guide or instruct? 609 | + does it strengthen and deepen understanding, or interfere/distract from it? 610 | - 2. Focus on people (not things) 611 | + You want people to see themselves using what you're promoting 612 | + So an image of one of us using a product will always carry more resonance than an image of just that product 613 | + images of people looking away from the camera is easier for us to imagine that that is us 614 | - 3. Cropping can change meaning 615 | + How you crop an image has a dramatic impact on how it's perceived 616 | - 4. Never go for the cheap shot. 617 | + don't be sexist or objectify people 618 | + don't objectify - empower 619 | - 5. Don't forget the power of illustration 620 | + particularly when the subject is something we see a lot - and as a result are numb to 621 | + illustration can be more relevant and appropriate to its content; it can provide powerful emotion support to editorials 622 | 623 | [back to top](#top) 624 | 625 | ### Imagery DOs and DON'Ts 626 | 627 | - [https://material.io/design/communication/imagery.html#principles](https://material.io/design/communication/imagery.html#principles) 628 | - DO: Show an actual person when the reference to that person is specific 629 | - DO: Use illustration when specificity isn't possible, or doesn't apply 630 | - DO: Look for images that represent and tell realistic stories 631 | - DON'T: Use posed, staged stock images that feel faked and unemotional 632 | - DO: If you're referencing a specific produt, show *that specific product* 633 | - DON'T: default to generic, literal stock photos 634 | - DO: Use color and composition to create a focal point that communicates meaning 635 | - DON'T: make the user hunt for the hidden meaning(s) in your image 636 | - DO: Use images with only a few meaningful elements, with minimal distractions 637 | - DON'T: obscure the point of focus, which also obscures meaning and diminishes power 638 | - DO: Strive for clear visual focus, which communicates the concept at a glance 639 | - DON'T: use photos whose lack of focus makes the image meaningless 640 | - DO: Build a narrative; imply an interesting, informative story 641 | - DON'T: Use images without context; these don't convey mood, brand, and context 642 | - DO: show a product and people in the context of a real-world situation 643 | - DON'T: show a product and its user disassociated from that context; it's not interesting 644 | + think of the car seat - one has the mother with the child, the other has just the baby in the car seat looking at the camera 645 | - [https://stocksnap.io](https://stocksnap.io) 646 | 647 | [back to top](#top) 648 | 649 | 650 | 651 | 652 | 653 | ## Creating and Simplifying Visual Cues 654 | 655 | ### Working With Icons 656 | 657 | - Microsoft -> put the icon and then associated text/description 658 | - icons make excellent touch targets 659 | - icons save space 660 | - icons are quick to recognize 661 | - icons should clearly convey meaning 662 | 663 | [back to top](#top) 664 | 665 | ### Four Core Types of Icons (and How to Choose The Right Type) 666 | 667 | - Similar icons are useful for simple, easily understood actions and concepts 668 | + turn right, no smoking, hand in gears 669 | - Symbolic icons represent an action, object or concept at high abstraction 670 | + hamburger symbol, lock, printer 671 | - Example use images taht exeplify or are commonly associated with an action, object, or concept 672 | + airplane to represent an airport, scissors + dotted line for "cutting" something, mail symbol for email 673 | - Arbitrary icons bear no resemblance to the represented concept; their meaning is learned through repeated exposure 674 | + USB symbol, bluetooth, male/female 675 | - Icon choice starts with their environment 676 | + App icons should be based on Android or iOS icons 677 | + Laptop software should use Microsoft, Google Chrome 678 | + Website should be based on commonly used icons 679 | - Quick Rule of THumb 680 | + if you choose more than 15 minutes to pick an icon, you probably need a different icon 681 | - Label + icon is hard to beat 682 | + a text label goes a long way in properly setting user expectation and enabling them to predict the result of the interaction 683 | - **UI Design Mantra #16: Icons must be recognizable and memorable.** 684 | 685 | [back to top](#top) 686 | 687 | ### Five Rules for Effective Icon Design 688 | 689 | - 1. Keep visual / perceived size consistent 690 | + icons that occupy the same pixel space on the grid aren't necessarily perceived as being the same size 691 | + check optical size with shapes - look for equal visual weight 692 | + check width of rules (strokes) used in the icon 693 | * when rule width varies, icons will be perceived as different size 694 | - 2. Keep the level of detail consistent 695 | + More detailed icons will atract the user's attention first - because they appear to have more visual weight than the others 696 | - 3. Eliminate unnecessary detail 697 | + think context: what really needs to be there? 698 | * if you are working in an email app, do you really need the envelope for all icons? 699 | - 4. Don't mix and match styles 700 | + fill and non filled style; it's okay for hover/active 701 | - 5. Don't reinvent the wheel 702 | + if the concept or action depicted is common, near-unversal, stick with the established icon 703 | * anything else invites confusion 704 | 705 | [back to top](#top) 706 | 707 | ### Dealing with Data 708 | 709 | - The greatest value of a picture is when it forces us to notice what we never expected to see 710 | - the "three legged stool" 711 | + book: Designing Data Visualizations: Representing Informational Relationships 712 | + Data - Designer - Viewer 713 | 714 | ![Three Legged Stool](https://github.com/coolinmc6/design-ux-ui/blob/master/assets/three-legged-stool.png) 715 | 716 | - Persuasive 717 | + Designer to Viewer 718 | + represents a specific point of view 719 | + meant to change opinion or reinforce an existing opinion 720 | + bias can be unintentional 721 | - Informative 722 | + Viewer to Data 723 | + Neutral presentation of facts 724 | + meant to educate as opposed to persuade (watch bias!) 725 | + example: Google Analytics 726 | - Visual Art 727 | + Designer to Data 728 | + Encoding takes precedence over decoding 729 | + when intentional, the intended outcome is usually just enjoyment 730 | + When unintentional, can have serious, negative consequences 731 | - Context of use dictates visual form 732 | + What does the viewer need to understand - how quickly or easily? 733 | + Example: bar chart vs. pie graph 734 | + What matters most - to us and to the viewer? 735 | 736 | ![Highlight important data for the user](https://github.com/coolinmc6/design-ux-ui/blob/master/assets/highlight-important-data.png) 737 | 738 | - Do the visuals accurately reflect the numbers? 739 | + bad example: 3-D bar chart vs. regular 2-D => 2-D is simple, flat and easier to read 740 | - **UI Design Mantra #17: Context of use dictates visual form.** 741 | 742 | [back to top](#top) 743 | 744 | ### Five Rules for Great Data Design 745 | 746 | - 1. Data is only useful if it can be understood 747 | + if I don't understand it, I can't act on it 748 | + If I can't act on it, it's practically worthless 749 | + Data isn't the goal - it's a tool that helps us understand and make change in the world 750 | + Data without design is noise 751 | - 2. You're designing for other people 752 | + you have to design for their identity, motivation, language, and learned social contexts (colo associations, icon recognition, reading patterns, etc.) 753 | - 3. You're designing for their context of use 754 | + what amount of infomration does the user need in order to understand or act? 755 | + what motivaitons is he/she coming to the table with? 756 | + how do those motivations influence how useful or actionable the visualization is? 757 | + How much time does he/she have to spend with this information? 758 | - 4. The usefulness of data decreases when its volume increases 759 | + the more information is any given view, the harder it is for viewers to find what they care most about 760 | - 5. The more brainpower required to decode your visualization, the less that's available for understanding it 761 | 762 | [back to top](#top) 763 | 764 | ### Simplifying Visual Information - Part 1 765 | 766 | - 767 | 768 | [back to top](#top) 769 | 770 | ### Sipmlifying Visual Information - Part 2 771 | 772 | [back to top](#top) 773 | 774 | ### Separating Context from Controls - Part 1 775 | 776 | [back to top](#top) 777 | 778 | ### Separating Context from Controls - Part 2 779 | 780 | [back to top](#top) 781 | 782 | ## Things to Remember 783 | 784 | 785 | 786 | 787 | 788 | 789 | 790 | 791 | 792 | 793 | 794 | 795 | 796 | 797 | 798 | 799 | 800 | 801 | 802 | -------------------------------------------------------------------------------- /Udemy-UX-Design-Fundamentals/Notes.md: -------------------------------------------------------------------------------- 1 | [Design-UX-UI Home](https://github.com/coolinmc6/design-ux-ui) - [Udemy Courses List](https://github.com/coolinmc6/design-ux-ui#udemy-courses) 2 | 3 | 4 | # User Experience Design Fundamentals 5 | 6 | ## Table of Contents 7 | 8 | - [Course Documents](#) 9 | - [Course Summary and Key Take-aways](#course-summary-and-key-take-aways) 10 | + [Basic Summary](#course-summary) 11 | + [Most Interesting Parts](#my-key-takeaways) 12 | - [Course Syllabus](#course-syllabus-and-learning-objectives) 13 | 14 | ## Course Summary and Key Take-aways 15 | 16 | ### Course Summary 17 | 18 | ### My Key Takeaways 19 | 20 | [back to top](#top) 21 | 22 | ## Course Syllabus and Learning Objectives 23 | 24 | [back to top](#top) 25 | 26 | -------------------------------------------------------------------------------- /Udemy-UX-Web-Design-Master-Course/Notes.md: -------------------------------------------------------------------------------- 1 | [Design-UX-UI Home](https://github.com/coolinmc6/design-ux-ui) - [Udemy Courses List](https://github.com/coolinmc6/design-ux-ui#udemy-courses) 2 | 3 | 4 | # UX & Web Design Master Course: Strategy, Design, Development 5 | 6 | ## Table of Contents 7 | 8 | - [Course Documents](#) 9 | - [Course Summary and Key Take-aways](#course-summary-and-key-take-aways) 10 | + [Basic Summary](#course-summary) 11 | + [Most Interesting Parts](#my-key-takeaways) 12 | - [Course Syllabus](#course-syllabus-and-learning-objectives) 13 | 14 | ## Course Summary and Key Take-aways 15 | 16 | ### Course Summary 17 | 18 | ### My Key Takeaways 19 | 20 | [back to top](#top) 21 | 22 | ## Course Syllabus and Learning Objectives 23 | 24 | [back to top](#top) 25 | 26 | -------------------------------------------------------------------------------- /assets/CIRCLES-method-product-design-framework.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/CIRCLES-method-product-design-framework.png -------------------------------------------------------------------------------- /assets/How-To-Write-A-Good-PRD.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/How-To-Write-A-Good-PRD.pdf -------------------------------------------------------------------------------- /assets/IDF-Achievements-Templates.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/IDF-Achievements-Templates.pdf -------------------------------------------------------------------------------- /assets/Product-Vision-Workshop-Template.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/Product-Vision-Workshop-Template.pdf -------------------------------------------------------------------------------- /assets/UX-Laws-infographic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/UX-Laws-infographic.png -------------------------------------------------------------------------------- /assets/ask-right-questions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/ask-right-questions.png -------------------------------------------------------------------------------- /assets/dschool_bootleg_deck_2018_final_sm.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/dschool_bootleg_deck_2018_final_sm.pdf -------------------------------------------------------------------------------- /assets/facebook-pm-interview-cheat-sheet.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/facebook-pm-interview-cheat-sheet.jpg -------------------------------------------------------------------------------- /assets/highlight-important-data.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/highlight-important-data.png -------------------------------------------------------------------------------- /assets/product-manager-cheat-sheet.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/product-manager-cheat-sheet.jpg -------------------------------------------------------------------------------- /assets/the-basics-of-ux-design.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/the-basics-of-ux-design.pdf -------------------------------------------------------------------------------- /assets/three-legged-stool.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coolinmc6/design-ux-ui/0a4fe198fa7258a0dcc5c278558096c7a55d73e8/assets/three-legged-stool.png -------------------------------------------------------------------------------- /cm-docs/template.md: -------------------------------------------------------------------------------- 1 | [Design-UX-UI Home](https://github.com/coolinmc6/design-ux-ui) 2 | 3 | 4 | # Course Name 5 | 6 | ## Table of Contents 7 | 8 | - [Course Documents](#) 9 | - [Course Summary and Key Take-aways](#course-summary-and-key-take-aways) 10 | + [Basic Summary](#course-summary) 11 | + [Most Interesting Parts](#my-key-takeaways) 12 | - [Course Syllabus](#course-syllabus-and-learning-objectives) 13 | 14 | ## Course Summary and Key Take-aways 15 | 16 | ### Course Summary 17 | 18 | ### My Key Takeaways 19 | 20 | [back to top](#top) 21 | 22 | ## Course Syllabus and Learning Objectives 23 | 24 | [back to top](#top) 25 | 26 | --------------------------------------------------------------------------------