Image via Heritage of Japan

I've always found it weird that so many companies consider "user experience" be solely the domain of UX engineers. Shouldn't everyone be pushing the experience further with their own strengths? Although Riparian Data is still constantly reworking its own culture in relation to user experience, here are a few things we've tried that have helped to embed UX throughout our organization:

1) Get everyone in the organization to see the value of UX-centered design

When people in an organization truly buy into the premise that building better experiences for users will increase the organization's chance for success, the UX work really can begin. Changing the culture to make it driven by people's experiences with your product tends to be diffcult, though luckily for me, some substantial work has already been done. The emphasis on design these days makes convincing those holding traditionally non-design-oriented positions of the user experience's importance a bit easier (also, previous generation of UX and IAers have made huge strides here). It seems like an easy premise to accept and pretty common-sensical, but what tends to be lost is allocating resources to user research and taking into account the findings.

2) Know that  product metrics are rooted in users

If a majority of users who played with our product wouldn't recommend the product to someone, we go back to the drawing board and iterate more fundamentally. If we do well on such user-centered metrics, we iterate on the other observations that we made (difficulties with the interface and other opportunities for growth). Then, once we have a large user base, we can do more quantitative analysis alongside the qualitative testing. By tying product direction directly into user research, people kept thinking and asking about what the user experience would be and what unmet needs we would meet.

3) Start a semi-parallel prototype upstream to determine strategy

Because of the makeup of our team, I am usually able to team up with a developer to make interactive prototypes ahead of the actual, scalable implementation. This works for us since we don't have a fully-developed product yet and are still defining a lot of functionality. Plus, some of our devs love the front-end work (especially as a respite from best programming practices, and the chance to hack on something really quickly to get to testers). Working with a developer means the prototyping goes fastter, and we're able to really collaborate to make something even better. Sometimes an idea was much better in wireframes than actually coded up, and we're able to change it right away. We can validate functionality and whether the design aligns with users' needs before we have to actually implement a more robust back-end for it.

These sort of quick prototypes also create a more direct, tangible connection to what's in the pipeline in the next few weeks. Coworkers feel more connected to people, and understand what's being tested because those are the only things that are coded up. It allows for iteration before production-level code and to give some breathing room for designs. This, however, does necessitate constant communication between the groups, and not becoming a silo of doing quick and dirty prototypes without feeding into the broader product. We're still working out the communication hurdles here a little, but with a bit more elbow grease from my end, we can make this work.

4) Develop an internal lexicon

Like how we develop a lexicon for users, it's super helpful to develop a lexicon internally. It builds a sense of community, as well as a common understanding of what you're talking about. We probably still need to work on this. This can (and should) be different from the lexicon that you use with users, because we're all different people. Usually, developers have different mental models from your user base. Maybe people won't like this, and I'll come under fire for it, but I feel comfortable with using Lorem Ipsum with internal mockups with the developers I'm working with, because we're also constantly talking and reworking the prototypes. It saves me time from finding and making content. Of course, this changes a bit when working with users, but we also develop a test account that's more aligned with most of our target users.

5) Use and update personas

On occasion, I'll find a user behavior trend that I didn't get from the more upfront user research, and will update the personas accordingly. When we started working on Gander, our personas were more general than they are today, as our problem space wasn't as well-defined. That being said, I could be better at embedding personas in our day-to-day conversation, and it's something to constantly work on.

But something cool that happened when our QA person, Mike, started: he had this great idea to walk through the product with each persona when trying to find problems. My findings and recommendations also get tied to personas.

6) Tie marketing lead generation with potential testers

Though I'm pretty sure Claire is sick of finding testers, the generation of leads from marketing helps with finding some testers. Since we don't have a launched product and are a bit lower budget on the user research, the outreach Claire has done has been super helpful. Mind you, it's a bit confusing between people who just want to beta test your product versus people who are willing to sit through a moderated session. And you certainly don't want to blast everyone who's interested in your product constantly about testing it. But, along with recruiting testers, mining the marketing leads and data also helps illuminate what appeals to people and what their current behavior is like.

7) Open sessions to remote observers

It's nice to have observers, both to build empathy with the testers and to see what you've built in use. Our awesome QA guy stops in often and it helps him to be able to put himself in the mindset of actual people. User testing sessions are open to the team as long as the participant knows and consents to the observation.

8) Make sure to test the biggest assumptions first

Especially in earlier stage designs, when strategy is informed strongly by user tests, it's easy to fall into task analysis of smaller things. The first thing that we tested was the basic assumption that it meets user needs. These require far more open-ended and exploratory sessions. The smaller interactions, of course, are noted and worked over in a more exploratory mode. I tend to do more structured tasks when our design is more firmly rooted. This strongly ties into Lean UX, and also informs what prototype to make (what to include, and what to exclude).

9) Advocate for and stick with a collaborative culture

Thankfully, there was already a strong collaborative culture at Riparian when I started. One thing that can help foster this is to share ownership of ideas and to try to exterminate "my idea" or "my design." Although it can be a little irksome when someone offers sketches at first, I take a breath, and try to dig at why-- much like understanding our users-- to incorporate feedback from these stakeholders as well. It might not be from a user perspective, but it comes from a relevant perspective to potentially pull a core concept out of. It's also super helpful as the only UXer to make sure I didn't miss something (which happens in one-week iterations). I'm a firm believer that the more you bounce and shape products with people, the better it gets.

These were some things that I've found helpful so far, and will continue to add to the list as I continue to try to improve how I do things. Let me know below if you have any suggestions!

Comment