�ݺ�ߣ

Editor's Notes

• #3: Career path from developer to entrepreneur.
• #4: For a product to become successful, there are a number of things that need to go well. Engineering– Right architect, scalable, reliable, performance, etc. Market Fit – Does the product serve the needs of the market? Is the market ready (too early)? Is the market big enough (addressable market)? “Product Market Fit” Business execution – Sales, Marketing, and business operation execution. Attracting customers, scaling sales teams, manufacturing supply chains, etc. User Experience - Can think of this as customer experiencs. Does it fit the needs of the user? Do they love it? Great engineers also think about, not just something UX people think about. It is a mindset. Engineers who get this can often be the key to making products users love. Technical foundation and user experience are absolutely connected. Think performance, e.g., Amazon and Instagram. Tell story of Friendster, MySpace, and Facebook. For engineers who start a company, this becomes a critical skill. Most startups lack the resources to hire a bunch of specialists in UX on day one, so engineer-entrepreneurs benefit greatly by developing this mindset.
• #5: Product Design isn’t about colors and pixels (that’s just part of it All aspects of how people use and interact with a product: The way it feels in their hands, how well they understand how it works, how they feel about it while they’re using it, how well it serves their purposes, and how well it fits into the entire context in which they are using it. “The Design of Everyday Things” – Don Norman
• #6: Think about going to a restaurant. It is more than just the food. Every element matters The décor The ambiance The service * Payment. Only take cash, but you don’t have cash. This may ruin your evening.
• #8: Bad UX doesn’t just apply to software
• #9: Windows What that heck does this mean? Sounds scary!! User is stuck
• #10: Don’t make me think!! A good mantra and great UX book
• #11: Don’t make me feel stupid either I’m not picking on Microsoft Here is one from Apple from their Mac OS
• #12: Engineering and User Experience are related. Best product outcomes are when everyone adopts the mindset. It’s everyone’s job (Developers, Product Managers, etc) Not always going to have every type of UX specialist Especially in a startup Even more important that developers understand UX concepts and process Having this mindset will make a big difference Jeff Bezos is super technical, but talent for UX is the big difference that has made Amazon successful Elon Musk and the Tesla. Also very technical but with a excellent UX mindset Software developers already build things with attributes that are similar to UX concepts. E.g.,Scalable (how the UX expands over time), Architecture (how things hang together) UX mindset can be applied to things like APIs The developer is the user Many of the attributes you’ll strive for in user facing functionality are relevant APIs - When building a platform developers are the users Who is the developer? Different kinds of developers? Design of the API with type of developers in mind. User centered. Level of abstraction. Method calls, parameters, error messages, iterating through lists of return values, etc. Consistency across APIs. Amazon AWS was meant to be easy to use by all developers, not just the ones who work at Amazon or Google Shows how Bezos applied same mindset and approach. Developers at the center
• #13: Examples of UX scalability
• #14: How do you create products with an awesome user experience that users love UCD is a process for defining a User Experience Cross functional team and disciplines. Interaction Design, Visual Design, User Research, Engineering, Business, Product Management, and of course, the User Has phases, but more of a mindset User stays involved throughout the process. Iterative process.
• #15: Process for creating the User Experience Different phase Strategy Scope Structure Skeleton Surface From abstract to more concrete This will not only help you contribute to building a product users love and help you with your startup. Will also make you a better developer today “The Elements of User Experience” by Jesse James Garrett
• #17: In this phase - Determine what we want out of this things we’re going to build. Collect a lot of info and data. Why and What and Who questions. Talk to a lot of people, talk to people on your team, talk to other functional groups (e.g. marketing) User Needs. User research. User Context. Prioritize needs. Hard deliverable - Personas User Research Old school: Field studies and traditional focus groups with users (video recording) Don’t have to be this way. Simple sketches. Show Friends and family. Interact with people via Twitter/FB Needs <> features. Abstract away from thinking about features in this phase. Business Needs How does business goals impact user experience & brand Define Success Metrics (e.g. conversion, sharing, using premium features in a B2B product – E.g. Salesforce Customer Success effort)
• #20: Persona – Tourist Context could be – On the move, need a map that fits in pocket. Durable. Or a mobile app. Want to see tourist destination, e.g. Fisherman’s Wharf, Golden Gate Bridge
• #21: Lives in SF Context: Waiting at a bus stop On the move? Scenarios: * How to get someplace like a restaurant, baseball game * Looking for a more optimal way for a regular trip, e.g., to work, to doctor’s office
• #22: Persona - SF resident Context – riding a bike Needs – SF has a lot of hills. Wants to know how to get around best on a bike. Need to know how steep certain streets are All of these are maps, but different maps based on Persona, Context, User Needs, etc.
• #24: Strategy is translated into Scope Deliverable - Scenarios Encapsulate user needs Scenarios are not agile / scrum use cases. How different than Agile User Stories More end-to-end. Connecting the docs. Examples of Scenarios Using story boards Deliverable --Functional requirements & Feature Set Features support Scenarios Deliverable - Prioritizing features (Must, Should, Could, Would) Ideation. Start with brainstorming. Categorizing / Grouping features. Feature Areas. Technical requirements Content you’ll need
• #26: In this phase, transform strategy into features & functionality Deliverable - Workflows Boxes and arrows. Or, Site Map Architecture!! * Site Map App Map Information Architecture (content website, e-commerce site) Conventions. If you’re building a mobile app, what are things we can do with an iPhone that we can’t do desktop/website? GPS? Bluetooth? Conceptual Model. Our language. How are we going to label these things? Finder in Mac OS, e.g., Items, Folder (traditional hierarchical), Smart Folder (query based), toolbar, sidebar, devices, places, etc. Pretty important. Without thought, can lead to a lot of confusion internally and externally. Names have a habit of living on forever.
• #28: Here is an example for a Point of Sale system. A checkout system at a store using an iPad. Replace traditional cash register Grouping things we can do in this App? Registration Login Welcome Screen Settings Order Screen Payment Screen
• #29: Don’t need them to be fancy Can just use a whiteboard with a group and take a photo Can use paper and pen People think this stuff takes to long and want to go fast But end up going fast into a wall, over a cliff, or in circles
• #30: Conceptual Model. Our language. How are we going to label these things? Example - Finder in Mac OS. CAVEAT – I’m showing you the finished product in this phase you won’t get to this fidelity. No visual design for example. I cheated.  Concepts: Items Folder (traditional hierarchical) Smart Folder (query based) Toolbar Sidebar Devices Places Pretty important. Without thought, can lead to a lot of confusion internally and externally. Names have a habit of living on forever.
• #31: Information Architecture as part of User Experience process Technical Architecture Both provide structure to what is being built
• #33: In this phase, we develop the Blueprint for the product Doesn’t tell you What color the house will be Doesn’t tell your what brand the refrigerator will be Says where it will be located Doesn’t say what time of carpet you will have
• #34: Deliverable -- Wireframes Can start off as sketches Low to high fidelity Don’t need them all at once. Not waterfall. Iterative. But remember to capture interaction. How the user moves through the application Just a 2D screen is a trap Stay away from branding elements. Colors It’s a distraction. People will focus in on these things. Feedback will be all about this stuff Prevent you from making progress on wireframes. This is trap to avoid
• #35: Here is a low fidelity wireframe Nice tools like Balsamiq, which was used for this example Can use paper and pencil Where items will be placed? Navigation When buttons / icons will be places Where the user will find things How screens will be broken up into sections Dialogs Some high-level Text (e.g. button labels, menu items) Interface Design Where things are placed High level user interacts with the application. How the user moves through the application or website E.g., Search query entered in, then next step in search results page, from there there are sub-pages like video, images, news. But not super detailed Information Design (e.g. graph type for a report)
• #36: * Hi-fidelity wireframe Closer to what the final product will look like, but no Look and Feel Elements are in the same spot Interface Design in more detail How the user interacts with the application. How the user moves through the application or website Measurements & dimensions (pixel measurements) More detailed text, closer to “final” text (but nothing is final, just for this round) Some copy Instruction text Handling corner cases, e.g., errors, data validation Animation and transition Hover effectives (hover over item, then edit button or delete button appears) Scrolling behavior Resizing window on desktop Behavior on iPhone 4 vs iPhone 6 with larger screen Drag & drop behavior Space constraints (e.g. words in German are very long, how does that impact design) Data volume (e.g. different UI elements based on volume of data) Typically accompanied by more explanations & notes Can be written up If small team or group. Even if within a large company Can be a whiteboard session with engineer. Photo of whiteboard Handwritten notes Comments/Answers in Confluence Add to JIRA tickets
• #38: Brings everything together into the final product Visual Design. The coat of paint Deliverables Visual Mock-ups & Prototypes If high level of interaction => HTML/Javascript (engineering) UI Kit Look and feel Color scheme Integrating brand Style (buttons flat, drop shadow, gradients, rounded corners) Fonts, Typography Exact sound clips UI consistency Finalized layout. Dimensions. Measurements Pixel perfect? Well, kinda. Mock-up Protypes Can just be design mock-up screenshots as a slide deck in powerpoint Showing visual design along with movement through the app Clickable Mock-up Prototypes Can click on areas of the screen and move through the app Hard corded data, not fed from the back-end Still getting user feedback and iterating Can be quick Don’t need to do fancy things like eye tracking Can use Google Hangout to interact with users User emotional reaction Developers provide critical feedback As they focus on implementation may identify things that are missed Feedback on implementation (t-shirt sizing small, medium, large). Time Risk Product Managers will often prioritize when functionality will be deliver. Sequencing implementation
• #39: *Both agile and UCD are iterative *Progress in small steps with verification and refinement along the way. *History of conflict between agile developers and UX designers. Agile software development is predominantly a developer-led philosophy, while UCD is, in many organizations, championed by creatives. Agile often focused on working software as measure of success UCD focuses on user needs, balanced with achieving business goals UCD – design without constraints. Long term end-to-end flows and scenarios. Sometimes prod dev has constraints that conflict, deadlines, legacy limitation (tech debt) Extending beyond the next spring or couple of sprints, while Agile often focuses on current sprint, next spring, and spends less time on future stuff Prod Dev works with UX to lay UX foundation (architecture) upfront, phase in along way to get to end-point Can’t really do UX within a sprint. Just doesn’t work. Handover between UX team and prod dev team creates risk. Blended teams help fix this. Engineering understands UCD and how to incorporate into Agile. Blended teams, where engineering can do UX prototypes and testing. Incorporate time (even if don’t have tasks in JIRA) to do UX testing and iteration within schedule. Easier to do this in start-ups where don’t have specialists for each UX area. Everyone’s job Agile prioritizes face-to-face communication, within SCRUM standups, but UCD while iterative is looking at end-to-end scenario that extends beyond a sprint or two, more focus on ideal end state
• #40: Select technology, libraries, languages, frameworks, and architecture with iteration in mind. Apply the mindset as you make decisions of feature implementation. Don’t just off load it to UX professionals Performance, scalability, etc., are part of UX. Instagram & Amazon examples Bake UX into schedules and estimates (time for additional prototyping, time for tweak after additional user feedback). Avoid the sprint trap. Remember nature tension between user experience & Agile Instrumentation trap. Don’t instrument upfront. Assume it can be done later. But then there is no data for analysis