About

Dee Sadler

I've been in the UX world for a long time and have done everything from visual design and interaction to user research, usability testing, hiring and managing teams, and mentoring of teams and individuals.

I'm a certified instructor who taught web and print applications, has facilitated dozens of Design Thinking workshops, ran UX user groups, and has spoken at many conferences and even ran my own conference. I recently spoke at Harvard Extension school and a webinar for Trinity who help out UX Bootcampers. I love being active in our community.

I have experience in UX for consumer-side mobile, financial applications, B2B applications, Ad agencies, telecommunications, web sites, and healthcare applications (serving consumers and medical professionals).

I've managed large and small teams.

My Process

1) Understand the user

For larger projects, I create a Design Plan with the who, what, when and how. First, and most importantly business lines must understand for whom they are building something. Quantitative and qualitative data like demographics, user segments to behaviors, lean-model canvases, journey maps, information from subject matter experts, any screen recording software information, any analytics, user interviews — all become inputs to things we can do to understand our users.

It is important to then synthesize that information to help the interaction designers create data-driven recommendations. What do we know — and what gaps do we have in knowledge? It’s essential to gain that understanding.

2) Hypothesize and iterate

I always have the interaction designers work with the researcher to come up with solid recommendations based on the synthesis of the research. It is the only way we can make sure the research isn't wasted. We've all seen this happen. If the UX'er is part of the synthesis (like being a note-taker for any user interviews) then they can help figure out what the measurement of success looks like for the research. I never have them start on the computer, either. Whiteboarding or , sketching on paper is always the are always good ways to make sure no one gets too attached to their own work. I’ve found it to be key to Wworking early on with Pproduct and engineering leads to ensure both business needs and whether it is the feasibility of doing some-thing.

I always start with internal usability testing. Even a drive-by test is helpful to get those early iterations done so we can move on toward true usability testing. I also never allow wireframes to be a true deliverable. Until we have done usability testing, everything is still in play for me. Even though I usually have the team do our usability testing in high fidelity, I still consider it just an assumption until we get consensus that we are headed in the right direction.

3) Solve for the user visually

I don't want to make light of visual design. It is never about the UI for me. The UI is a byproduct of good UX. It is about solving problems for the user, visually.

Is the audience male-heavy? Then many might be color-blind and thus color really matters. Are they older? Then the font size matters. Are there rollovers? Is there enough of a "hit" area for a touch device? What interactions will help users see when something new arrives in a data table? So much of visual design is solving problems visually for the user, and is not remotely about general fonts and colors. Is there a Design System? Sometimes that doesn't even matter because they aren't meant to solve every problem you have. You always have to understand the rules to break them.

4) Validate

My favorite part of the process is validating the work. A hypothesis is only as good as the validation that follows.

This is an area that — along with research — is often under-appreciated in many organizations. Of course, my team works off the research and understanding of users and their pain points, but whatever the team comes up with is just an assumption — until users agree that it is the correct assumption. This is why research and testing are so important! If the business, product, or engineering teams alone had their way...they might come close, but until we understand the tasks the user is trying to accomplish, and their pain points, motivations and behaviors...we can't change any of those things.

It isn't about the number of clicks or how much a user scrolls; those are just a perception of something that doesn't flow or make sense to them. It’s important to remember that perceptions make someone keep or throw away a bit of software. This is the part of UX that influences the ROI. We can actually prove that we can help to lower development costs — only if we are allowed to go beyond design, and do the research and the testing.

Clients

Testimonials