About Me

Mobile: 1+ (801) 541-9131

Passionate about delighting users, using research to drive product direction, and creating extraordinary designs and strategies—I craft solutions that meet user needs, product requirements, and business goals. With a thirst for learning and a drive for improving human interaction, I ensure that product usability is attained through intuitive and functional interfaces.

Over 15 years experience in the field of visual design, and 5 years in UX design and web development has informed me how to effectively craft meaningful user experiences. Additionally, with agency experience and occasionally freelancing across a wide range of industries—I‘ve developed a business acuity and unique perspective to share with clients. Through this experience, I‘ve gained insightful skills in interpersonal communication, empathy, and critical thinking. I use these skills to build consensus with stakeholders, while staying committed to best practices and user-centered process refinement.

My strengths are in the areas of user-centered and responsive design, graphical user interfaces, wireframes and prototyping, design sprints, brand identity, design systems, interaction design, information architecture, and user research. I have indispensable experience working on complex SaaS, mobile applications, marketing campaigns, and websites. I am proficient in front-end development languages such as HTML, CSS, and JavaScript, along with popular frameworks; and I'm familiar with the Agile/Scrum development process in collaboration with product managers and engineers.

I‘m looking to use my creative, analytical, and big-thinking skills along with a strong product team to take on more challenging projects. I would love the opportunity to discuss your organization‘s creative needs further.

My UX Design Process

Though every project is different and may require varying degrees of thoroughness, my process has four major stages: 1) Discovery, 2) Design/Validation, 3) Development, and 4) Usability Testing. Very few developers follow the Waterfall approach anymore, as most are employing Agile methodologies. As a result, UX practitioners must adapt their traditional methods as well—into always evolving “Lean UX” methodologies. Often the size and makeup of the team along with the duration of the development sprints will have an effect on how compressed the activities are for the UX design team. Team makeup affects what specific roles the UX Designer (one hat to many hats) has in the process, and it’s important to define those roles at the beginning of the project. The size and scope of the product component being designed whether an Epic, Feature, or regular User Story also determines how much lead time is needed by the design team. In Lean UX, the focus is on greater team collaboration (daily standups, design sprints), and obtaining feedback early and fast in order to make quick decisions. It tends to be more rapid and iterative in nature than traditional UX. Less emphasis is given on the level of detail in deliverables, while concentrating more on changes to improve the product faster. We create problem statements, identify our assumptions, create hypotheses, and estimate risk. Resources are maximized while allowing for experimentation in developing the most basic version of the concept that produces valuable results (MVP), and building from there.

Project Kickoff

Often just before embarking on a new user story, I’ve discussed the idea with the Product Manager and agree to put the project into my pipeline. I create new design tasks in project management software such as Visual Studio Team Services, JIRA, Trello, etc. This helps me to plan out my estimated timeline for the Product Manager to track my progress and keeps me focused on time-boxing broken down activities. If something is looking like it will take longer than expected, I can alert the Product Manager immediately. It’s important to stay at least one sprint ahead of developers to give adequate time for UX design activities.

Discovery

In the first stage, I’m trying to uncover the big picture (like the industry and business case/goals). I find out who are the product stakeholders (such as product managers, developers, executives/client, other departments, and customers/users), interviewing them to understand how success will be measured and invite them to be part of this journey. I’m conducting research on who the users are—what are their needs, goals, motivations, and behaviors. If it’s an existing product, I try to conduct some usability testing to get immediate feedback on areas needing improvement, and audit the product against known best practices. On both new and existing products, surveys are a good tool for gauging the perception of effectiveness of the product in meeting user needs, and what desires users have toward improving the experience. Creating personas and user flows help to keep the user and their behaviors in the front of everyone’s mind while working towards a solution. I often store these documents into a sharing folder like Dropbox, Google Drive, Office 365, Evernote or Confluence.

Design

In the second stage sometimes there tends to be some bleed over from the last stage, often going back-and-forth to get the details needed to formulate a good design. The size and scope of the problem I’m designing sometimes necessitates a Design Sprint or Design Spike in order to leverage resources and balance workloads to come up with a collaborative solution. At the top of my mind when designing is how to make the product functional, intuitive, useful, and delightful.

I give much thought to the hierarchy of information—how it’s structured, labeled, and organized in a way that makes logical sense to the user. I like to employ card sorting at this stage to see how the user would divide or group types of information. Sitemaps are created from this information. I also map out interaction flows, illustrating the number of steps needed to perform a task and how many screens I need to design in order achieve the solution.

From there, I can extrapolate what the navigation should entail along with it’s relationship to the layout of other compositional elements like images and content. I generate a wireframe to communicate this concept, sometimes creating an interactive prototype that I can go validate with a few users or at least a product expert. If I get it wrong, no worries because I didn’t invest a lot of time into aesthetics. Only after I’ve addressed any issues or inconsistencies, do I begin adding color and start refining the UI into higher fidelity—typically using Sketch and UXPin or InVision.

Once a design has been validated, I write as much detail as necessary in the form of specifications or documentation for the developer to build out my design. While I’m designing the front-end, I’m either drawing upon a living style guide or design system; or I’m making notes to add the new elements into a design system with the accompanying HTML, CSS, JS, as a developer reference. Because it’s a living document, continuous improvements are being made but having a style guide will ensure consistency across the application during development. Sometimes I’m the person to write this code or sometimes I work with a front-end developer to write it. I like the design system to give the developers context into why a UI or branded element looks the way it does, along with it's appropriate use.

Design - Validation

Though validation is ideally going on throughout the entire process (why I don’t consider it a phase in itself), it’s extremely important before passing off a design over to development. I prefer to have feedback from at least 5 users before handing off to developers, as a quality control measure it really helps buffer the risk of costly mistakes in development. The design is generally scrutinized at this point to determine if the idea breaks down or if more thought needs to be given to the design. Generally a user group is targeted for moderated or unmoderated usability testing or in some cases an A/B test in order to observe their behaviors while performing a task. Rarely is a design 100% perfect on the first try, and often requires tweaking based on user feedback. The size and scope of the user story often dictates the time needed to perform adequate testing.

Development

In the third stage, generally the Product Manager approved the design and proceeds to add it to the development sprint pipeline. I prepare the finished mockups for Sprint Grooming and assist the Product Manager in writing the problem statement for the user story along with acceptance criteria. I generate zip files of the necessary assets and attach it to the user story. I publish links to the final mockups and associated specifications and documentation in UXPin or InVision and attach those to the user story as well. Usually at this time I begin my next user story while this one is in development. While development happens, I support the PM in the Scrum cycles of Sprint Planning, Grooming, Review, and Retrospective to ensure the design intent is being met and addressing any issues that arise during development. Occasionally a new asset may need to be generated to address unforeseen circumstances during development, but I try to avoid this as much as possible. Developers typically give me a demonstration or screenshot for quality control purposes. I respond with any feedback in the product management platform, email, or Slack, while keeping the other team members in the loop.

Usability Testing

In the fourth and last stage, is sometimes the first stage of the next project. Taking what we’ve learned from the design and development process, the code is usually deployed from a development or staging environment to a beta environment—sometimes with a feature toggle on the backend or limited access for some targeted users to test the new feature. Again, usability testing or sometimes even A/B testing methods are used to determine the effectiveness of the new feature before enabling it for all users in a production environment. We anticipate any bugs or fixes that might need to addressed on the design and development teams. Once testing is completed and Product Manager has given the sign-off we move on to the next project or user story.

Thank you for your interest! I'll get back to you shortly.

↑Back to Top