Conducting the Research

Having enough context and doing the right research can make all the difference in the successful implementation of a product. For me, this usually involves looking at publications, analyzing best practices & competitors, and interviewing target users. From the information I gather, I jot down my findings and start creating user persona, storyboards, and user-flows. It's also vital to consider and discuss business goals at this point, to ensure mutual understanding between all stakeholders.

Occasionally, team brainstorming sessions or even a design sprint may be necessary depending on the scope and scale of the project. After the data and information has all been recorded, I filter out and refine the ideas for creating a requirements document.

Defining the Requirements

After condensing the research down to the personas/storyboards/user-flows, I present them along with other key findings to the development team and any stakeholders. It's not always enough to be just "good", or "in accordance with best practices or industry standards", so I try to work in extra value for the user that isn't offered anywhere else; sometimes this involves taking risks, but it can also just be ensuring fast and iterative cycles that continuously adapt and improve.

If necessary, it's at this point that compromises need to be made between business and user needs. By having both a technical and business understanding, I can consult and resolve issues here between parties. When all is said and done, I create a requirements doc, tasks, and issues, using a project management system (be it Asana, Atlassian, GitHub, etc.), and assign them to team members appropriately.

Creating the Plan

I usually start off with a site map or information architecture flow to help organize the requirements visually. Creating something fast and sharing with peers is a great way of fine-tuning the details. I also test experimental hypotheses (How-Might-We's, stretch goals) at this point too, and user-test certain user interactions and flows.

Designing the Interface

Wireframes, mockups, prototypes. All with rapid review and iteration cycles in between. I make and share designs as quickly as possible to garner feedback and perspectives. For certain interactions or interfaces, I code the prototypes myself for interactive prototypes for "pixel perfect" design, animation, and timing.

They say a picture is worth a thousand words. Well an interactive prototype is worth dozens of hours of meetings and deliberation. Why show, when you can experience?

Polishing the Experience

Small issues can pile up. Some issues are so small, they can get ignored entirely. While there are definite benefits to having faster development cycles, it's good to stop every once in a while to take care of all the little things that can turn into huge problems later on (e.g. responsiveness, localization [i18n], accessibility [WCAG 2.0], design inconsistencies, etc.). During this time, I provide mentorship to the developers/designers to train everyone to be more attentive and to follow design/development guidelines.

Validating and Improving

Conducting stability/stress tests, and re-evaluating the UX on a production server is crucial, as new problems can be uncovered that didn't exist before. I also conduct regular user testing and data collection to monitor the health of new and existing features. It's a good opportunity to learn about the ever-changing needs of users, while identifying pain points.

Metrics are an easy way of revealing trends and issues, but the hard part is recording and looking at the right data. I can filter out the noise to reveal what the biggest issues are, and prioritize them using a value vs difficulty decision matrix.

It goes without saying that design is iterative; no solution is ever perfect. After testing and issue documentation, I start all over again — unless there's new problems to tackle!

My Core References

I owe a lot of what I know to online publications and literature. Here are some of my favourite and most useful books:

• UX Strategy by Jaime Levy
• The Elements of User Experience by Jesse James Garrett
• Hacking Growth by Sean Ellis and Morgan Brown
• The Visual Display of Quantitative Information, Envisioning Information, and Beautiful Evidence by Edward Tufte
• Hooked by Nir Eyal

Honourable mention goes to Design of Everyday Things by Don Norman and Don't Make Me Think by Steve Krug, which were the books that got me interested in UX.