DESIGN Q&A

I believe designers offer tremendous value in leading teams visually, creating efficiencies and process improvements that enable us to be successful faster as one untied team. These are my thoughts based on my own unique experiences.

"How would you approach beginning with wireframes for a complex software application feature set that you know very little about?"

I would start by collaborating with the product team on what we know, understanding all vendors that may be used, analyzing and documenting technical data and information architecture to create journey maps, technical understanding and where touch points/actions will need to take place (understanding engineering constraints).

Preliminary research may still be needed and could include shadowing users to better understand their needs, meeting with customers and taking note of any pain points that could be enhanced or simplified ahead of starting the design process.

After preliminary research, a story mapping session may be beneficial, establishing epics that trickle down into actions that trickle down into the screens needed to achieve the workflow.

Once that has been completed and is understood and agreed upon by all, wireframes and reviews can take place ahead of taking it to customers for feedback. Wireframes allow ideation teams to fail and then succeed faster on establishing the UX before adding in the UI design layer.

This is preferred to take place 2 sprints ahead of the scrum team developing the work. The above helps to begin establishing foundational technical US's that can be worked ahead of adding the UI layer. This keeps the efficiency and momentum of the team going.

"How do you ensure consistency and innovation in your designs while aligning with a company's design standards and business goals?"

Request the documentation on current and overall business goals and take the time to understand them.

Pay attention to what competitors are doing by attending free product webinars, etc. to remain innovative.

Take the time to read and understand the documentation on design standards, current patterns and their usage.

If documentation is not readily available, take advantage of relevant technical training as a prerequisite for beginning UX work on a specific feature.

"How do you manage component libraries and maintain alignment across multiple teams?"

A well structured and organized component library is key. One that includes usage details, best practices for use and where they currently appear within the product line hierarchy. I would then assign a DS component library owner that maintains it, tracks it and gives regular updates to the UX team for discussion. I would also set the expectation of the need for a component library roadmap against the UX and product roadmaps that allow visibility into what features are coming, what components do we already have to support them and if not, how we can plan ahead so the component is ready for use when the work begins? These conversations should also happen around DS patterns and workflows, not just the component library.

The use of storybook is beneficial to make sure everyone is in alignment on what is in development vs. what is in the DS component library.

I would include documentation to support both, including it's usage and name of component.

Consistent naming between both storybook and the DS component library eliminates confusion when collaborating with scrum teams.

"How do you provide constructive feedback to your peers in design critiques?"

What I do that might be unique to some orgs is pay very close attention in sprint reviews and advocate that UX teams attend ALL sprint reviews. I speak up when necessary to challenge workflows or decisions that I know from expertise will be a problem. I back it up with education as to why. Example: “Did you consider reusing XYZ existing pattern for this instead? [For the group] Patterns that have proven to be successful and advocating for the reuse of those patterns has the following benefits from a UX and engineering perspective. First, it eliminates the need to train users on an entirely new workflow which will increase user adoption and decrease the strain on customer service groups to train and solve problems. Second, the reuse of patterns decreases the development time to build, allowing us to move faster and ship more features."

"How might you persuade a resistant stakeholder about your design approach?"

With a lot of engineering leadership and developers, utilizing prototypes to share with customers often faces resistance. To solve this, I like to collaborate and come to an agreement (engineering leads, product team leads, stakeholders, sales team, UX) on what we feel we should be delivering by the desired launch date. Starting with wireframes or very simple designs containing only what we perceive to be MVP based on prior research and competitive analysis. Limit distractions and exclude features that are not MVP. Review as a team and get sign off (this can take a couple versions to agree to). Do VOC calls 2 sprints ahead of development start to confirm or refine our assumptions and feedback. Doing short status update meetings a couple times during the design and feedback phase puts everyone on the same page in talking about the new feature set or product launch when conversations begin with customers.

I find that agreeing and signing off on what we will show and what we will ask, which customers are best for feedback, etc is the best way to start. Once we come back and report the findings, stakeholders are usually pleased to learn that we can simplify certain things and come out of these sessions with a clear path forward on the features that really matter.

Most appreciate knowing exactly what is necessary to build beforehand. I have done this before at eVestment with leadership where we even refined prototypes again, went back to the same customers with perfected design a second time to be extra sure. Doing this = winning because you have confirmed exactly what is needed through prototyping before the engineering time is spent building it. Customers are often honored and happy to be a part of the decision making process and this also generates excitement and buzz around the innovative features that are coming and the great things the company is working on with their input.

"How do you handle ambiguity or a lack of clear direction when designing for new features?"

I have a natural curiosity and will do as much research and gathering of information on my own, as best as I can. I have also found that utilizing the Neilson Norman UX analysis 'CSD Matrix' approach to define what we assume, what we know and what we don’t know as soon as we get started for UX review with the product owner, product manager and tech lead is a great starting point.

The idea is that you move the things you don't know to the 'what we know' column as you work through the matrix together. I like to take a first pass and fill in matrix details to get us started when we meet. Suppositions and doubts get assigned action items out of the review and we can all move faster to uncover the unknowns together. I have found that It really helps to break it up and visualize it this way.