Fly By – Solving Real Customer Problems


Below, you’ll find my slides from the Fly By presentation with speaker notes, in addition to a screen capture of the Framer.js protoyping demo I did. I hope this helps and feel free to reach out with any questions. Just to recap, here is the description of the talk.



Instead of covering UX in a broad sense, I’m going to focus on my process for maximizing one’s chances to create products that actually solve a customer problem. This process is really broken up into 6 main phases:


  1. The Eureka Moment
  2. Initial user research
  3. Use-cases and personas
  4. Establish product goals/commandments based on findings
  5. Initial design based on product commandments
  6. Lastly, and most importantly to this talk, usability testing and design iterations


I’ll be going over steps 2-5 quickly more as a means to share a process that has worked for me. However, the majority of the fly-by will be dedicated to #6- the basics of how you prototype using framer.js. 




Fly By 10.15


Fly By 10.15 (1)


I’m mainly going to talk about framer.js, a super effective tool for creating high fidelity prototypes. Prototyping is a key part of getting valuable feedback from users but usability testing (i.e testing various aspects of your prototype/product’s efficacy) is only one part of what I think is a formula to maximize your chances to create a product that solves real customer problems.


Fly By 10.15 (2)


However, before I wanted to give you a little insight into the process that I’ve picked up through projects and working at different places. I’m going to be very brief in defining these steps because I want to focus on prototyping but it will give you a foundation that you can build off of. You can easily google all the UX terminology I’m mentioning and reach out to me if you have any questions. Last little point is this isn’t going to focus on executional design and UX, it is going to focus on how to build a strong conceptual foundation based on your users that will serve as guidance when making your design decisions.


Fly By 10.15 (3)


This process outlined here is oversimplified, particularly for step 5, but gives you a sense for the sequential progression you should be following. The beauty is that each step informs the next.


Fly By 10.15 (4)


This is the moment you come up with a really exciting idea that you want to explore. You start sketching and thinking about how this concept could be realized.


Fly By 10.15 (5)


Once you have a point of view, it’s very important that you take a step back and let users validate your thinking. Immediately jump into user research and I’ll be explaining why in the following slides.


Fly By 10.15 (6)


I worked on product and design for a start up for almost two years and one of the key reasons we failed is that we introduced the customer/user way too late in the design process. I’m not going to go into the specifics but the outcome is that we did not have a realistic grasp of what we needed to actually get people to change/modify their behaviors in the music space. When you’re dealing with a saturated marketplace, your chances of success dramatically decrease if you don’t seriously take into account people’s’ preexisting behaviors and habits in the vertical you’re working in. You then validate your pre-existing hypothesis or identify new opportunities relative to the feedback you get.


So learn from my mistakes and speak to users early :).


Fly By 10.15 (7)


At ITP, there is a culture of user testing which is great but it reminds me of what failed me at Pow Wow, the venture I was just talking about, in a way. I think that’s simply because of the short-amount of time we have to churn out our work but it’s something to be conscious of when thinking about more commercially-minded products that you plan to work on.


The majority of the time, we get our valuable user insights way too late in the process. We have an idea, get some feedback from classmates and professors, and then push through and try to execute the best possible version of the idea in the time we have. Many people don’t really ever interface with users until they have a very polished product at one of the ITP shows. The problem with not getting user feedback early, and even at the start of the of your project, is the more time and resources you spend on a direction, the more psychologically attached you become to that angle.


I saw it happen with the Pow Wow team. By the time you actually do get user feedback, you’ve built up false justifications for all of these decisions you’ve made and don’t properly take the feedback into account.


Fly By 10.15 (8)


Fly By 10.15 (9)


As you interview, mark down everything that is important on post-it notes. Question topics should include:


  • background related things to the user (who are they, how technically proficient are they, are they very active in the space you’re looking into)
  • process (how to they currently do the closest version of the task you’re trying to make easier or better). Super important to understand their current behaviors.
    Other questions will depend on what vertical you’re working in
  • The most important thing is don’t ask leading questions as it will definitely skew your feedback:
    • GOOD: When do you check your email?
    • BAD: Do you check your email in the morning?



Once you’ve amasses a huge pile of post-its from your interviews, start organizing them into general buckets (i.e. background, process, ect) and associated individual post-its that are similar. Start marking post-its with stickers that touch on key insights and log the trends in the user data you see.


Fly By 10.15 (11)


Having the user as a justification for your design decisions will (should) almost always end a debate between designers. It seems to me that the difference between the inexperienced designer vs. experienced designer is how in touch with the user they are. I just started doing this initial research phase for the products I’m working on and plan to add it permanently into my workflow.


Fly By 10.15 (12)


Let your research inform what the most important archetypes and use cases you should be designing for. Here are quick descriptions of what use cases and archetypes are if you’re unfamiliar with the terms:


Use Case – The simplest way to think of a use case is how and when a user interacts with your product.


Archetype – An archetype is a variation of another term you may be familiar with, personas. Personas are fictional representations of a user segment to help designers impose design constraints when working on products. The problem is that some personas you see are solely focus on characteristics (i.e. Jim is a highly educated, 28 year old man that works in the corporate setting as a lawyer) and can include completely unnecessary pieces of information as well. Archetypes may include characteristics but are based on behaviours. That is a key difference and it allows you to design in a much more focused, accurate manner.


Fly By 10.15 (13)


Using the previous steps in the process, define the main guiding principles that serve as your reference when making design decisions. This is important if you’re working alone to make sure you remain focused on designing for particular user behaviors and not just a flexible user, and is especially important if you’re working in a team. This ensures everyone has an aligned vision for the product you’re all working on.


Take an example of the differences between the product commandments for a social app vs. a banking app. For the fake social app, you heard from your research that users wanted to be able to publish content to their friends in a quick and simple way. And for the fake banking app, you heard that security was paramount. So that means that simplicity and low barrier to entry could be product commandments for the social app and security and credibility could be commandments for the banking app.


So in case designers found themselves debating about how to execute a particular in the social app ,the product commandments would serve as a reminder to remove as many steps as possible when a user is trying to publish content. Therefore, if a feature was being presented that would be a distraction/obstacle to publishing content, you would know to oppose. And for the banking app, if designers had to make a decisions between a faster onboarding process that was less secure vs. a longer one that was more secure, they would know to choose the latter because of the credibility and security commandments.


Fly By 10.15 (14)


This step has been drastically oversimplified as actual designing has a process of its own. This is where you start evolving your initial vision for the product from the eureka phase and transform that into something that reflects all of your user findings. The design process is different for everybody but will typically include the following:


  • Wire-framming / sketching
  • Sitemaps / user flows
  • Interaction tests
  • Enough visual design to communicate the general feel/aesthetic (You will refine the visual design progressively and periodically throughout your usability testing)
  • Internal reviews on all of the following with your team or colleagues

These steps should all be considered before starting usability tests. I would google any of the terms that you’re not familiar with.


Fly By 10.15 (15)


This is where I brought everyone through the framer.js demo and I’ve provided a screen capture video below so you can get a feel for what an awesome tool it is. The video is 26 minutes long, but in reality, that’s not too bad for learning all the basics of a new prototyping tool.



Category: ITP

Submit a comment