Research & Design Process
The truth is that sometimes a small team may not have taken the time to document the decision making process for new teammates to reference later, and the demands on their time might mean that they aren't available for a hands on briefing either. It's definitely not an idea situation, but I've always been someone who is willing to make lemondade when I need to.
The following process is one that I follow when it is necessary for me to build information about a product, its industry, and its users from the ground up. I do my best to make my cumulative research available and organized for on-boarding new members of the team, and I make documents or presentations about my current findings for other departments as well as the development team so that everyone can better understand the research supporting the decisions we are making with the product.
1. Start with Existing Online User Resources
With Brivity, I began by attending webinar demonstrations like a potential customer would, reading existing self-help and support articles online, and reviewing any marketing materials I could find. Though it was a slower process than a direct briefing from coworkers, I gained a lot of insight into the experience of a new user.
2. Meet, and listen to the customers
My second week at Brivity, I was offered a chance attend a trade show & conference as part of the sales team. I made notes of things attendees didn’t express interest in, which features they were most excited about, and any inquiries that I wasn’t yet familiar with yet. Between selling, I also attended educational sessions.
3. look into user behavior
Back in the office, I managed to get my hands on some data of what sorts of objects users were creating in the app and what they looked at on the marketing site. We examined things like which features were the most popular among users, which were underutilized, and how users might be using existing features in a way that we weren't expecting. We also analyzed exit survey results from trial users and longer-term clients, customer feedback on feature usability, bug reports, and feature requests.
4. Get familiar with the perceived (from the UI) and actual app architecture
I got everything up on a wall and tagged the heck out of it with post-it flags to create broad user flows based on what I had learned from my earlier research. Most users had very strong opinions about how data related in the app, and gave me ideas of how they thought it was structured, and how it should change. I wanted to understand how closely the user's perspective of the information matched that of the apps architecture. The answer to that turned out to be complicated.
5. Learn the industry standards and expectations
Understanding what your competitors do and how they are different is very important from a product development and marketing perspective.
6. Observe users using the product
We started with Generative Research—specifically with contextual inquiries—with users of the product from a large real estate team in the same building, and a couple of smaller local teams in our research pool. This provided users ranging from 2 years of familiarity with Brivity & real estate, to newbies just starting in real estate and with Brivity the day I was observing them. Generative research is important because it helps us make sure that we're actually building something people want.
I made notes of any questions trainees asked and of the explanations given. I also asked experienced users about other products they’d used and what they had liked and disliked about those in comparison to Brivity. This was followed up with Evaluative research from what analytics we had (later setting up tracking for a few more) and analyzing past feedback survey results received by sales and support.
With a better understanding of the existing product and the needs of users, I'm then able to move into the design process, which itself is sprinkled with additional research and feedback along the way.
The Design, Feedback, Design, Development feedback... Loop
The design/development process moves quickly from one step to another with the expectation of changes based on the feedback received happening between each phase. I am usually at different stages of this process for 3-10 features for mulitple products at a time.
Low Fidelity first
Add more details
High Fidelity enables testing real-world examples & aids development
Collect Feedback and Iterate
As product owner, I set up regular daily check-ins with the support team to talk about what customers were talking about and asking about them most, as well as give them information about where we were in the process with specific feature requests so that they could update users. We also used these check-ins to remind them of release times and dates and let them know if those would move outside our normal schedule. Instituting these meetings made a huge difference in how Support saw themselves as part of the research and development team; it improved communication and made the feedback loop a lot more efficient.
The best part of these meetings as a product owner and UX designer, is that they gave us good primary feedback on newly released work. If a new feature didn't have any comments or questions on how to use it within the first week, we'd check analytics to make sure it was being used, but then we could rest assured that the feature was easy to understand and met expectations. Sometimes though, it wasn't used at all—which then became a marketing question as well as a "did we just build something useless" question—and we knew we'd missed the mark a bit. Then support would give us the contact information of particularly opinionated users to follow up with. This was great, because we could ask them questions about what they thought the feature would be, why it wasn't meeting their needs, and then get some ideas on how to iterate in the future.
Rinse, wash, repeat.