So you’ve conducted a round of user interviews. Great! You’ve got video or audio you can revisit if you or your partner weren’t able to jot down everything in time. Wonderful! You recorded your thoughts during the session and kept track of conclusions and interesting observations immediately after. Amazing!
(Wait, you haven’t run a user interview yet? We run User Research Sprints that help with this exact thing.)
We’ll be using a fictional story about a hotel that wants to boost its appeal among business travelers. They’ve interviewed a group of experienced travelers and are about to break down the results. This story is loosely based on the DoubleTree cookie.
You’ve written your script. You’ve screened your respondents and you’ve scheduled time with them (which you learned to do in our Guide to Recruiting Participants). You’ve got a big day of learning about your users ahead of you!
We’re going to cover what to do during the interview and what to prepare ahead of time. Preparation is important—he more confident you are, the more your respondents will trust you and feel comfortable responding.
As a consulting firm that’s been around for 17 years, Carbon Five has a unique perspective on trends in digital product development. In this post we look back on 2016 and reflect on what we’ve seen in the industry, and where we think it’s headed. Here are the the top five trends we saw in 2016.
If you have ever tried to recruit folks for a focus group or usability test, you know it can be really hard, super frustrating, and downright discouraging. But have no fear, Carbon Five is here! Before you start reaching out, you’ve got to get into the right headspace. You will probably be interacting with people that come from diverse backgrounds, and there are some unusual places you can find ready willing and able participants for your research study. A few rules of thumb will help you successfully recruit:
Empathy is at the core of Carbon Five’s design process. We use it every day to design and develop software that can help solve real problems that affect real people. We are always looking to partner with companies and organizations who also value empathy. That is why we were excited to collaborate with YouCaring, a free fundraising and crowdfunding website.
So, you’ve read the introduction to the Carbon Five Guide to User Research and you’re ready to get started. Welcome!
During this step we’ll be working through what we’re hoping to find, who we’re hoping to talk to, and what we’re hoping to ask. If you’re trying to convince someone else in your company to invest in a research project identifying the basic assumptions and outcomes like this is a great place to start.
We’ll be using the hypothetical company Delivery Healthy. Delivery Healthy is a startup that serves people who are trying to eat healthy while still ordering a lot of take-out, because they say you should write what you know.
User Research focuses on understanding user behaviors, needs, and motivations through observation techniques, task analysis, and other feedback methodologies.
User research helps us understand the constraints and opportunities of the audience we’re building for, and is a core part of building a successful product.
Let’s say you’ve got a great idea for a product. Will your users agree? How do you reach them? In order for your product to succeed, it needs product/market fit.
Defining the users you want to reach and talking to them before you build will will give you empathy and a clearer sense what your users hope to achieve using your product. It’s much easier and more effective to design with a specific person fixed in mind than a set of demographics without a distinct voice.
One month ago I was on a panel at Grace Hopper, “Startups, Big Companies, Silicon Valley, Government Contractor — What’s the right career path for you?”. I was speaking mostly to software engineers who were just entering their career post-college or transitioning from their first job. I was on the panel with four other talented software engineers from a range of job experiences, Sha-Mayn Teh (Teachers Pay Teachers), Jennifer Liu (Quizlet), Neena Parikh (Benchling), and Stephanie deWet (Pinterest). Here are some of the thoughts I personally shared with the room on how to decide on what kind of company to work for.
Working on an oldish Rails project, I came across some smelly ActiveRecord code that begged for some refactoring love. I also spent some time speeding up pages with slow/many database calls. Between those two experiences, I felt the inspiration to write-up some “Back to Basics” Rails Database Best Practices.
Rule #1: Let your Database do its Job
Databases are extremely feature rich and are really freakin fast when used properly. They’re great at filtering and sorting… and many other things. If the database can do it, it will do it way faster than doing the same thing in Ruby, or any other language for that matter.
You might have to learn a little bit about how DBs work, but honestly, you don’t have to go very deep to reap a majority of the benefits.
We generally use Postgres. What you choose is less important than getting to know it and using its features to make your product awesome. If you’re curious about Postgres, there are some good resources at the end of this post. We love it.
Our first, overarching rule: Let your database do what databases are good at, instead of doing it in Ruby.
Monolithic applications are great when you start building your company, but as time progresses, they become difficult to maintain. These codebases, as they grow, easily become Big Balls of Mud.
When building large applications in frameworks like Rails, the very convention-over-configuration design principles that made Rails such a joy to use begin to get in the way when the application grows in scope. You may be experiencing the same pains as well if:
Refactoring is difficult and tedious, because methods and classes depend on too many other classes
You have an ever-growing list of business objects that are difficult to keep in your head. In fact, nobody seems to be able to understand the system as a cohesive whole
Changing code in one area of the code leads to unexpected and unintended side effects in other areas of the code, because it’s easy to call out to global services and objects
Carbon Five is a full service software consultancy that helps startups and established organizations design, build, and ship awesome products. If you have a project you’d like us to take a look at, or are interested in joining our team, please let us know.