Table of Contents
IntroductionPaul Boag introduces the course by providing some personal background involving the design process. An overview of the four critical areas of the design process that will be covered in this course is also discussed in this segment.
Design Project & Avoiding PitfallsPaul discusses common reasons design projects struggle, including scope creep and subjectiveness. Suggestions for how to avoid design pitfalls, including introducing objectivity, involving the client often, and providing reassurance, are also covered in this segment.
Design PrinciplesPaul walks through the process of how to deliver solutions to the design pitfalls. Agreeing on design principles, the reasoning behind them, and workshopping design principles will help solidify and give direction to a project's design process.
Design Process IssuesPaul discusses issues with commonly used design processes, including designing without content, designs coming as a surprise, and clients' lack of the knowledge to provide constructive feedback. Design iterations being unpredictable, the final site compared to the original design, and project risks are also discussed in this segment.
Speculative DesignPaul demonstrates the fallbacks of producing unpaid design work for prospective clients. Prospective clients, the designer, and new clients all take all the costs of unpaid design work.
Better Design ProcessPaul provides an overview of a better design process by breaking the process up into four separate phases, discovery, prototyping, build, and live. Breaking a project into smaller phases reduces risk, provides more accurate cost estimates, and reduces the chances of failure.
Discovery PhasePaul briefly discusses the discovery phase of a design process as being dedicated to defining problems to be solved and the project's scope. These can be determined through user research, stakeholder interviews, competitive analysis research constraints, and reviewing the existing website/app.
Prototyping PhasePaul discusses the prototyping phase as having defined the design direction and build's scope. A discussion of the minimum that should be done for prototyping, including mockups, wireframes, testing aesthetics, and testing usability, is also covered in this segment.
Build & Live PhasesPaul briefly walks through the build and live phases of the design process and the minimum requirements for each. The build phase is where a design is turned into a fully functional website, and the live phase is monitoring the website's user behavior.
Defining StakeholdersPaul discusses defining the stakeholders role in the design process to help avoid irrelevant feedback and micro-managing and provides a checklist summary. Three roles of a stakeholder are finding problems, championing the business's needs, and defending the users.
Design Process Q&APaul answers student questions regarding what phase internally run projects for optimizing a site would be and if having content created or delegating content creation to the stakeholders is preferred. This segment also covers how this process applies to products like web or mobile apps and the differences between using this process in an agency and internal setting.
Initial Design & ContentPaul discusses techniques to engage stakeholders while maintaining control over the final design and how to approach content creation for non-copywriters. Using proper navigation, drafting content, and a student's question regarding drafting content for multilingual sites are also covered in this segment.
Content Process & Content BlocksPaul walks through prioritizing and organizing content through top task analysis and methods such as card sorting. Mapping content to pages based on card sorting results and grouping related items by chunking content is also discussed in this segment.
Critical Pages and Q&APaul discusses integrating stakeholders when deciding on the page content and briefly covers what critical pages should be wireframed. Student questions regarding at what point to move from discovery to prototype and what phase of the process is currently being discussed are also covered in this segment.
WireframingPaul demonstrates two quick wireframe tests, a 5-second, and first-click test, to determine page layout and whether or not users see a design's call to action. A student's question regarding how to factor in must-have text such as legal and cookies is also discussed in this segment.
Design Style & AestheticPaul discusses introducing a site's aesthetic, defining brand keywords with stakeholder exercises, and creating style tiles. Style tile aesthetics can be tested with semantic differential surveys to determine how well the brand keywords are conveyed to the target audience.
High Fidelity Mockup or PrototypePaul discusses creating high-fidelity mockups with the developer in mind and suggests a service to predict where users will look when viewing a design. Creating a high-fidelity prototype, testing the prototype, and a brief checklist for the design and prototyping phase are also covered in this segment.
Presenting to StakeholdersPaul demonstrates steps to prepare for presenting a design, including involving the stakeholders, identifying possible objections, and creating a short video. Common complaints, potential responses, and reasons to speak to stakeholders individually are also provided in this segment.
Design Presentation AgendaPaul walks through the main steps of a design presentation, including recapping stakeholder decisions and collaboration, design testing, and preempting objections. Ending a presentation while downplaying design sign-off and providing ample time for stakeholder feedback are also discussed in this segment.
Handling Feedback & DisagreementsPaul discusses avoiding feedback during a presentation and following up post-presentation to get better feedback results. Example questions to ask stakeholders and how to handle disagreements are also covered in this segment.
Handling Scope CreepPaul discusses handling when scope creep becomes impossible or unreasonable to accommodate. Creating a backlog of post-launch work and test scenarios helps reassure stakeholders that the project is ongoing.
Design Presentation ChecklistPaul walks through a six-point presentation and feedback checklist and responds to a student's comment on the value of the previously discussed suggestions for a better presentation experience.
Keeping Development in MindPaul discusses working with developers to ensure the final product reflects the design. Creating reusable components, designing with auto-layout, and staying consistent with colors and typography helps reduce the margin of error and workload on developers.
Design SystemsPaul demonstrates the benefits of creating a design system and the critical parts to include in design systems: styles, elements, and components. A student's question regarding how to handle disagreements with designers wanting a "pixel-perfect" design is also covered in this segment.
Design Systems Q&APaul answers student questions regarding what scale to begin thinking about a design system and how to handle finding a mistake after the presentation.
Post Launch OptimizationPaul discusses utilizing the live user interactions of the launched design for post-launch optimization and provides examples of companies who have benefited from it. Prepare clients for post-launch optimization by including it in the initial design timeline and creating a list of post-launch features and improvements.
Post Launch Optimization ProcessPaul walks through post-launch optimization, including identifying dropout points, identifying the problems, testing solutions, and publishing those solutions. Testing solutions depend on the size of the change; small changes can use an AB testing tool, while significant changes may require a prototype of the new approach.
Final ChecklistPaul walks through a six-point checklist for the final stages of the design process.
Final Design Process Q&APaul answers student questions regarding examples of design systems for inspiration and opinions on large organizations relying on third-party agencies when designers should stick with an established design pattern or suggest a new one.