A Scrappy Approach to Design

I grew up making art pixel by pixel on MS Paint (seriously, pixel by pixel). Over time, it became a tool that I really mastered — as much as someone can master maybe... the art of using a calculator. By that, I really just mean I created Paint graphics that would some times be mistaken for Photoshop quality work. I then moved onto Gimp, Photoshop, and more recently, Sketch, in hopes to be able to whip up Dribbble quality work. Yet, they all remained tools that felt like a hassle to open up, because I consistently needed to look at documentation and watch tutorials. My soul never quite vibed with them the same way I did with Paint. Until I met Figma.

I won't sit here and pretend like I'm some sort of Figma or design expert. I seriously don't know any "best practices" when it comes to designing with Figma. But I can get everything I want done with it (here’s a sample app I designed for my HCI class 👀), and that's what I'm here to share with you. Here are some scrappy tips and tricks for designing (with Figma) for noobies, to enhance your quality of life.

1. Use the pen tool to make illustrations

Nice illustrations definitely jumps to mind when I think of design and it definitely sucks wanting to design things when you're not good at drawing. If you have a picture you would love to see as an illustration, use the pen tool on Figma to trace the entire photo and you'll get something like this.

Original image

Original image

Illustration made with Figma’s Pen tool

Illustration made with Figma’s Pen tool

2. Prototype off built-in screen sizes (demo below)

If you're trying to prototype an app, think about what devices you're trying to optimize for and use the built-in screen sizes for the proper canvas to start off with. The "play" button on the top right corner lets you walkthrough your prototype in the device chosen — it really helps bring your designs to life.

3. Take advantage of high quality illustrations (demo below)

Jumping back to illustrations, beautiful illustrations really help make a page pop. Pablo Stanley has some awesome open source illustrations that anyone can use, it's as easy as pulling them up from a Figma plug-in.

4. Libraries (demo below)

Every platform has their own design language. So rather than reinventing the wheel, using community files could help you adhere to conventions.

A Figma demo of designing for different devices, using plug-ins and community files

A Figma demo of designing for different devices, using plug-ins and community files

5. document.designMode = "on"

You may know about right-clicking any page, selecting "Inspect" and manipulating HTML elements in the "Elements" tab of your browser. I often leverage this functionality to test out all design edits on web pages. But did you know if you select "Inspect", open the "Console" and type in document.designMode = "on", you'll be able to directly manipulate elements on the page? You don’t need to manipulate HTML at all, your whole page just becomes a drag and drop editor. Take a screenshot of the page to share your designs. You can even bring this back to Figma!

Directly manipulating site elements with document.designMode = “on”

Directly manipulating site elements with document.designMode = “on”

I hope these tips / tricks are modular enough that at least one of them sticks with you. But I think the main takeaway of this post is that it doesn't really matter whether you use Paint, Illustrator, Figma, or Instagram, being comfortable with a design software can come in so handy — even if it's just for something as simple as annotating day-to-day screenshots, making a quick birthday card for friends, or trying to piece things together for a website.

PM#5: Outside of Work

I love hearing about what people do at work, but I especially love hearing about what people do outside of work. This inspired Derek and I to start The Intern Podcast last year— a podcast about employees’ side hustles. And one of my ongoing questions then becomes, how can I leverage my work-work to serve other initiatives I care about outside of it?

I’ve found one way!

unnamed.png

Over the past 2 months, I have donated $1300 to 2 non-profit organizations— A.I. For Anyone and Unloop, all through volunteer hours. Not only does every employee start with $50 they can donate to any organization of their choice, Microsoft also matches every 1 volunteer hour to qualifying non-profits as a $25 donation. This means that not only am I helping them with actual volunteer work, I’m also actively donating money to the cause. 

Screen Shot 2019-07-09 at 1.11.57 PM.png

Going into my internship, I knew I wanted to dedicate my non work hours to solving problems I really cared about, with democratizing technology being my leading motivation. This translated into reaching out to A.I. For Anyone and asking to start their newsletter for them. This gave me an opportunity to kickstart an initiative, learn about AI (and interview awesome researchers), and of course, write. It has been an absolute honour moving the needle with them, and I’m excited to see where this newsletter takes us.

The first issue of our newsletter, All About AI— a newsletter aimed at demystifying and democratizing AI by improving AI literacy, comes out today. Subscribe here!

User Research

One thing I love about product management over software engineering is the ability to view projects in more holistic views. I want to understand not just how we should build something but rather, why we are building a product, and who we are building it for. That’s where user research comes into play. I’ve conducted over 30 user research and usability testing sessions during my time with 4 projects in the Microsoft Garage— working with a diverse set of Windows users, cancer researchers, and finally published a research report with Xbox research about accessibility in gaming. More recently, I’ve conducted another series of user research sessions to learn more about user needs and expectations for the docs.microsoft.com platform. 

I’ve started becoming more hyperaware of when I walk out of user research sessions feeling like I’ve lost a sense of direction for my project vs. when I leave having gained clarity and my mind is bubbling with ideas. At the end of the day, the former is bound to happen, and sessions like that could very well be why we should do these in the first place. But I’m hoping to reflect on how I can stop being the reason why the former happens.

Here is how I generally approach conducting user research:

Create a user research plan with the goal, hypotheses (optional), research details etc.

    • No leading questions

      • For example, rather than asking “Do you have any problems with x?”, which implies that a user has a poor relationship with x. Instead, ask “Tell me about your experience with x?” so they get to choose how they feel about it, and then follow it up with why.

    • Tie numbers to questions

      • Especially for more qualitative studies, tie number scales to questions (i.e. “On a scale of 1 to 5, with 1 being very poor to 5 being excellent— how do you feel about x?”) to quantify sentiments of responses after the interviews. It can be difficult to differentiate a “decently good” to a “fairly well”, but it is easy to know the difference between a rating of “2/5” and a “4/5”. Of course, scales are relative as well, but they are slightly more empirical.

    • Let them tell me a story

      • It is sometimes helpful to leave questions intentionally broad so users have the freedom to answer with anything they want. This can often reveal unidentified flaws in a product, opening up my eyes to not just to a solution I like, but rather, the solution we need.

    • Magic wand question

      • Very much like the previous point— give users the option to describe their ideal experience with x if they had a magic wand and anything is possible. This helps me understand what the desired user journey could look like, without constraining them to my own bias / questions. Although remember, users are experts of the problem space, but not necessarily the solution space.

Create a user interview guide

    • The user research plan is helpful for outlining everything I hope to get through in an interview, but the truth is, it’s difficult to keep referring to a sheet of paper when I want to foster an organic conversation with someone. So making and reading over an interview guide (a simplified version of the research plan with bold highlighted points), allows me to glance at my cheat sheet during the interview and know exactly where I am in terms of progress.

Conducting interviews

    • Don’t interrupt them

      • It can be difficult to hold myself back from steering conversations “back on topic” when I feel I’m not getting exactly the response I’m “hoping for” from a user, and they start going off on a tangent. But people speak the truth when I let them speak their heart.

    • Don’t try to fill in awkward silence

      • Sometimes user research will feel awkward— and that’s when I generally go rogue and start suggesting answers to users. I fall straight into the trap of asking leading questions, in hopes that they don’t feel bad. But after a terrible interview where I basically spoon-fed a participant all the answers, my mentor gave me the advice of just letting awkward silence happen. This worked surprisingly well. People feel obligated to come up with answers (and often even more innovative ones) because of the uncomfortable dead air.

Summarize interviews

    • I find it helpful to conduct interviews with another person so that one can ask questions, while the other focuses on note taking. This time around, we did our user research through usertesting.com which meant that I didn’t have to take notes at all, and could review the recorded interviews after each one. It also gives the flexibility of annotating the video to mark down key points.

    • I create a summary report with every interview I conducted based on (loosely depending on context) the following points:

      • Anonymous user ID (remove PII for confidentiality)

      • Background

      • What they currently do

      • What problems they have

      • What their wants are

      • Quotes

      • Other interesting observations

User research report

    • After all of my user research sessions, I sit down and draw themes amongst my observations and generate recommendations / actionable items out of my findings. This includes reviewing my hypothesis. 

    • It’s important to reflect on and share my learnings so that there is transparency in the work that I’m doing, and the team should be aware of concerns that users have. This facilitates an environment where teammates share and learn from each other’s work.

Don’t let user research be the be-all and end-all

    • It’s inevitable to have anomalies in user research findings, and that’s okay. It doesn’t mean the research should be scrapped or augmented to prove the initial hypotheses. Rather, the holistic result of the research can be used to help drive part of the decision making in creating a solution that users will love, but it should be coupled with data and metrics to ensure that a solution doesn’t just satisfy the needs of the small sample size of users that were interviewed.

Huge thank you to Sara Lerner, Den Delimarschi, Horyun Song and Melissa Boone for guiding me through all of this. I still have lots to learn. 💖

Microsoft Internship, Build 2018

I interned as a Program Manager at Microsoft's Experimental Projects Division, the Garage.

Group pic of all my best friends, aka fellow interns & our fearless leader, Stephane.

Group pic of all my best friends, aka fellow interns & our fearless leader, Stephane.

It’s the feeling of finding those who share mutual passions, those who make you laugh so hard you lose your voice for a week, those who go to the beach at 2am just to lay down and count the stars with you, people who just get it— your people. That feeling came rushing back to me every morning as I stepped foot into our office building. A series of inside jokes and silent chanting of our intern anthem (speaking of which, please listen to it while you read the rest of this post 🙏) laid the foundation of inseparable friendships. And I hope you too, will find your own Microsoft Garage.

I just came back from the Microsoft Build Developer Conference 2018, with a ticket so generously gifted to me from the incredible Cloud Developer Advocates team during my internship 🎉 . I went last year too, but this year was really something else. I sat in the audience as they announced the release of 2 AI projects we worked on during our internship— Snip Insights & Mobile Chest X-Ray Analysis. It was heartwarming to see how different teams across Microsoft have also spent the past year revolutionizing the way AI is used in our day to day workflows. But also, tears flew out of my eyes when I saw our faces on the screen credited as the team behind those 2 projects. The early mornings and late nights (not to mention, getting a flood of messages from our manager to go home) we worked have evolved from prime team bonding time, to now, products on the big screen for everyone to try at Build. Our project even made it to TechCrunch! It was at that very moment when I felt like the luckiest person in the world to be able to create such impactful projects. I never want to stop doing this.

Our pictures at Build!

Our pictures at Build!

These past 4 months have probably been one of the greatest experiences in my life. Every day of the internship held a new surprise and we never quite knew what we’d be working on or what challenges might come up, besides the fact that our team would always come out of it stronger. As the only Program Manager intern, I had the pleasure of working across all 4 project teams (Snip Insights, Cloud Chest X-Ray Analysis, HoloLens & Minecraft: Education Edition). 

This internship wasn’t an easy one. We built out our own prototypes, we sketched our own ever-changing architecture diagrams, threat models and scoped our own features, only to be (constructively) torn apart at our weekly “Dragon’s Den” style pitches to different internal teams. We did over 50 user research and usability testing sessions to continuously iterate on our features and design. We actually went through a 180-degree UI/UX change for Snip Insights 3 days before presenting our project to the CVP of Cloud AI. Needless to say, agile did us well. We passed compliance (accessibility review and testing, privacy reviews, security reviews, global readiness, code analyses, open source release review) by a hair, as we worked until exactly 5:00pm on our last day. And believe me when I say, I will never view products, and accessibility in particular, the same way ever again. I have a LOT more respect for products that go the extra mile to protect users' information, handle localization, and be accessible for all users. This internship was a life-changingly rewarding one.

The once foreign Garage desks, chairs, and kitchen had become so familiar. As I walked past the area one last time, the rush of nostalgia flushed away that familiarity and suddenly, I realized what was once the entrance had become the exit. With that being said, I know those doors will always be opened. In fact, I’ll be heading back very soon for an exciting Tweet Chat panel and to present our project at the Imagine Cup Finals! As for all the friends I made during my time here, stay in touch. The world is only so small. 😉 

Here are some bonus videos and tweets from our internship that you might enjoy!

If you too, love turning ideas into real projects, you NEED to check out the Garage.