I’ve always thought owning “user experience” as its own little silo was a bit weird. 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:

When people in the 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. The culture to be driven by people’s experiences with your product tends to be one of the hardest things to change. Luckily for me, there was some substantial work already done. The emphasis on design these days make it a bit easier, and 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.

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. For instance, we found that users just weren’t excited about our product in July, we changed our product substantially from a mobile search product. If we continue to 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). We haven’t gotten to a large user base, but when we do, 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.

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 still defining a lot of functionality. Some of them love the front-end work (especially as a respite from best programming practices, and ability to hack on something really quickly to get to testers). It goes a lot more quickly, 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 super quickly. We could 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 could make this work better.

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 just 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.

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. They tend to start out a bit more general as our problem space wasn’t well-defined at first. 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.

Tie marketing lead generation with potential testers

Though I’m pretty sure our awesome marketing person, Claire, is sick of finding testers, the generation of leads from marketing’s perspective helps with finding some testers. Since we don’t have a launched product (much less a substantial number of visitors), and are a bit lower budget on the user research, the outreach Claire has done has been super helpful. Mind, 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 (which has been more appropriate for what we’re trying to find out right now, and will change shortly). And you certainly don’t want to blast everyone who’s interested in your product constantly about testing it. She also gets a better understanding of what appeals to people and what their current behavior is like.

Open sessions to remote observers

It’s nice to have observers, to build empathy and to see what you’ve built in use. Our awesome QA guy stops in often and helps him to put him also in the mindset of actual people. The sessions are open to the team as long as the participant knows and consents to the observation.

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).

Collaborative culture

Thankfully, there was a strong collaborative culture at Riparian that was already developed when I started. One thing that can help 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!