Philosophy

• Measure twice, cut once: design is cheaper than development, so it saves money to invest in design research, rather than to build quickly and learn after release.
• Proper human-centered design is the path to excellent products. The “fail faster” approach of building quickly with minimal UX testing leads to products that are just good enough, because new features will usually be prioritized over improving something that’s already built.
• Trust the process: we won’t know at the outset what the right solution is. Go through the exercises and the solution will become clear eventually.

• I believe in the servant leadership approach—my goal is to enable success for my employees, putting them in an environment where they can thrive and produce their best work for the company.
• Regular one-on-one meetings are key for keeping communication lines open. If there is a problem, an employee should find out as soon as possible. The employee should never be surprised during a review.

• Most people are terrible at defining what they need, but they will often try to prescribe a solution. Work with them to get them to focus on the problems to solve, and the user tasks to be done.
• It’s OK if conversation gets off track during requirements-gathering. Listen and take notes. Often something will come up that wouldn’t have come up in a more directed session.
• You don’t have to solve all edge cases, but you should handle them gracefully. And try to validate that your edge cases are really edge cases; maybe they come up more than you think.

• A web site or app should be clean, easy to read, and easy to navigate.
• Stick with the familiar for functional elements. Users have become used to certain practices; give them what they expect.
• Test, test, test your designs! Never underestimate the power of users to surprise you.
• Simpler is better. When you’re building a complicated application, break it down and focus on individual tasks.
• Sometimes a user needs to be guided through a process—something they will do just once, or just occasionally, for example. But for tools and user will use daily, you can sacrifice clarity and focus for speed—those users will learn the complexity quickly.