Product Design Retrospect on ‘Twitterrain,’ a Prototype Marketing Platform
‘Twitterrain’ was never a marketing platform to begin with.
It started out with an idea my teammate Daniel proposed for our data visualization course in the Master of Information and Data Science (MIDS) program at the UC Berkeley School of Information: “What if we could visualize how people feel surrounding a given topic in real time? How cool would that be?” As cool as the initial concept might be, it was difficult for us to come up with features for the product; let alone delegate tasks for potential contributors without a user in mind. It was clear, early on, that this was our first of many product design lessons.
Product Design Lesson #1: Design with a user in mind
What differentiates good product from great is that great product enables people. Every form and function is intentional because each individual component collectively affects the users. Like all product designers who come to pass, we design these components with the intention of relieving the users’ problem.
Our users, in this case, are marketers. The problems they face is justifying to brands why they should use social media for market leads.
Talking to marketers, I was able to define tasks that could help them out in their day-to-day work. As excited as we were to implement these tasks, I realized we faced a number of constraints. First, we had ten weeks to implement this project with three people who have other obligations besides this project. Second, I was the only team member well-versed in web application development. Third, most free APIs limit the information one can see, so several of the tasks proposed by our marketer friends are not feasible unless we are willing to pay.
Instead of pushing these constraints further down the pipeline, we decided to embrace them and figure out what alternate solutions might be. This is the second product design lesson we learned.
Product Design Lesson #2: Embrace the constraints
Working with the constraints, we were able to rank tasks that are not only worthwhile for marketers to use but also within the scope of what free APIs can do. We then focused on one social media platform, Twitter, because we wanted to have a working prototype running within our time constraints. What was effective about Twitter is that Twitter tells us people’s opinion in a concise 280 characters limit over a broad spectrum of topics (even though the search time range is constrained up to seven days for the Standard version of Twitter API).
At this point, however, we hit a second roadblock as a team. Without a visual of how the product would look and feel like, no one seemed to know how a cohesive product would be formed. What’s more, we do not live nearby to each other so the only form of communication we could do as a team is through a video call. How are we going to solve this problem?
I decided to put my product designer’s hat on. Since we could not meet in person and sketch out together the different components that make up the visualizations, I looked instead at the competitive landscape and determined what interactive component works and what doesn’t. Then I designed the basic functionalities of each task in a quick sketch and showed it to my marketing friend. Once I received a thumbs-up, “you’re good to go” okay from him, I proceeded to learn Sketch (the digital design toolkit) and designed a high-fidelity mockup for my team. It was then that I realized how important researching the competitive landscape and visuals are.
Product Design Lesson #3: Research the competitive landscape
Product Design Lesson #4: Visuals help team share a cohesive vision
With a shared vision in mind, we employed our first high-fidelity visuals to evaluate how effective ‘Twitterrain’ is at completing the three tasks we defined in the beginning. We repeated the cycle of prototyping high-fidelity visuals followed by a meeting with marketers to see if the prototype fulfilled their needs before finalizing on one that we would eventually code. This iteration step was crucial to the development because we often missed one feature that did not seem effective to the user.
What we found to be the most constructive way to gain insight about a feature was to record and ask the users to perform a list of tasks without us guiding them (Thanks Andy for the tip!). It was through this process that we ended up with our final high-fidelity visuals.
Product Design Lesson #5: Design iteration brings powerful results
The iteration process does not stop there. Interaction is another component that our visuals cannot represent. Since all members were more comfortable programming than prototyping an interaction, we repeated the iteration step as before but instead of using visuals to evaluate the interaction, we deployed the marketing platform and have our users, the marketers, assessed the interaction on the website.
‘Twitterrain’ still has a long way to go before it becomes a digital product that marketers cannot live without. In order to achieve this goal, it needs to continually adapt to the rapid changes in the field and provide continual improvement in the marketers’ daily life. One way to do so is to avoid confusion. Currently our working prototype has not integrated a login function, so it does not assume that multiple users will visit the site. For example, if user A and user B visited the site and user A modified an interaction user B was seeing, user B will see the interaction changes that user A has made. In version 2 of ‘Twitterrain,’ we will address this issue with a login feature.
For those of you who are interested in our iteration process, please feel free to check out the presentations that we delivered midway through the development and in our final week. Thank you for taking the time to read my retrospective thought on this product’s design process. Any constructive feedback would be appreciated!
