4 Things Every UX Designer Should Know Before Integrating UXD into an Existing Product

24
4 Things Every UX Designer Should Know Before Integrating UXD into an Existing Product

Transcript of 4 Things Every UX Designer Should Know Before Integrating UXD into an Existing Product

4 Things Every UX Designer Should Know Before Integrating UXD into an Existing Product

So — You’ve been hired as the first UX designer at a company that already has an existing software product.

Congratulations! I’m sure you have no idea what to expect and are

wondering things like:

Will they like my ideas? Will the product’s usability be any good?

Luckily the company that hired me already had a successful product

— that isn’t to say that improvement didn’t need to be made from a UX perspective —

but I quickly learned four lessons that will help you prepare for what you can expect

when integrating UXD into an existing product.

Lesson #1: Introducing UXD to an Existing Product Can Be Easy (I Promise!)

Successfully implementing UXD into the product

team’s usual process can be as simple as

empowering others to create their own prototypes.

Invite others to involve you in reviews & ideation sessions to strengthen the team’s interactive design skills.

Delegate responsibilities and believe in the expertise and experience of your colleagues.

Avoid trying to do it all yourself!

Implement best practices early on.

Don’t hesitate to remind the team of design guidelines and rationale.

YOU are the advocate for your industry!

Speak to the importance of UXD across all departments via feedback meetings and

presentations for new features.

Lesson #2: Teach the Product Team to Think Like a UX Designer

Include product engineers in the building of prototypes during usability testing.

This allows them to see what you see (like key paint points) and

will help broaden the conversation on solutions.

Apply design heuristics when reviewing prototypes the team has

developed on their own.

This allows the team to use the same measures when reviewing their own work.

Listen to feedback and critique.

Trust your team’s ideas and use these opportunities to present

usability lessons that clarify your decisions.

Review research findings with members of the development team to further

illuminate and understand your craft.

Share some of your favorite UX articles that pertain to a problem your team is

currently working on to provide context

and creative thinking.

Lesson #3: Leverage Other Company Team Members

Rely on customer-facing team members for existing research and for

impromptu idea validation.

After all, these are the people who live on the front-lines for your company every single day.

Utilize data from support team members for potential usability issues

and less obvious points of friction.

Your time is valuable, so make sure you conduct internal usability tests before testing externally to

ensure test tasks align with customer-facing business processes and expectations.

Also, this can act as internal training and show

the team the value of usability testing.

Lesson #4: Learn When to Compromise (and When to Push)

Agile development hasn’t always been friendly

to traditional UX approaches, so you will need

to learn when to compromise on your approach

and when to push for more time or resources.

Compromise: Know what can be done quickly,

such as conducting usability testing with less

participants than originally desired.

Push: Something like rebuilding a new information

architecture is going to take time. Explain your rationale and approach needed to accomplish this successfully without compromising quality or exploration.

Show the impact of your approach and the quality of the results to

internal stakeholders to validate your process and build equity in your

personal brand.

Congratulations! You are now ready to make a splash at your new company and seamlessly integrate some user-centered design principles into your team’s product.

Mary Ann Tackett Sr. UX Architect at Field Nation

Proving it’s never too early to start coding, Mary Ann Tackett began teaching herself HTML at the ripe old age of 12. Working as a designer since 2003, Mary Ann has spent more than a decade transitioning from visual design to user experience architecture by working for both agencies and software products. She enjoys building cross-disciplined

design teams that tackle difficult problems and constantly push each other out of their comfort zones.

www.fieldnation.com