DEV Community: Dani Sandoval

Bookmark Beat: EP 5

Dani Sandoval — Thu, 11 Aug 2022 22:22:17 +0000

My birthday is tomorrow, so this one is going out a bit early. It's a bit shorter too... but the beat goes on 🥁

This week, I'm sharing a bit about my experience with accessible video games, prioritizing research and what I've learned - so far - from Abby Covert's new book!

If you jam to this bop, you can subscribe to updates via Substack

An intro: Legible HUDs make me 😍

Last month, I beat Ratchet and Clank: A Rift Apart. Despite having a PS5 for a while, it took me a while to pick up this fantastic showcase of its "next generation" features. From the nuanced haptics and sound effects within the controller to the gorgeous reflections on in-game surfaces, I was impressed with how immersive this game felt - despite its cartoony shell. The other thing that impressed me was its accessibility features!

As someone who is partially blind, I often turn up the contrast, enlarge the font sizes and otherwise play around with accessibility settings in the games I play. I like being able to enjoy the game without having to squint or tire out my one good eye. I think my favorite feature was being able to map accessibility toggles to the D-pad so they could quickly be turned on and off. Compared to my day-to-day operating systems (Mac/Windows) which usually require me to press some esoteric claw of a key stroke, a single tap on a button was a much-appreciated method to adjust the game to my current vision clarity (or lack thereof).

I'm really looking forward to the next big game on my wish list, God of War Ragnarok, since it seems like game studios (or, as least, the big first-party ones from Sony) are finally starting to care about making their products accessible.

Anyway...

Let's talk about UX Research again

Last week, I shared some links to help answer the question, "What's the point of a UX Research Team?" After reading this, one of this newsletter's subscribers shared an amazing post with me that I knew I had to share this week...

In Building a framework for prioritizing user research, Jeanette Fuccella highlights the research tools and mindsets that should be applied to different levels of "Risk" and "Problem Clarity". It's easy to get into a habit of just "doing what works" and mindlessly following the same research plans that have already gotten buy-in from stakeholders and/or will likely garner "good enough" results. But, instead, if we take a step back to evaluate the current state of a research question before choosing a methodology, we'll likely find a better fit to answer the question.

I've used a similar framework during portfolio presentations to describe how designers can make conducting research more effective by aligning the artifacts they produce to the questions they're trying to answer. I like how this article takes this thinking one step further by including "Problem Clarity" in its evaluation framework.

What I love most about this article is its use of diagrams to communicate and frame the discussion...

And diagrams really do help!

Over the last two weeks, I've been reading Abby Covert's book, Stuck? Diagrams help. Readers of this newsletter might recognize Abby's name from her amazing work on Practicing Information Architecture. In her most recent book, she defines a diagram as "a visual representation that helps someone" (and that "someone" can be you).

I've been feeling the pressure, working in a totally new domain with a lot of terms that I have never heard before, to try to grasp a lot of concepts (and their relationships) all at once. What I love about this book is that it describes the emotional journey of the endeavor that is "making a diagram" and makes me feel like I'm not alone.

I now realize that the diagrams I put together will help me better understand the space and, if I take a step back to consider an audience outside myself, can help others who are working with me better understand, as well.

While I'm here recommending diagrams, I'll also share a couple more resources from my Knowledge Dump - covering some of my favorite diagram tools:

Coda: Same meal, different plate... and a lot of work!

Over the weekend, I read a fascinating article about how the creator of the popular game Papers, Please (Lucas Pope, also known for creating Return of the Obra Dinn) ported his game to mobile devices. From code examples to empathy-rendering prose, this article makes me feel like I'm in good company as a designer of digital things:

...but I knew this port would require some blood. After testing my first basic carousel implementation, the arterial spray I expected from losing document management turned out to be more of a minor abrasion.

The amount of thought and care that goes into the tiniest of details reminds me of how so many designers think about their work (including myself). Even if you don't know a lot about programming, games or pixel art, it's well worth the read!

Now it's time for the...

Tweet of the week

A lot of new people working in tech are fixated on getting to work on consumer projects, but often times, the most interesting problems to solve are b2b tools that make people’s jobs/lives easier.

~ @hellojoie

Ain't that the truth, Joie!

Happy birthday to me, y'all! If you like what I'm reading and listening to, you can check out the I Am page on my website. And, if you haven't already, feel free to subscribe for future posts 🎉

Bookmark Beat: EP 4

Dani Sandoval — Sat, 06 Aug 2022 19:05:03 +0000

Wow! It's been a whole month since I started this weekly summary of my browser history... I hope y'all have learned something from reading my musings. If not, I'd love to hear what you think I should be sharing instead. If you are, I'd also love to hear from you!

This week, I'm geeking out about the purpose of user research within the context of the business, diving into the core competencies of conducting research and how to ensure the research we conduct is actually inclusive.

If you rock to this rhythm, you can subscribe to updates via Substack

An intro: Dungeons in Dragons... IN SPACE

Polygon covered, what they believe is, Dungeons and Dragons\' weirdest setting, Spelljammer, then and now. In my opinion, Eberron is way weirder... but that's not the point. The point is there's going to be a table-top campaign that's basically a Treasure Planet look-a-like.

I love table top games. They're a great way to hang out with friends and exercise the imagination muscles. I also love big ships and space. So, despite not loving the 5 edition rules, I'll likely still get the Astral Adventurer's Guide for the pretty pictures and lore!

Anyway...

What's the point of a UX Research Team?

That's what Jane Davis answers in her recent blog post. I'm a sucker for two-by-twos (2x2s) and it's worth staring at this one for a long while. Having hired external research vendors, grown a research team, and helped facilitate self-serve research for product teams, I appreciate seeing how they compare on the level of "research expertise" and "organizational context" that comes along with these staffing decisions.

I agree that an internal team, with the right practices and priorities, can be significantly more effective than outsourcing research to an agency and/or whichever PM/Designer has time. As my research team was starting to grow at Chipper, I loved this conversation from dscout to help frame the purpose of the team. At the same time, I read Matthew Godfrey's post on a having a \'research framework\' - which helped me get better at explaining why some projects took so much longer than others.

And, once a project was complete, Adam Fry-Pierce's guide on The 3 Unbroken Chains for Org Alignment For Design Teams helped me bubble up insights gathered in research projects back to the design team, product teams and the rest of the organization.

But getting "buy in" is only half the work...

You then have to actually conduct the research. Whenever a new researcher came on board, I assigned Just Enough Research to them. If you haven't read it, stop reading this newsletter and buy it. It's one of the most important books for any designer, researcher or product-aligned person could read.

As a contrast to that fully-fleshed out book, this post by Austin Z. Henley is a great intro for more technical folks who might need some convincing that research is important (or even possible). Although not a complete guide to all user research methods (this Field Guide from User Interviews is much better for that), Austin's writing style and examples makes me want to send this post to every developer I know!

Where UX strategy is all about communicating to "the business", UX tactics are more focused on getting folks on your team (like engineers) to understand what you're actually doing.

So let's do research right!

It all starts with taking your time. In tech, we've become so used to doing things as fast as possible. "Move fast and break things" was the default ethos for so long that it's easy to forget how long it takes for our brain to work on things in the background.

That's where tools like theme identification come into play. Techniques to Identify Themes in Qualitative Data is a classic paper that describes these techniques in detail. Indi Young's Removing bias from your solutions dives deeper into how to identify themes while minimizing bias.

To explore this space further, I highly recommend A Practical Guide to Inclusive Research or join a community of practice focused on inclusion - like HmntyCntrd.

Coda: Music theory for folks like me

I've been playing guitar for over 15 years and I still can't read music. I know my scales and pretty much every chord. But if you would have asked me last week why something it's called "a 13th note", I would have shrugged and said "I dunno, but it sounds good".

Thanks to this Practical Guide to Music Theory and Improvisation, I actually know now! Piano is also becoming less of an impenetrable mess in my brain. So I think I'm on the right track.

I read through this guide with a pack of sticky notes and a MIDI keyboard - I recommend anyone who is interested to do the same.

Here's your...

Tweet of the week

I wish more had been documented about the non-white male contributions to early design/UX et al. When I read "histories" they always perpetuate what was most visible, yet I know countless women and POC who have 20+ year-long careers that have been all but erased from the story.

~ @leeloowrites

Thanks for reading! If you'd like to keep up with my bookmarks and listening list more often, you can check out my I Am page. Oh, and don't forget to subscribe 👋🏼

Bookmark Beat: EP 3

Dani Sandoval — Sat, 30 Jul 2022 21:21:15 +0000

Welcome to the third week of the Bookmark Beat! A (mostly) weekly summary of my browser history. This week, I reflect on how to progress through the design career ladder and how to manage new designers as they make their way through it. I also found some great case studies in the bookmark bin - spanning the years, the front- and back-end...

If you think this beat is catchy, you can subscribe to updates via Substack

An intro: Joni Mitchell makes me cry

I woke up on Monday to a tweeted video that captured a moment I was very lucky to be alive for... Joni Mitchell performing again!

Joni was joined on stage by Brandi Carlile to sing and play a couple of her hits - including the tear-jerking "Both Sides Now". The fine folks at the Newport Folk Festival released an amazing recording of the performance on Tuesday. Every time I watch it I cry. Something about Joni's gentle timbre, surrounded by a phenomenal group of musicians, makes me choke up half-way through the first verse.

Anyway...

I've been thinking about "professional development"

and how silly it is that we think of it as something separate from the work we do. The larger the company, the more likely there's a budget for you, called "prodev", that you can use to buy books, courses or even take time off work to learn. But, having worked at startups for most of my career, I've always found something a bit off about this sort of "mandatory fun".

Yet, it's performance review season, layoffs are hitting companies big and small, and everyone is trying to set goals, prove that they've hit goals, or learn new skills in an attempt to "stay relevant" in a challenging job market.

And, it's not like our field makes it easy. There's new tools and technology all the time. Every new designer is pressured to learn everything there is to know about VR/AR, FinTech, AI, and whatever other area we think is still hiring, despite everything else. Thanks to sites like ADPList, progression.fyi and levels.fyi, though, it's become clearer than ever that the skills you need to succeed in Design are not domain-specific, nor are they unique to any particular medium... instead, the vast majority of skills that show up in these frameworks are cross-disciplinary and most certainly not unique to our discipline.

So, that's great news if you're coming from another field! You'll stand out much more against your fellow bootcamp applicants if you can actually work well with others and manage your own task list. And as you progress in these foundational skills, your "level of impact" will increase - leading to higher and higher roles - as described in Jing Jin's amazing post: Career ladder from junior to director — guidance for UX professionals

But what if there is a skills gap? Then what?

If you're asking this question, you're probably a people manager. You've maybe seen progression in these foundational skills... or maybe it really is the "craft" skills that a certain employee is lacking in. I think it's important to actually take a step back and really identify the source of the problem. In this oldie-but-a-goodie, Don Clark breaks down the common reasons why employees don't perform well:

Lack of Skills: This is mainly an employer responsibility — the need to supply training or learning opportunities.
Lack of Information: This is also an employer responsibility — need to supply information or train how to use or collect readily available information.
Motivational Issues: Employer and employee jointly responsible — requires mutual discussion.
Personal Issues: Employee responsibility — needs to take charge of life
Environmental Issues: Employer Responsibility — redesign is needed.

Note how more than half of these are actually the employers responsibility. Yet, we've become so focused on "managing up" and "taking initiative" that we can sometimes forget that "the work" must go both ways. I've been loving Jasmine Friedl's Performance Management as a New Manager series to break down this work, more specifically.

Getting down off my soapbox

To geek out about some old case studies!

Redesigning Evernote for iOS describes what Kara Hodecker "learned redesigning the Evernote mobile experience, twice!"
Designing Windows 95’S User Interface is a rollercoaster of pre-agile hijinks that makes me really happy I live in a world where "rapid iteration" is not some crazy hail mary pass that execs throw at a looming deadline.
Never Use a Warning When you Mean Undo is not so much a case study but a reminder that computers have memory for a reason. We were discussing an error message today at work and we realized we could replace it with just a generous undo... it made me happy and reminded me of this post.

Finally, this case study, Ethnography is Key for Computer-to-Computer Communication that Enhances Veteran Experiences, reminded me of the amazing work that goes on behind the scenes to make spectacular developer experiences. User research is key, even when your users are developers interacting with your API.

Some other great resources for this type of work:

Documenting APIs by GOV.UK
Streamline Your Teams\' API Design and Strategy with User-Centered Documentation by me!

Coda: Background beats

Ever since listening to TED's Far Flung: The secret Somali mixtapes, I've been jamming out to this Spotify playlist inspired by the mountain of cassettes and reel-to-reel recordings buried in Hargisa during the Somalian civil war.

It's a great story and the playlist really packs a punch!

Let's wrap this up with the...

Tweet of the week

I used DALL·E 2's inpainting feature to make a version of Eames Powers of Ten, leaving the prompts in to explain each of the 57 steps. #DALLE @OpenAI #AI

~ @adampickard

That's all for this week! If you're looking for a bunch of free "professional development", check out my Knowledge Dump! Oh, and don't forget to subscribe ✌🏼

Bookmark Beat: EP 2

Dani Sandoval — Fri, 22 Jul 2022 18:00:00 +0000

It's the second week of Bookmark Beat! A (mostly) weekly summary of my browser history. This week, I'll be skimming through my bookmarks to share a bit about "customer profiles", accessibility on the web, and how I'm playing around with my Mac menu bar to be more focused...

If you find yourself nodding along to this beat, you can subscribe to updates via Substack

An intro: Paying for things is (still) too hard

Design is more than just the graphical interfaces we interact with every day. A lot of design (or lack thereof) is lurking under the surface... From APIs to SDKs, FTP servers to Mainframes, the world (and money, specifically) now runs on the speed of light (or, more accurately, fiber optic cables strung along the bottom of the ocean).

It's for this reason that I loved reading 20 years of payment processing problems. This article covers all the ways that humans have tried to solve the problem of "sending money securely over the internet" - including all the ways that's gone horribly wrong. It's a great read... even if it is a bit technically dense at times 😅

There must be something in the water...

Because two of the newsletters I follow, Proof of Concept and The Beautiful Mess, posted about customer profiles.

In David Hoang's article, The skeptic, customer, and fan, three models of a "user" are sketched out and elaborated on. Users can move between these profiles or stay comfortably within them. David's point is that you can better understand a user's feedback if you align it with the profile you think it came from.

In John Cutler's post, TBM 30/52: The Customer Profile Trap, this sort of profile-based thinking is applied to marketing. He describes the common problem of "when you design something for everyone, you are actually designing for no-one". He also describes how to avoid this problem by finding overlapping messages between discrete customer profiles.

I like these ideas.

Have you reviewed your app/site for accessibility problems lately?

Probably not. Fortunately, we have folks like Marcy Sutton to get the fire under our butts and show us, with screen recordings and all, how to audit a site from the comfort of our desktop browser. Check out her Accessibility Review of kexp.org, if you haven't already seen it.

While I was thinking about it, I dug into some of my historical bookmarks to find my favorite resources for #a11y - Smashing Magazine's A Smashing Guide to Accessibility and Planning for Accessibility from A List Apart are a great place to start... if you're building an app/site right now and need something to get up-and-running with accessible components quickly, check out C&PAC (the Copy and Paste Accessible Code site).

My new focus setup

A few months ago, I bought a subscription to SetApp. There were a couple apps on there that I really wanted and having one tool to manage a bunch of my subscriptions saves me from having to dive into my email to find the licenses for Mac apps I already paid for (most notably, Bartender and Better Touch Tool).

With such a low barrier to entry to trying new apps, and the newly-attained large gaps in my calendar for "focus time", I figured I'd install Timeless. The conceit of this tool is to hide the actual Mac clock and replace it with something that just shows time ranges.

I find that, when there's only a half hour or so left in a focus block, I start to lose steam, goof off, or decide to "not start" something because "I won't have enough time to really get into it anyway". This is a silly mentality and, after downloading and installing Timeless, I hoped that I would finally stop thinking this way...

Unfortunately, the latest version of Mac OS X broke my little heart 💔

The clock is no longer optional for Big Sur and newer macOS. It drives the do not disturb shortcut (option + select) and summons the Notification Center when selected.

~ A kind human on StackOverflow

So I did what that post suggested and turned my menu bar's clock into an analog one. Together with Timeless, it looks like this:

This worked great! I found myself flowing between tasks seamlessly without worrying about whether or not I can complete something before my next break.

Then I attended a meeting. I had no idea how long the meeting had been going when I brought up a topic and was nervous that we might run over! This normally isn't a problem, since I can look at the clock and estimate how long a given topic might take to discuss. But since I only had a time range at the top of my screen, I was totally in the dark.

Also, during user interviews, keeping track of the number of seconds a given task takes, or when to move onto the next part of the interview, is extremely important.

So I went to the internet to find a way to show and hide the digital clock at-will... and find it, I did!

I have moved the app, ToggleClock to my Dock - next to my Zoom.app icon and, one of my new favorite tools, Unblah.

So a quick tap of the clock:

and my menu bar looks like this:

Having the seconds on the clock helps me when I'm facilitating conversations and tracking time-to-completion in prototype testing... It can easily be turned on in settings (and I'm sure there's a way to turn it on/off with applescript):

Let's wrap this up with the...

Tweet of the week

I am begging you to stop calling designs or business concepts "sexy"
...
Humbly suggesting that "glamorous" does the job without creeping anyone out

~ @nicolarushton

That's all for this week! If you liked this post, you might also like my shared Notion doc, Knowledge Dump, that I usually send to folks I mentor. Don't forget to subscribe 😉

Bookmark Beat: EP 1

Dani Sandoval — Sun, 17 Jul 2022 21:14:54 +0000

Welcome to the Bookmark Beat! A (mostly) weekly summary of my browser history. Along with this curated catalog of links, I've added my thoughts and tried to create some semblance of a narrative.

If you like this sort of thing, you can subscribe to updates via Substack

An intro on leadership

So, the James Webb Space Telescope launched this week. Its pictures are absolutely incredible! But an even more incredible part of the JWST is the story behind it... the New York Time's exposé on Gregory Robinson, He Fixed NASA's Giant Space Telescope Reluctantly, tells a captivating story of one person's struggle to motivate others by building rapport and making room for mistakes.

Anyway...

A bit about my job

I have a new job now. It's great! I'm learning a lot about a completely new domain... Data! I've had the pleasure of running a few user interviews and shadowing many others. One of the interview participants pointed us to Uber's Databook and, since then, I've been diving into the deep end with this resource and so many like it.

But, one thing I've noticed so far is, just like many fields within computer science and technology, there's a lot of language... and it's not very consistent.

It turns out most of designing something is understanding the thing in the first place!

Words are hard. They're also the foundational elements of our shared reality. By naming things we encapsulate the thing itself into a word or phrase that allows us to recall it. If we don't get our words right, we can't think about problems correctly or even have a chance to solve them!

So, I'm coming to terms with the concept of Language/Market fit. There's lots of tools to move towards it, but I've been circling around taxonomies as a way to get there with my team. So far, there's been a bit of formal work in creating a glossary for the Data field:

but not a whole lot...

Language can help us build brands, communicate ideas to our users and name variables/components in our design systems (as we all know, naming things is hard!). Speaking of which, I'm super excited to finish reading through Superfriendly's Design System in 90 days. I think we can do it even faster at Stemma, since our team is so small 😉

Another place that language influences us is in the way that we talk about our own internal tools and processes. The folks at ~~GraphCMS~~ hygraph have a great article about that, actually, as they walk through how they organize their files and projects in Figma.

Coda: Hey FinTech, you OK?

I found out via Dan Hon's newsletter that, "at WWDC this week Apple announced Apple Pay Later, which is a bit like if someone decided to make a bicycle for the {bank, credit card, wallet, consumer credit financing industry}."

A few days later, I saw this report on CNN: Red flag: Consumers are using Buy Now, Pay Later to cover everyday expenses. Which, combined with the global economic crisis that seems to be slowly creeping its head over the other terrifying news we get week-to-week, feels like a bit of validation that privatizing our economic systems might not be the best thing...

Anyway, even if you disagree with me, I highly recommend reading this Harvard Kennedy School working paper that was buried in the article. FinTech is weird since it's both a product of, and a pushback against, government regulation. So finding a balance between "innovation" and "I don't want my money to disappear / be useless" is something I'm still thinking about - despite not designing for a FinTech product anymore.

Tweet of the week

This one is a great thread to rabbit hole down…

If you could recommend one book not written by Don Norman, Alan Cooper, or Steve Krug to those new to #UX or #design, what would you recommend? Why? #uxTalk

~ @DougCollinsUX

Hope you enjoyed this! I certainly did. It's nice to take a break and actually read the bookmarks I save. If you want a running list, you can check out my 'I am' page anytime. Until next time!

Redesigning the Design Interview

Dani Sandoval — Mon, 21 Jun 2021 23:51:59 +0000

Author's Note: This post has some interactive elements and is best viewed on the canonical URL

As the first designer at a growing startup (Discuss.io) and as a consultant for much larger companies (Liberty Mutual, Humana, USAF), I've seen first hand how difficult it can be to hire designers. Now, as the first designer at another growing startup (Chipper Cash), I have a lot more of a say in how we hire for our design team.

Over the past few months, throughout dozens of interviews, I've reflected on the ways that the design industry creates unnecessary barriers within our hiring practices. Having been on both sides of the table, I'd like to share what problems we've identified in the "standard" design interview loop and how we're working to address these problems at Chipper Cash.

The "standard" design interview loop

Below, I've outlined what most designers go through when they're looking for a new job...

Hiring starts with an application screening - where the recruiter or hiring manager takes a look at a large number of candidates' resumes and portfolios. Based on a rubric (or sometimes just a "gut feel"), these screeners will select a handful of candidates to move onto at least one "screening" call with the recruiter and/or hiring manager.

If this screening goes well, the candidate is usually required to do a portfolio review with all or some of the members of the "interview loop" - the members of the company that are responsible for asking questions of the candidate and helping the hiring manager make their decision.

Then the most time-consuming part of the loop begins. Sometimes combined with the portfolio review, the whiteboard interview is a chance for candidates to solve a problem that they will likely never face in the role they're being hired for. Over the course of an hour, the candidate is asked to "redesign an ATM" or "design an app to coordinate ping-pong games at the office".

If the whiteboard challenge is overcome, the candidate is then sent home with a "take home assignment". Sometimes the assignment is just a higher fidelity version of the whiteboard challenge, other times it's a completely new assignment. Either way, the candidate is expected to come back with some polished work to present to the next round of interviewers so that they can defend their design decisions, discuss how they might test them, and answer any number of hypotheticals that the company has written in their interview guide.

Finally, the candidate is allowed to participate in the types of interviews that are more common across all industries. These "culture" and "technical" interviews usually have questions like, "Tell me about a time that you had to settle a dispute" or "Compare the differences between mobile-first and responsive design." These interviews are usually the first chance that a candidate has to meet the people that they might actually work with on a daily basis, ask about the company itself and how their potential future colleagues feel about their jobs.

At most large companies (like Google), it can take 8-12 weeks from the first interview until the offer is negotiated and signed.

Problems with the "standard" interview loop

For those just entering the field, this process can feel like a lot of new things, all at once. For designers who are looking for a new job, the amount of time required to change jobs can make it difficult (if not impossible) to transition to a new position or company.

But the process outlined above is not just overwhelming. It's also...

Inequitable - Not everyone has the time to create/update their portfolio, schedule time off at their existing job or work on "take home" assignments outside of work. By insisting that this amount of work is required to be hired, we're screening out candidates who are working multiple jobs or in hostile work environments, have family to take care of, or have hobbies outside of work.
Disrespectful - When a candidate is rejected after 5-10 hours of time dedicated to the process over multiple weeks, it can feel like a complete waste of time. When design challenges are actually representative of a "real world" situation for the company, it can also feel like candidates are being asked to work for free.
Focused on the wrong things - Not all design roles are the same. Some roles are more UX-oriented while others focus on visuals. Due to the collaborative nature of design, past work shown in a portfolio review rarely represents the skills required for a given role and is usually judged on a surface level - prioritizing work that "looks good" over the actual design process.

Combined with the fact that many candidates are applying to multiple positions at once, these problems beg the question...

Why do we do this to each other?

After reflecting on all the ways that this hiring process disadvantages diverse applicants, I had to take a step back and ask how we got here. What are we trying to achieve with the current hiring process?

At Chipper, we identified that we were really interested in three things:

Avoiding misalignment
- Does the candidate share our values?
- Can they resolve conflicts cross-culturally?
- Can we afford them?
Strong foundations in the design process
- Can they break down problems into more accomplishable steps?
- Can they prioritize problems based on user needs?
- Do they respond well to feedback?
- Can they "ship it" (e.g. work with devs, adjust to business constraints, etc.)?
Filling gaps in our team
- What skills do they have already (UX? Visual? Platform-specific expertise?)
- What skills do they want to learn/grow in to? (IC? Manager? New design skillsets?)

What we're trying

By listing out these goals, we were able to reframe them in a "how might we" statement:

How might we create a more equitable hiring process that respects candidates' time while ensuring that we hire designers with the skills, values and interests needed for the roles we're trying to fill?

After a few rounds of experimentation, we came up with a process that requires no "take home" work, combines the "culture", "technical", and "whiteboard" interviews into a series of interviews with the minimal number of interviewers...

First off, the hiring manager decides on the priorities for the role in concert with our Talent team (the "recruiters"). Application materials are reviewed according to the requirements of the job post:

For more visual roles, portfolios will be reviewed. Otherwise, they are not.
Years of experience are not used to screen candidates in/out of the role.

Then candidates get to talk to a member of the Talent team. The role is discussed in detail and the timing of the interview loop is agreed on. This call is to make sure the candidate understands the scope of the position before they commit to the rest of the interview loop.

For roles with a visual design focus:

The hiring manager call is framed with the prompt, "Show me one project that stands out to you as your best work. Feel free to skip the process, if that's not relevant. There will be a more formal portfolio review in the full-day interview. "

For roles without a visual design focus:

The call with the hiring manager starts with, "Please share one or two projects that you think demonstrate your understanding of research, design and collaboration. You can show these if you want, or speak to them. "

The portfolio review is for visual design roles only

In this panel-style, the candidate shares 2-4 pieces of work that demonstrate their understanding of research, design and collaboration with all members of the interview loop. The graders that are assigned for this interview have an understanding of Chipper's Design Principles and how to look for them within a portfolio.

The "take home" assignment is replaced by two "workshop" style interviews

First, a member of the Product or Growth team presents a business problem framed by data. The candidate can ask questions, discuss options and frame a problem that can be solved by design.

Then, a follow up call with a member of the Design team starts by asking the candidate to introduce the problem in the context of a Design Studio. The candidate and the interviewer must then sketch mutliple possible solutions to the design problem and share their sketches with one another.

At the end, the candidate is asked imagine how the solution(s) might be built and next steps they'd take if it were there project.

**There are only two other interviews**

One is the "Values" interview. Usually run by a member of our Operations team, this interview focuses on common and unique situations that occur in a remote startup. Candidates are asked how they might deal with them or have dealt with them in the past.

The other interview is with a member of our Engineer team. In this call, the candidate and interviewer discuss tradeoffs between the worlds of design and engineering. Past experiences are compared to ideal situations as the interview focuses on how the two roles are involved in product development.

Conclusions

With less steps and specific goals for each interview, we were easily able to incorporate our company's goals for interviewing designers into this more streamlined process. The recruiter screen up-front gives candidates an opportunity to opt-out early if they feel like the role isn't a good fit for them, or ask for accommodations if the timing/approach doesn't work for them.

We already have a number of plans to modify the "design studio" interview to work for disabled candidates - including a text-only script writing studio that assesses the same skills without the visual element.

What do you think? Do you prefer this approach? Did we miss something totally obvious? Feel free to reach out!

Getting Hugo up and running and styling the home page

Dani Sandoval — Tue, 16 Jun 2020 12:04:48 +0000

Intro

In this series, I walk through the steps (and tools) it took to...

Research a tech stack that made it easy to comply to web standards
Get Hugo up and running and styling the home page (this post)
Migrate my blog from Medium and my portfolio from my old site
Style the blog and portfolio using SCSS
Design and build out the portfolio browsing experience
Migrate the only dynamic content on my site, the "I am..." page
Deploy to netlify, set up DNS and redirect rules
(Cross-)Post content on others' sites and get feedback on drafts

A Hugo "Hello World"

Hugo has a great Quick Start guide that lets you copy and paste commands into your terminal to get started. Broken down into 7 steps, the guide only requires you to make one choice... A THEME

Although the guide uses the Ananke theme as an example, I found myself wary of using a theme that would force me to understand somebody else's styling and possibly undo their work to make my site look the way I wanted.

So I started from scratch with the blank theme.

I later found out that hugo doesn't require you to use a theme at all and, instead will look for the same folders that a theme might provide (layouts, static, etc.) in your root folder, if no theme is configured (docs).

Themes are essentially a way to encapsulate the content-agnostic code for your site into its own tidy directory.

From zero to hero: the home page (S)CSS

Pretty much everything I write and release with my name on it is made with two fonts: Raleway and Merriweather. So, of course, the first thing I did was add those fonts to the page:

Code to enable fonts in baseof layout

  <!-- baseof.html -->
    <link href="https://fonts.googleapis.com/css?family=Raleway" rel="stylesheet">
    <link href="https://fonts.googleapis.com/css?family=Merriweather" rel="stylesheet">

Code to enable fonts in main.scss

  /* main.scss */
  body {  
      font-family: 'Merriweather', serif;
  }


  h1, h2, h3, h4, h5, h6 {
      font-family: 'Raleway', sans-serif;
  }

The new "blank" theme:

I also added SCSS support (more info):

Code to enable SCSS


    {{- $sassOptions := dict "targetPath" "assets/css/main.css" -}}

    {{- if (eq (getenv "HUGO_ENV") "production") -}}
      {{- $sassOptions = merge $sassOptions (dict "outputStyle" "compressed") -}}
    {{- else -}}
      {{- $sassOptions = merge $sassOptions (dict "enableSourceMap" true) -}}
    {{- end -}}

    {{- $style := resources.Get "css/main.scss" | toCSS $sassOptions -}}

    {{- if (eq (getenv "HUGO_ENV") "production") -}}
      {{- $style = $style | postCSS | fingerprint -}}
    {{- end }}

  // postcss.config.js
  module.exports = {
    plugins: {
      autoprefixer: {
        browsers: [
          "last 2 versions",
          "Explorer &gt;= 8",
        ]
      }
    },
  }

The content you see in the screenshot, above, is the default theme content. My next step was to re-add the content from my original site. First, the header and my color palette:

HTML content for header component



    <a href="{{%20.Site.BaseURL%20}}">
        <img src="/img/logo.png">
    </a>

        {{ .Site.Title }}
        {{ with .Site.Menus.main }}
        <ul>
            {{ range . }}
            <li><a href="{{%20.URL%20|%20relURL%20}}">{{ .Name }}</a></li>
            {{ end }}
        </ul>
        {{ end }}

The CSS is broken up into two files:

/* main.scss */
@import "layout/index.scss";
@import "components/header.scss";

index.scss

  /* layout/index.scss  */
  @import "../tokens.scss";

  html {
      background: $color-background-dark;
      box-sizing: border-box;
      color: $color-font;
  }

  *, *:before, *:after {
      box-sizing: inherit;
  }

  body {     
      font-family: $font-paragraph;
  }

  h1, h2, h3, h4, h5, h6 {
      font-family: $font-heading;
  }

  a {
      color: $color-primary;

      &amp;:hover, &amp;:focus {
          color: $color-secondary;
      }
  }

  main {
      margin-top: 7em;
  }

header.scss

  /* components/header.scss */
  @import "../tokens.scss";

  header {
      display: flex;
      position: fixed;
      z-index: $elevation-header;

      align-items: center;
      top: 0;
      left: 0;
      width: 100%;

      padding: 0.5em;

      background-color: $color-header-background;
      @include elevation(4);

      .logo-nav {
          img {
              width: 4.5em;
              height: auto;
              margin: 0 0.45em 0 0.2em;
          }
      }

      .site-title {
          font-family: $font-heading;
          font-weight: 700;
          font-size: 1.7rem;
          letter-spacing: 0.018rem;
          padding-left: 0.15em;
      }

      nav {
          display: flex;
          flex-direction: column;

          ul {
              display: inline-block;
              list-style: none;
              margin: 0;
              margin-left: -0.15em;
              padding: 0.6em 0;
          }

          li {
              display: inline;
              padding: 0.25em 0.45em;

              a {
                  font-family: $font-heading;
                  letter-spacing: 0.024rem;
                  text-transform: uppercase;
                  text-decoration: none;
              }
          }
      }
  }

Here's the header:

I decided to use SCSS variables to make it easy to modify things across the site with very small changes. This let me experiment with things, later on, like deciding which font to use for the lower-heirarchy headers (like h4-h6).

Also note the use of semantic html within the header component and styles. This makes it easy for screen readers to digest the page. Add to that auto-generated navigation using hugo's templating syntax and we're left with a very minimal code base.

Copying over the content from my old site, I added in some CSS Grid, with fallbacks (and normalize.scss) for older browsers and mobile layouts:

Home page layout


  {{ define "main" }}

    <h1>{{.Title}}</h1>
    {{ with .Params.subtitle }}
    <span>{{.}}</span>
    {{ end }}

      {{.Content}}


  {{ partial "sidebar.html" . }}
  {{ partial "honors.html" . }}
  {{ end }}

Sidebar component




        <img src="/img/profile.jpg">

            <h1>Dani<br><a href="https://dev.to/d3sandoval" rel="noopener noreferrer">@d3sandoval</a>
</h1>
            <h2>Product Designer</h2>
            <h3>Pivotal Labs (VMware)</h3>
            <h4>Cambridge, MA</h4>

Honors component



    <h2>Honors</h2>

        {{ range .Site.Data.honors }}

            <a href="url" rel="noopener noreferrer">
                <img src="{{%20.logo%20}}" alt="{{ .organization }} logo">
                <h2>{{ .title }}</h2>
                <h3>{{ .organization }}</h3>
            </a>
            <p>{{ .description }}</p>

        {{ end }}

As before, the SCSS files are broken out for maintainability:

/* main.scss */
@import "lib/normalize.scss";

@import "layout/index.scss";

@import "components/header.scss";
@import "components/honors.scss";
@import "components/sidebar.scss";

Homepage/global styles

/* layout/index.scss */
@import "../lib/tokens.scss";

html {
    background: $color-background-dark;
    color: $color-font;

    // prettify fonts: https://developer.mozilla.org/en-US/docs/Web/CSS/font-smooth
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
}

body {     
    font-family: $font-paragraph;

    padding: 0 40px;
    max-width: 1080px;
    margin: 0 auto;

    display: grid;
    grid-template-columns: 3fr 1fr;
    grid-gap: 60px;
    align-items: start;

    main {
        grid-column: 1;
        margin-top: 7em;
    }

    aside {
        margin-top: 7em;
    }

    footer {
        grid-column: 1 / auto;
    }

    section.honors {
        grid-column: 1 / span 2;

        width: 100vw;
        position: relative;
        left: 50%;
        right: 50%;
        margin-left: -50vw;
        margin-right: -50vw;
    }

    @media #{$breakpoint-mobile} {
        grid-gap: 8px;

        main {
            grid-column: 1 / span 2;
        }
        aside {
            margin-top: 24px;
            grid-row: 2;
        }
    }
}

h1 {
    font-family: $font-heading;
}

h2, h3, h4, h5, h6 {
    font-weight: 400;
    font-family: $font-heading;
}

p {
    font-size: 0.95rem;
    line-height: 1.5;
}

a {
    color: $color-primary;
    text-decoration: none;

    &amp;:hover, &amp;:focus {
        color: $color-secondary;
    }
}

Sidebar styles

/* components/sidebar.scss */
aside {
    .profile {
        img {
            border-radius: 50%;
            width: 100%;
            height: auto;

            // fallback for non-grid browsers
            max-width: 200px;
            @supports (display: grid) {
                max-width: unset;
            }
        }

        .info {
            &amp; &gt; * {
                margin: 0;
            }

            .name {
                margin: 8px 0;
                line-height: 1;
            }
            .job {
                margin-bottom: 4px;
            }
        }
    }

    @media #{$breakpoint-mobile} {
        .profile {
            img {
                max-width: 200px;

                display: block;
                float: left;
                margin-right: 0.87em;
            }

            .info {
                display: inline-block;

                h1 {
                    padding-top: 0.4em;
                }
            }
        }
    }
}

Honors styles

/* components/honors.scss */
.honors {
    margin-top: 60px;

    &gt; h2 {
        font-size: 2em;
        margin: 0;
        margin-left: 80px;
        border-bottom: 1px solid rgba(255, 255, 255, 0.8);

        @media #{$breakpoint-tablet} {
            margin-left: 40px;
        }
    }

    .honors-list {
        display: flex;
        padding: 0 80px;
        overflow-x: scroll;
        scroll-padding: 0 50%;
        scroll-snap-type: x mandatory;

        /* Horizontal Scroll Indicator */
        background-image: linear-gradient(to right, $color-background-dark, $color-background-dark), linear-gradient(to right, $color-background-dark, $color-background-dark), linear-gradient(to right, rgba(0, 0, 20, .87), rgba(255, 255, 255, 0)), linear-gradient(to left, rgba(0, 0, 20, .87), rgba(255, 255, 255, 0));
        /* Shadows */
        /* Shadow covers */
        background-position: left center, right center, left center, right center;
        background-repeat: no-repeat;
        background-color: $color-background-dark;
        background-size: 20px 100%, 20px 100%, 10px 100%, 10px 100%;
        background-attachment: local, local, scroll, scroll;

        .honor-item {
            scroll-snap-align: center;
            display: inline-block;

            min-width: 16em;
            padding: 2em 0;

            text-align: center;

            img {
                height: 64px;
            }

            h2 {
                color: #fff;
                margin: 0;
            }

            h3 {
                margin: 0.4em 0 0 0;
            }
        }
    }
}

The home page content (zoomed out to show the entire page):

The fallback layout:

Note that the home page content is just a markdown file and the honors list is a JSON file in the data directory. You can view that file, along with the rest of the code base during this iteration, over on GitHub.

Next up: the great migration

In my next post, I'll discuss the tradeoffs of hosting a blog on Medium, how I exported and converted the posts into standard markdown, and mourning the loss of my custom markdown parser.

Spoiler alert: It turns out, anything you could do with a custom markdown parser can usually be done much more easily with the tools built into a static site generator!

Why I chose to use Hugo and SCSS instead of React

Dani Sandoval — Wed, 15 Apr 2020 12:29:44 +0000

Every time I rebuild my website, I think that I've found the perfect solution to show off my portfolio, write and share my blog, and create a corner of the web that I can truly call my own.

Yet, my last website (which was custom-built from React tools) made me realize that a website's architecture can prevent its content from being accessible for all users...

In this series, I will walk through the steps (and tools) it took to...

Research a tech stack that made it easy to comply to web standards (this post)
Get Hugo up and running and styling the home page
Migrate my blog from Medium and my portfolio from my old site
Style the blog and portfolio using SCSS
Design and build out the portfolio browsing experience
Migrate the only dynamic content on my site, the "I am..." page
Deploy to netlify, set up DNS and redirect rules
(Cross-)Post content on others' sites and get feedback on drafts

The problem: React is too flexible, yet some of its tooling is way too opinionated

As a Product Designer, a proponent of semantic HTML and a lean software zealot, it gave me a bit of heartburn to see how bloated my website had become. What started as a fun side project to teach myself React eventually morphed into a custom markdown rendering pipeline that required an always-running node server and a Redis cache!

At first, I strayed away from all-in-one frameworks like Gatsby to avoid bloat and boilerplate in the code I had to write. Yet, when I found myself fighting against what Next.js's opinion of a static site should be, I realized that the amount of configuration required to customize the look and feel of my website made it hard to focus on one thing at a time...

Want a sticky header? Install helmet. Need a loading bar for dynamic content? Guess I'll grab nprogress for that. Want to write markdown for your content? react-markdown feels like a good choice.

Each one of these tools had its own API and learning curve and I still for the life of me could not figure out to do CSS Animations!

Eventually, I grabbed Material-UI to reduce the number of choices I had to make. But if I wanted to customize anything to look different, I had to read pages of documentation just to update some nested element's border radius.

The pivot: focus on the content

So I took a step back and asked myself. What was I spending so much time on? Why was I so obsessed with all these little things when my site was essentially just...

A front page (including a bio and a list of honors)
A link to a blog (hosted on Medium)
A portfolio home page and its children portoflio posts
The "I am..." page (which shows my Last.fm and Wallabag feeds)

I steeled myself against sunk cost fallacy and asked, "what is the bare minimum that I need to display this content and make writing new content easier?

The hero: the static site generator

Although Next.js has static site generation built-in, the way I was rendering the markdown made it very difficult to be flexible in my posts. What if I wanted to embed an iframe? Welp! Gotta write a new function for react-markdown for that!

There had to be some other tool that had solved the markdown parsing problem for me... A bit of ducking led me to the following options:

Jekyll (Ruby, an oldie but a goodie)
11ty (Javascript, the new hotness)
Hugo (Golang, and therefore FAST)

I spent a lot of time reading the docs for each of these (along with a various other SSGs that didn't make this top 3 list). I had used them all on projects in the past but this time I brought my own designer/content-first lens to the table.

So let's get started...

Jekyll (Quickstart)

Instructions:

Install a full Ruby development environment.

Install Jekyll and bundler gems. ...

Yikes. This is a lot of setup for something that claims to be "just your content."

11ty (Getting Started)

Eleventy is available on npm and requires version 8 of Node.js or higher
...
Congratulations—you made something with Eleventy! Now put it to work with templating syntax, front matter, and data files.

This was pretty straightforward but also makes me nervous. Coming from a site with too much flexibility, the "start from scratch" nature of 11ty's setup make nervous.

Hugo (Features)

Hugo is for people that prefer writing in a text editor over a browser.

Hugo is for people who want to hand code their own website without worrying about setting up complicated runtimes, dependencies and databases.

Hugo is for people building a blog, a company site, a portfolio site, documentation, a single landing page, or a website with thousands of pages.

This ethos really spoke to me as a designer and hugo's technical choices "walked the walk" here. Rather than starting from scratch and needing "version 8 of Node.js or higher" (like 11ty) or requiring me to "Install a full Ruby development environment" (like Jekyll), Hugo is just a binary file (see Installation).

As someone who switches computers (and operating systems) frequently, a zero-dependency tool with a focus on speed of setup and content authoring (👋 LiveReload) hooked me with its simplicity.

Next up: my kingdom for a theme!

In my next post, I'll cover why I chose to setup Hugo with a blank theme and add my own layers of paint... Spoiler alert: Designers are picky!

Content Warning: If it's been a while since you wrote plain HTML/CSS, the simplicity of the next few posts may scare you (and possibly cause you to swear off ever writing client-side rendered websites again).

Working from home in a time of uncertainty

Dani Sandoval — Tue, 24 Mar 2020 14:21:30 +0000

For those working from home for the first time or (like me) are returning to work from home due to COVID-19, you may not realize that the best thing you can do to stay focused is to be flexible and kind to yourself.

After scrambling for a space where your background won't expose your entire life to your coworkers, you may have spent the better part of this week reading the hundreds of articles with advice on how to work from home effectively. Despite working from home for most of 2018-2019, I found myself doing the same thing—attempting to find comfort in the "tech tips" and "survival hacks" that filled my news feed.

I noticed, however, that these articles didn't cover one of the most important things that I learned while working from home. It wasn't the Pomodoro technique or the Getting Things Done method that kept me on task, nor was it tracking my sleep cycle or a mid-morning meditation that gave me the energy I needed. To remain productive, sane and (even sometimes) joyful, I had to recognize that I wasn't perfect.

The following list describes the "release valves" I use to relieve the pressures that build up throughout the day—the expectations that I've set for myself that I may not live up to.

1. Make your routine flexible

I start every morning with a routine that goes something like this:

Wake up
Shower (and shave, if necessary)
Read, draw and/or journal (with coffee!)
Stretch
Start breakfast
Get dressed
Finish & eat breakfast
Take the dogs out
Do the dishes
Personal projects (if there's time)
Start work

This routine is 3 hours long but it can be squeezed into 2 hours, if needed. Alternatively, I can remove things like reading or working on personal projects, if I want to spend more time stretching or feel like sleeping in.

Sometimes, after taking the dogs out, I'll realize that it's 8 o' clock already and time to start the work day! Other times, maybe when there's less dishes to do or the doggies do their business quickly, I'll have 30-45 minutes to read the news, work on an open-source project or write a blog post (like this one!)

It really just depends on the day, and that's okay. Once I accepted the fact that this routine is flexible it got a lot easier to stick to it.

2. Start work at the same time, let your team know when that changes

Teams work best when they share a set of core hours. Whether it's 2 or 8 hours of overlap, being able to reliably get a response from a teammate during the hours we've all agreed on makes working together remotely much more efficient and pleasant.

To be a good teammate, it's important to respect these core hours and to be honest when something comes up that'll affect that. If, for example, a lunch break is taking a bit longer (due to having to go to three different stores to find toilet paper), I make sure to let my team know that I'll be starting late.

This does two things:

It demonstrates that I respect others' time.
It makes it more likely that others will let me know when they're running late.

If you've ever been on the other side of a message with no reply, you'll have empathy for the person pinging you to ask "if you'll be joining standup"

Remote work requires over-communication. For this reason, I like to have my team's messaging app installed on my phone, so that I always have a reliable way of letting them know when I'll be deviating from core hours.

3. Pair with others often

Remote work can get lonely. Whenever possible, I try to find ways to pair on tasks with others. Extreme Programming (XP) practices like pairing do not only apply to software developers.

I've found that the same outcomes that come from pair programming—like fewer distractions, higher quality work products and increased information flow within a team—can also be garnered from pairing with product managers, other designers and programmers on things other than code.

During a daily standup meeting or via direct messages throughout the day, I'll try to find time with my teammates to pair on my own work or work that they have on their plate. Even if it's just 30 minutes of my day, having that time to connect with members of my team one-on-one helps us stay on the same page and trust one another with difficult decisions.

4. Try timing yourself (and maybe turn off notifications)

Sometimes there's nobody to pair with or a task just makes more sense to do on my own. In these cases, I've found that it's best to "time box" to stay focused on the task and not get distracted by other ancillary pieces of work—or worse, Twitter!

Instead of setting an arbitrary amount of time in which to do a task, I've found it's better to time myself forwards using a tool like Toggl, or just a simple stopwatch and sticky note.

Seeing the number increment upward with a bit of text to remind me what I'm working on is usually enough of an emotional tether to keep myself from clicking that red badge on an email or messaging application.

That being said, if there's too much distraction from notifications, it's easy to quickly turn on "Do Not Disturb" (with a keystroke on Mac or a desktop shortcut on Windows). Just remember to turn it off after your current task is done!

In times like these, it's also easier than ever to get pulled into the news. In the past, I've used StayFocusd to keep myself from habitually opening Twitter. There's also tools like News Feed Eradicator if a task involves using social media but I'd like to avoid getting pulled into distracting conversations.

5. Take breaks, and remind others when you're on one

When working from home, it can be easy to forget to take a break. Since working at Pivotal Labs, I've learned that taking just 10 minutes away from the computer can help solve even the most difficult of problems.

To avoid burnout and back pain, I take at least one break in the morning and one in the afternoon. When I'm doing lots of small tasks, I may need to take more frequent, but shorter, breaks. These breaks make changing contexts from one task to another easier than just staring at the screen trying to force my mind to shift directions.

Since I'm never sure when the right time to take a break is, it's difficult to set them up in a calendar for others on my team to see. Some teams that I've been on prefer that people taking breaks post in a messaging app's dedicated channel.

This "break channel" can be good for two reasons:

It lets everyone know who is unavailable (and by contrast, who is available) at any given moment.
It reminders other team members that they should consider taking a break, maybe even remotely together!

In situations where teammates do not post at break times, I still do not hesitate to tell others when I'm on one. If I get a message while walking the dog or taking a walk around the house, I'll quickly respond with a message like, "on a break now, will be back in 10 minutes".

These techniques can be summarized in two words, "over-communication" and "patience". Over-communication ensures that the things I might think are obvious are made obvious to others; while being patient with myself, my team and others I work with has made it easy to adapt to the ever-changing environment of remote work.

If this helped you, please let me know via email or comment below!

Do you have your own tips on working from home? I'd love to hear them! I also found this curated page from Notion and this amazing self-care focused post from Alice Goldfuss to be super helpful, this week.