When talking with fellow designers, whether it’s at meet-ups or as I’m performing a tech screen, there’s some common questions I like to ask or often get asked. I think these help give an understanding of someone’s experiences. So, why not answer these myself? I think this helps preemptively answer questions that help demonstrate my background, philosophies, and strategies.
UX is a spectrum, from research to visual design. Where do you land?
I can do all steps of the process. I’ve created research plans, interview scripts, personas, journey maps, etc. I do enjoy conducting research, but I would say my strengths and passion are more towards the design, user validation, and developer handoff side. My degree in graphic design and graphic design background certainly feed into the visual design aspects. But as someone who also loves scientific process, analyzing data, and making educated decisions, I would not be comfortable standing behind any designs I create without the research steps in place. All parts of the process have value, but I understand business perspectives that may not want all parts. Many times I can understand the need to minimize steps and can adjust my process to fit, but if there is a step I find crucial to a given project, and I’m asked to skip or minimize that step, I will evangelize to keep that step or at least make sure it is known what the risks are for skipping said step.
How do you work with a stakeholder whose opinions are different than yours?
I can design what I think is best, and a stakeholder can have a different idea of what they think is best, but neither of us can know which is right without validation testing, user feedback, and tracking defined key performance indicators to see what performs best. In a case when we disagree, I would user the stakeholder to run it through validation testing. I would make, like always, the validation testing script is neutral and non-leading, and ensure to review it with the stakeholder to make sure they agree. I will then conduct the test, gather results, present the data and then my recommendation based on the outcome. At that point, I hope the stakeholder and myself can align together, but if not, I know I have presented the best data I can gather, have presented my opinion, and will go with whatever decision the product owner will ultimately make.
What do you know about designing for accessibility?
This is a really big topic. All my design work is done with WCAG in mind, and Apple’s and Google’s accessibility best practices and framework. I believe accessibility also goes beyond the basics of color contrast and screen reader compatibility and includes making sure products are accessible for all applicable ages, experience levels, languages, culture, and socioeconomic status.
I have played a large role in defining CRi’s accessibility practice, our accessibility review process, and have been the go-to person to help solve accessibility challenges. We use automated tools to aid us, but know that accessibility is a human experience. Tools can miss issues, as well as flag issues that should be ignored within context. This is why we believe it is important to do manual reviews, at least of select number of screens and elements.
What size of teams have you worked on?
Working at CRi, we worked with businesses to build custom software solutions. CRi Solutions had its own internal team of UX designers, business analysts, product managers, project managers, QA, and developers. Our customers would also have their own teams that I would regularly meet with, and sometimes be integrated with as one large team.
The CRi team was anywhere from 1 to 3 UX designers, 2 business analysts/product managers, 2 QA testers, 5 to 8 developers (iOS, Android, web, API), and 1 to 2 project managers. When including the customer team as well, I’ve worked on teams anywhere from 5 team members to 50.
What's the difference between user experience design and product design.
There is certainly a lot of overlap between the two roles, and many companies may have user experience designers doing product design without realizing it. Different sources will describe the differences in many ways, but there’s a few key differences.
Both follow human centered design processes, but they’re invested in the actual product differently. A UX designer is focused on user satisfaction, and may only be involved designing how new functionality works. A product designer is involved throughout the life span of a product, focusing both on what works best for the user and what makes sense for the business. Product designers are involved in choosing what functions may be added, helping support developers and marketing, and can be involved in those decisions of user satisfaction vs business value.
In my line of work, a lot of my experience has been in the ux design role, but I’ve grown into the product design role as I’ve been involved in some major long term projects. Product design is incredibly fulfilling and I enjoy working with all the different teams that I get to work with while being a product designer.
What is your normal ux process when a new project comes in?
I often am involved in the initial sales process. I meet with stakeholders to ensure we have a clear upstanding of the goals. I assist with generating estimates and putting together statements of work.
Design deliverable: Statement of work
When planning for a project, I try to start with a discovery phase. This phase includes stakeholder interviews, subject matter expert interviews, competitor analysis, research and analysis of current site/app (if existing) and existing feedback and analytics. This allows us to understand the root of the problems, gives us a chance plan the rest of the project timeline, allows us to start exploring visual design languages, and make sure all parties are brought to the same page to continue forward.
Design deliverables: Research results and supporting documents, initial atomic design system guidelines, story map
Here is where we work through the “Design Thinking” and “Lean UX” processes. Where we ideate > create > validate > iterate.
I begin working through the story map to create designs. I like to start with the initial design guide and create high fidelity mockups pretty early on. In my experience, especially with a brand new project, stakeholders have a hard time viewing wireframes without wondering “but what will this really look like?” Historically, they say you should start with wireframes to avoid getting hung up on design details. But with symbols and components in tools like Sketch or Figma, it makes it incredibly quick to work with hi-fi mockups if you spend the time up front building out the design library. Once I can show what things will look like, not every screen NEEDS to be created as a high-fidelity mockup, but it really is quick.This phase also includes validation testing at intervals determined by the discovery phase. I create realistic interactive prototypes (which is also why I favor high-fidelity mockups), and then create validation test script. This can then be conducted with test participants in person, remote over screen share, or through a tool like User Testing. This works well with sprints, when we can break out the story map into sprints. As stories have their designs completed and validated, development work can then begin, usually starting just a couple sprints after design has started.
Design deliverables: Atomic design system, high fidelity mockups, user flow diagrams as necessary, validation test results
Design and development continues, following agile project management. Design continues to follow just a sprint or two ahead, creating designs, validating them, working with a business analyst to finalize the user story and acceptance criteria, then it can be handed off to a developer. As development comes across challenges, I work with them to determine solutions or potentially shift designs, as long as it doesn’t harm the user’s experience. When development comes to an end, I also do final UI review. This helps to ensure what was designed matches my expectations, but also make sure once everything is together, that it actually functions as well as indented.
This is all what I have found to work well given the types of projects I have worked on. But rarely do any two projects/companies come to me with the exact same needs, resources, and budget. So it is not unusually to deviate from the ideal process. A new project that has limited scope and timeline will flow differently than a long term project I’ve been involved with for multiple years.
Have more questions for me? I’d be happy to answer!