Archive for the ‘Design’ category

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.

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.

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?

Architect’s myopia

22 January 2012, in Design, Resources | 2 comments »

Before I get to my main point, I must mention (once again) the phenomenal quality of the hand-picked articles that are featured on the Give Me Something To Read website, the source of the piece I will be referring to in the following lines.

The article “The Architect Has No Clothes“, by Michael Mehaffy and Nikos A. Salingaros, explores why modern architecture feels so cold and inhospitable and how that might be easily explained by a phenomenon called “architectural myopia”. The authors describe how this consequence likely has its causes in how architecture is taught and how the methodologies used in the classroom deprive future architectures from any empathy with those who will in the future live and use their creations.

It’s not my goal to provide a summary, as the article does a much better job at explaining this fascinating theory. But I started thinking about whether it would be fair to conclude us web designers might sometimes suffer from a similar malady. I also found it interesting that this profession I hear mentioned so many times as so established and as the ideal model to follow is, like our own, still finding its own ways.

Do designers need a personal style?

2 February 2010, in Design, Project 52 | 24 comments »

A post by Darren Hoyt caught my eye the other day (among the hundreds of unread posts on my RSS reader…) where he asked whether designers needed a personal style or not. I wrote up a quick comment at the time, but I feel the question deserves a little more discussion — specially because no-one seems to have a definite answer (my bet is that there isn’t one).

(more…)

The tangibility of websites, or something like that

30 November 2009, in Design | 8 comments »

Last night I watched Objectified, a good film about the design of everyday things. In the film, the matter of durability and sustainability in design is mentioned a lot, and that led me to think of how those ideas translate to web design.

(more…)

From print to web: avoiding common design mistakes

14 July 2009, in Design, Work method | 7 comments »

Moving from print to the web is not as easy as it may seem. I had to do it myself a few years back, so I can speak from my personal experience of the process and also from my experiences coding designs that have been created by print designers that were new to the web.

(more…)