Be ready to accept design system help

11 August 2019, in Design | Add a comment »

A cross-team design system can only flourish if people from outside the systems team are properly equipped to participate and contribute to the system.

These contributions can take different formats: suggestions, feedback, bug reports, proposals for new components, etc. — and you should be ready for them as soon as you kickstart your design system.

Be ready from the start

I’ve never heard of a design system team that isn’t strapped for time, so my guess is that if people from outside the team have the time and disposition to contribute, you better be ready for them.

Start planning for this from the beginning — don’t wait until you have all the components and all the documentation “done” to accept help.

If someone comes to you and tells you they can help — they may have a slower week, have some spare time, or there’s a specific thing in the system they need very soon and are keen to help with — you should be ready and not say “let me get back to you on that”.

Not just design and code

Remember that contributing doesn’t just mean providing final design specs and coded components. It can mean other things, such as:

  • Improving and reviewing documentation
  • Testing components in real life and submitting feedback and bug reports
  • Gathering information for further design work (for example: how are people using tabs right now, which use cases does the system have to account for, etc.)
  • Explore different design directions for a specific component
  • And so much more!

“Start here”

Many open source repos include the labels “good first issue” and “help needed”. These are excellent indicators that make external contributors confident that they are following the right steps to help.

“help wanted” and “good first issue” labels in Airbnb’s React Sketch.app repo.

Different levels of commitment

Consider the amount of time someone has to spare, and triage your work items accordingly.

Triaged issues in the Kubernetes community content repo.

I’ve seen open source GitHub repos where open tickets have difficulty level or time estimate labels, which makes it super easy for contributors to know what’s the best issue to work on.

If someone has a free morning, you don’t want them to focus on a task that may take one week to complete. If they have one available day every week, you could potentially hand them over a task that is not time sensitive, but that may take 2 or 3 days to complete.

Spending time carefully triaging your tickets will mean contributors can pick up an issue that they know they can finish.

Where to get started

If you are going to evaluate contributions based on certain requirements, then write the requirements down and share them with everyone. It’s only fair that, if someone is going to spend time helping you, they know how their work will be reviewed. Consider documenting:

  • Getting started information: everything you need to set up the development environment, design tools, access to projects, etc.
  • Documentation process: how to edit documentation, writing style guide
  • Coding guidelines: standards, browser support, accessibility checklists
  • Where to get help: if someone gets stuck and needs to ask a question, who and where can they go to

As you receive contributions that are missing things or don’t pass your tests, remember to update your contribution documentation to avoid further similar issues.

Being a good citizen

As for any online and offline community where people will interact with each other, you should have a code of conduct in place that can be enforced. What kind of behaviour will you not tolerate? Who can people go to if there’s a problem? And what are the steps you will take if something goes wrong? Think about all of these in advance, so that you know what to do if someone breaks the rules.

Iterate, iterate, iterate

Just as you would for a component, if a process isn’t working, make it better.

As more and more people contribute to your system, you’ll start to hear feedback that you should act on to make the steps easier.

Are people having trouble finding your documentation, or understanding them? Do they keep asking the same question? Do proposals consistently break some of your design guidelines? Do proposals lack refinement or consideration of a variety of scenarios? These are likely not the fault of those contributing, but rather an opportunity for you to improve documentation and communication with people outside of the design system team. Be more vocal and more transparent about your processes, present work in progress, describe your process and how you get to what your team considers a good, complete proposal.

A good way to keep improving your processes is to maintain a regular cadence of retrospective meetings, where participants from different areas (designers, PMs, engineers, etc.) can voice what they feel went well and what could be improved in the past few weeks. This is sadly a step that is often skipped when working in sprints, but, when done well, is key for working better together.

You won’t fix all the issues in a day (or even in one sprint), but the more you advocate for good design, good code, and collaboration, and the more contributions you accept, the better they will be.

My secret to remembering my achievements — write them down

7 May 2019, in Work method | Add a comment »

Since starting 5th Grade in Portugal in the 90s, I dread self-evaluations. To this day, every time, I feel I minimise (or just forget!) my achievements—and never guess what “bad stuff” I did (I’ve heard everything, from the classic “be less aggressive” to “eat lunch with your mates” and “learn to let go”).

Blogging and keeping to-do lists makes things a little bit easier, as I can go back and remember what I’ve done for the past 6–12 months by glancing at articles and notes. But it always feels rushed and like I’m missing the bigger picture.

So I’ve started writing down my achievements and advise anyone that feels similarly about performance reviews to do the same.

How I keep track of achievements

I keep a note on Simplenote with the title “Achievements”. Then once every few days, usually at the start/end of the week, I write down what I’ve done. I divide the list in quarters (Jan-Mar, Apr-Jun, etc.), so it’s easier to scan.

I don’t write down every little task, but things like small projects that I helped complete, that I did on my own, or that I championed.

I also write down achievements that I expect to complete within the next few months — things that will make me happy and good to do, and things that will have a positive impact on my team and my company. It’s good to have this regular reminder of what I think it’s important, as we can easily get distracted and lose focus on our day to day.

Since I’ve started doing this I’m surprised at how much I have achieved (not what I have “done” or “delivered”). I’m certain I would forget many items on my list if I had to think about it while looking at a blank performance evaluation form.

Try it, and tell me if it works for you too.

My notes on Rachel Andrew’s “The New CSS Layout”

9 October 2018, in CSS, Resources, Reviews | Add a comment »

“The New CSS Layout” was released when I was about to embark on the challenge of refactoring an old site to be responsive and have grid support and support for old browsers. Yikes! I wasn’t looking forward to the faff that I assumed this kind of challenge involved, so I was more than pleased to have a book to guide me.

By the time I read the book in preparation for my adventure, I had already watched all of Rachel’s video tutorials, and I still found the book filled in gaps in my knowledge. Maybe it’s because I read books more carefully than watch videos or read blog posts but I recommend it to anyone who’s starting to work with grid (which, by now, should be all of us).

I like that the book starts with a brief trip down memory lane, helping to contextualise and explain how CSS layout was achieved previously to the advent of grid and flexbox.

I found the chapter which delves deeper into the subject of old browser support (“Chapter 7: Embrace the future”) particularly useful for my task at hand. I still can’t believe how painless it was to add basic support with only a few lines of CSS.

Just like other A Book Apart publications, “The New CSS Layout” does an excellent job at taking you from newbie to confident at its subject. The book won’t turn you automatically into a pro at CSS Grid Layout, which, as you may have guessed, only practice, trial and error, many times over will.

I only fairly recently started using grid in production and client work and am completely converted. And this wouldn’t have been possible without Rachel Andrew’s relentless publishing of resources on the subject.

These days, when creating CSS layouts, I keep 3 tabs open at all times:

And “The New CSS Layout” gave me the foundational knowledge that I needed to get started with grid more confidently. Thank you, Rachel. ????????

My notes from UX London 2018

29 May 2018, in Events | Add a comment »

I had the pleasure to attend UX London for the second time last week, and, as with any other Clearleft event, it didn’t disappoint. The speakers, the workshops, the food, and the coffee: ????????

My notes are a bit scattered, as I tried to pay attention to what was being said, and sometimes I forgot to write things down for the whole talk (I’m sorry, speakers). They are imperfect, made mainly for me, but here they are.

Aarron Walter (@aarron), “Story First”

  • Data stays in our head, but not as long as a story does
  • When you have clarity about the broad vision you can be more agile
  • Shared mythology is important in a company
  • A roadmap tells us what and when, but not why
  • Collective understanding is hard to come by

Kate Rutter (@katerutter), “Finding the Narrative in Numbers: Making the Most of Metrics”

  • How do we know that our work is working?
  • None of the numbers tells us if the product is working for customers (downloads, sign ups, time on site)
  • Book: Lean analytics – user centred approach
  • Metrics should be unique to your business
  • What can a customer do with our product that they can’t do without it?
  • The holy grail is to intentionally move a metric
  • Use metrics as design material, before we start designing
  • Book: UX for lean start ups

Krystal Higgins (@kryshiggins), “Onboarding for the long run”

  • Onboarding should be: multiple events; diverse methods; long term guidance
  • Familiarise, learn, convert, guide
  • Spaced repetition:
    • Reinforce core concepts over time to maximise retention (of information)
  • Reference: “Minimising change aversion for the Google Drive launch”
  • Diverse onboarding toolkit: good defaults; inline onboarding; reactive guidance; proactive guidance; on-demand guidance
  • Where does onboarding end? Don’t design onboarding for the first run only

Navin Iyengar (@navin_), “Design like a Scientist: A/B Testing UX at Netflix”

  • Observe real world data and draw your own conclusions
  • Work is a series of experiments instead of projects
  • Learn reliable information about how to read the world that allows to predict future behaviour
  • Scientific method: hypothesis, experiment, result
  • In product design world, both proving true or false hypothesis is good
  • Asking someone’s opinion has biases (user interviews), what they say doesn’t mean what they’ll do
  • Develop a hypothesis: surveys, trends in data, interviews, ethnography
  • Test a hypothesis: a/b testing

Paul Adams (@padday), “The End of Navel Gazing”

  • We need to stop having an existential crisis
  • UX is not in the middle, unlike what Venn diagrams say
  • Leadership is in the middle
  • Sales team know our product better than our product team
  • Same for support team
  • UX is just one voice of the user
  • Make multidisciplinary decisions

Ame Elliott (@ameellio), “Trust Me: Building Trust with UX Design + Security”

  • When receiving a email from Google, don’t know what a message from Google is supposed to sound like
  • Maybe this was done this way so different teams have autonomy, but doesn’t build consistency and trust
  • Understand risks to users
  • Lead through design

Amber Case (@caseorganic), “Designing Calm Technology”

  • Technology should use only the least amount of our attention
  • Notifications that intrude on other people’s attention not just your own
  • Machines shouldn’t act like humans
  • Humans shouldn’t act like machines
  • Technologies shouldn’t be making our decisions for us
  • Technology can communicate but doesn’t need to speak
  • The right amount of tech is the least amount to get the job done
  • Technology should work even when it fails, not just in perfect situations

Josh Clark (@bigmediumjosh), “Design in the Era of the Algorithm”

  • Correcting bias is in itself a form of bias
  • Bias and codifying the past – eg racist tap
  • How to address our blind spots, not just gender, ethnicity but also cultural
  • Make it easy to contribute accurate data

Cheryl Platz (@muppetaphrodite), “The Future of Voice”

  • Voice interfaces are mainstream but not mature yet

Pamela Pavliscak (@paminthelab), “Creating a Future with Feelings”

  • Designing for emotion
  • Feel/understand the layers of emotion
  • Design a future full of feelings!


UX London ran over 3 days, with the talks in the mornings, and workshops in the afternoon. Sadly I had to miss them on day 1 because of Sick Child At Home™.

On day 2, I attended Jason Mesut’s (@jasonmesut) “Shaping you: now and next”, which was wonderful for an introvert, and it addressed concerns I have at work right now:

  • “How do you best represent yourself to others so that you are applied to the right challenges for your skillset?”
  • “How do you recruit people in your team to fit the needs of your projects?”
  • “How do you help define how you and others can develop their skills?”

I won’t reveal Jason’s secrets here, but really loved the exercises and pace of the workshop.

On day 3, I attended Liza Kindred’s (@LizaK) “Mindful Technology” (with a cameo from Josh Clark), as I had pledged that this year I would be trying to bring this kind of thinking into my work as much as possible: “Instead of designing for page views, it’s time to design for purpose, for calm, and for compassion.” Yes!

Liza made us put our devices away in a box for the duration, which made me upset at first, but a bit calmer as time passed. Thank you, Liza.

What’s next

These days it’s hard to find time to travel and attend conferences, so I don’t go to as many as I once did. I knew UX London was going to be great and time well spent, and it didn’t disappoint. I already have my ticket for Leading Design in October, also put on by Clearleft, and the expectations are high!

Why side projects aren’t a good idea

19 February 2018, in Life | Add a comment »

It’s common knowledge that your side projects and open source contributions can be the key to landing your next job. But when hiring for diversity, this can be a problem.

I was watching Brenna O’Brien’s video The myth of the “Real JavaScript Developer” when she said something that piqued my interest: the fact that we shouldn’t expect developers to code all day.

Amongst other points, Brenna mentions the example of Nicolle Sullivan, who, after having a child, reconsidered the normal practice of looking at a candidate’s open source contributions when hiring—not everyone has the ability or will to work on code outside work.

I agree: working day and night shouldn’t be a requirement when looking for the best candidate for a job. And, like Nicole, this is not something I’ve considered before having a child (despite my long-lasting RSI).

As an introvert, staying home to code and write has always come easy to me. Many times I advised people to build their portfolios with side projects, to write, to learn, speak at conferences, go to meetups. But I’ve changed my mind: I don’t think we should be judging people’s ability to perform their job by how long they can (or want to) sit in front of their computers.

Take attending a meetup after work. For you, it might mean that for 2 hours in the evening you’re learning new things and meeting cool new people. For me, it means I won’t see my son for more than 20 minutes that day (if that much), and that I will lose precious downtime with my husband once the house is quiet. And those 20 minutes will likely be stressful, trying to get everyone out the door in the morning.

These days, the mere suggestion of weekend and evening events raises my heartbeat and makes me stress and worry. It puts me in a position where I have to either a) say no to my career, be anti-social, and prove once again that working mothers can’t be flexible, or b) miss precious time with my family, who I already feel I don’t see enough of.

Here are others things I will be sacrificing every time I do the things so many recruiting managers would like me to do:

  • Time with my friends
  • Time to rest
  • Time to think
  • Time to experience different moments that allow me to enjoy life
  • Time to deal with everything else that is not work, and that needs to be done
  • Time to do nothing

The ability to work on side projects carries a certain bias against those who can’t do it, or simply don’t want to. Doing so surely falls onto some kind of discriminatory hiring behaviour (if not, it should).

I know how easy it is to hire young white man after young white man, and to try to get away with the excuse that “there just weren’t any good women candidates”. It’s so easy to almost accidentally take the mental leap between “these two candidates seem equally qualified” to “but the woman might have children, she won’t go the extra mile for us”.

But working at the same screen 24/7 without the ability or desire to take in the world around you should also tell you things, and should also be considered when hiring that awesome candidate.

I have the feeling that our lack of ability to understand that more hours spent working doesn’t equal better work will be the kind of thing future humans will be perplexed by. Just like we are by child labour now.

I’d like to live in a world where I don’t feel guilty about enjoying my free time. And where we don’t judge anyone’s potential by how many hours they spend in front of their screens.

Designer interview tests: should designers write?

17 January 2018, in Design, Work method | Add a comment »

Knowing whether a candidate is right for a role isn’t straight forward. Jobs are different, teams work differently, and assessing someone’s ability to adapt to a different set of circumstances can feel like an impossible task.

I’m not particularly fond of design exercises. They can easily feel like spec work, especially when the recruiter’s expectations aren’t clearly set. Are you expected to work on an answer for 30 minutes, 2 hours, a week?

The subjectivity of the process in contrast with the typical engineering hiring process also bothers me. How do you tell a correct answer from an incorrect one?

With this in mind, other day I had this idea that, if good designers write, could a written exercise be part of a designer’s recruitment process? Because, truthfully, if you can’t write, can you design?

I must confess, I did no research whatsoever before writing this post, so the possibility that there are several companies doing this already is very real.

Nevertheless, the idea is worth exploring. A writing exercise could be the only exercise, or part of a series of steps (screening — take-home writing exercise — in-person whiteboard exercise — portfolio review — final chat?).

Would this cause issues to certain candidates? Could this be an exclusive process that puts some at a disadvantage? Would there be any accessibility issues?

I think this is an idea worth trying. I’d love to know if anyone has tried it before, and if it was successful.

Technically Wrong: the book I needed to start the year

8 January 2018, in Reviews | Add a comment »

Those who know me know I’m not a fan of surprises—I choose my Christmas and birthday presents. And this year was not an exception. But nevertheless, my husband, as the risk-seeker that he is, took the bold step of gifting me something I hadn’t previously approved, but that he sensed would be just my cup of tea.

He wasn’t wrong. Since I opened my book-shaped present on Christmas Eve I haven’t been able to put Sara Wachter-Boettcher’s “Technicaly Wrong” down.

Unputdownable, they say.

Somehow, I had missed this book’s publication, which is very odd as I follow people who I’m sure have tweeted about it. Nevertheless, I had never seen it before, or heard of it, so maybe other people don’t know of its existence either, which is a crime.

I don’t want to go into a lot of detail about the book, because I’d rather everyone read it. But I’d like to echo the sentiment of the author. The subtitle, “Sexist Apps, Biased Algorithms, and Other Threats of Toxic Tech”, is a good summary of what you will find inside.

Technology is an inescapable part of our lives. From the most trivial things, like buying lightbulbs, to the most live-changing ones, like applying for social housing, or getting a passport. But we don’t place tech companies and the people within them in a position where they have the same accountability as other, older institutions. We think if a computer came up with something (like a search result), it must be right. But it’s humans all the way down, and humans have biases and are fallible.

Technically Wrong includes incredible, heart-pumping, rage-inducing stories of racial discrimination, gender inequality, sexual harassment, and much more. There is also a call for everyone to open our eyes to the biases that permeate the technology that surrounds us, and that we brush aside, because they mostly don’t affect us in a harmful way. But technology is for, and is needed by, everyone. And everyone means people who don’t all live, look or sound the same.

Sometimes I forget in how many categories I fall that technology and the tech industry have a tendency to put at a disadvantage: I’m a woman. A working parent. An immigrant. There’s an acute accent in my often-too-long name, who no-one can pronounce. [I totally understand the plight of the woman in the book who needs to manage different versions of her name across different systems—that is my life (p.72).] Online forms that ask for my ethnicity confuse me (although I just sent my saliva to 23andme, so I might know how to answer that question soon). My passport says I was born in Russia (actually, in the “Soviet Union”, which is as amusing as it sounds), but I am not Russian (it was fun getting my son his British passport).

One time, I had to wait for 20 minutes at an airport check-in desk until someone with enough authority could allow my son and I to check-in. Why? Our names didn’t match our passports. Why? The airline’s online booking form said “the combination of both of our first names and surnames was too long”, so I had to cut them until they fit the form.

My anecdotes are largely benign. But for people who are less privileged, tech that doesn’t consider anything that departs from the norm can have truly devastating consequences. As tech workers, it’s within our power, and our responsibility, to change this:

“[A]lienating technology doesn’t matter less during this time of political upheaval. It matters all the more.”
—Sarah Wachter-Boettcher, in “Technically Wrong” (p.196)

My new year resolutions are very much the same as the next person’s: drink plenty of water, got to bed early, exercise more, read more books, write more articles.

But on top of that, and most of all, I hope I can bring just a little of what the author asks of us to my work. If I can do that, it will be a good year.

Now go read it.

What’s in a name?

4 January 2018, in Design, Writing | Add a comment »

As I consider a move away from having my blog separate from my namesake domain, something dawned on me: my blog is called Web Designer Notebook, but is that name still accurate? How many of us still call ourselves web designers?

Recently I advised a friend looking for a new job to not only search for the term “web designer” but also “product designer”, as that describes what many companies are looking for today. She did find more job ads.

So the question is twofold: is there a point in keeping a blog as a separate entity of the portfolio site (ignoring the unwelcome task of merging Kirby and WordPress); and is Web Designer Notebook a good name for it anyway?

Book review: “White Hat UX”

19 April 2017, in Reviews | Add a comment »

When Trine told me she’d been writing a book for the past year I knew it would be good. I’ve had the pleasure of speaking at a couple of the same events as her in the last few years and have since followed her work. Her talks gave me a great insight on designing for children — an important topic that we should know more about but that can sound daunting at first.

White Hat UX is a great reminder for experienced designers of the kind of work we should be striving to do, and an excellent introduction to the topic for UX novices, as it dedicates some time to explain some of the basic concepts.

Trine’s book, co-authored with Kim Andersen and Martin Michael Frederiksen, focuses on doing things right. It goes into detail about how we can improve our users’ experience of our sites and products, and our bottom line, without resorting to dubious design practices.

“Day-to-day business is about traffic measurements, conversion rates, cost per click, page views, uptime, media convergence and all the three-letter acronyms of IT business.

“What has become of style, tone, good language, identity, branding and positioning? They are still there, but are struggling to keep afloat among the flurry of new technologies all driven by metrics.”

—White Hat UX, page 53

My favourite aspect of the book is that it holds design professionals to the high standards that we should all want our work to meet, without excuses. Our work can influence the lives of people in ways that we can’t even image, and as professionals with this kind of influence it’s important for us to revisit our practices and consider what we do regularly throughout our careers.

The best part: the book is available for free on Amazon until the 22nd of April. Go get it — it would be rude not to.

I swore I wouldn’t write another book

6 March 2017, in Writing | Add a comment »

I wrote a book. Another one.

Even though I had sworn off ever doing it again, I somehow convinced myself that it wasn’t going to be too hard since this book was going to be much smaller, and I already had a lot of the content anyway.

Cue me being proven wrong.

Read more »