FAQs

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. 

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.

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.

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.

1. Sales
   

   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

2. Discovery
   

   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

3. Design

   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

4. Development
   

   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.