Ask them what exact requirements you are talking about? And for a requirement breakdowns :)

A tricky question without a simple answer...but in an ideal situation:

• I would have done user/audience testing on what was created and validated the product. I find that clients find it harder to argue with users feedback (though some find a way! sighhh) but most will understand and appreciate that you went and made sure it worked for those that intended to use it.

After all, our clients might not know everything about their audience and that's what product experts are hired for 👏

I believe a proper discovery session with the client, would help you understand what the client defines as "requirements".

Also, it's true that a lot of clients do not have a complete understanding of what they want their products to do, hence, a usability test is also advised, and if it meets their requirements, then that should be a go.

Finally, I also think it'll be a good move to carry your client along in your design process, so they're aware of what is, and what is not. That way, any iterations that need to be made, are made during the process, not after completed efforts.

Hi Bolaji Ayodeji Reusable components mean any codebase or any project can take and use it as is, without any string attached or complexity. That said, a reusable component is pretty isolated itself so that it will be generic enough. It's a good practice to build them in isolation with Storybook, assuming all the specs are well given :). Building in isolation means you have the component at the most basic form, and you can test out its functionality or behavior in different situation, then understanding if there is any need to modify for better coverage. Building in the regular way is also good, but you may face complexity if the component is not well structured and extracting the component to use in a different project can be a difficult task. I always start with Storybook, as a way to organize my components and check if I miss any use case it may have. There are a lot of benefits - it helps us as front-end developers to be more organized, do a better architecture of our own design system or project since we have to list down what components we need. Also it avoids code duplication, and most important, you can find the most common potential bugs almost immediately without waiting for it to be in actual use.

But again, don't make it too isolated (especially for CSS) or else it will be not reusable at all :).

This is really helpful Maya Shavin, thanks a lot.

Thank you Eriol Fox! Definately going to read the book you suggested. 😊

I totally, totally second all the answers provided here!

It's important to consider the effect/feel/experience you intend to create with whatever you're designing. Colors are proven to have a psychological effect on users, hence, it's expected that we duly think this through when selecting colors - the effect of certain colors on various individuals, with respect to what you're designing, be it brand identity, digital products, etc (yes, some people actually have hormonal responses to certain colors😄).

Also, it's important to look out for key factors such as contrast.

Finally, the visual appeal is just as important as the functionality of the product being designed - your design has gotta look just as good, as it works!😁

coolors.co does a good job for me.

Thanks Joshua Ofor 😊

Lots of things have moved online 😅

Pros: It's been way easier on the mind and work (don't have to take days off from work + travel + stay in a different city). A lot more accessible, more + diverse set of people now have access to meetups and conferences.

Cons: I don't get to to hang out with my friends from other places that I love bumping into or make new ones!

With respect to the future, I'm guessing online events will still have their place but we'll start appreciating in-person meetups a lot more 😅

I miss meeting folks irl :( it's certainly made it an odd time in history!

I mostly get mad about how online conferences are great in theory, but rarely account for folks with unstable internet or limitations to access.

The good parts are that conferences are embracing pre-recording talks which means that lots of people can present ideas and talks. So there is a lot of content out there now!

I do miss the human connection of in-person events and I hope that we're all safe to attend soon but I see the biggest change is that conferences in-person will likely have better facilities for people who can't travel or would risk their health to travel. So more meet-ups and conferences that are 50% in person 50% livestreamed/pre-recorded.

At the start of the pandemic, not having to attend or participate in in-person meetups posed surreally, but being up till now shows I (we) sure found a way to navigate that phase.

Not getting to experience that physical/human interaction, hugs, smiles, and teeming joy when we walked into a room for a physical meetup, with a lot of devs enthusiastic about creating cool stuff? I have missed all of that.

Nonetheless, I'm certain that we'd be returning to that experience, or at least something close to it soon, and yes, online meetups have come to stay; as an alternative to the physical. Livestream, pre-recorded sessions & AMAs like this have helped keep the conversation going.

It really depends :). For design and prototyping, I use Sketch App on Mac, and lately Affinity Designer on my iPad Pro. And from time to time Adobe Photoshop and Illustrator for others (icon, photo editing). For developing, of course VS Code and this is definitely something I can't live without. If you ask about UI framework then TailwindCSS is the first choice :)

Depends on the kind of project and stage of the project but daily I use these a lot:

• Adobe XD
• Github (for conversations on issues)
• Notion for research and documentation

I've used lots of tools before, illustrator, balsamiq, figma, sketch etc. but the best design tool doesn't have to be techy, paper and a pen to sketch, a team for conversation/collaboration is very, very useful :D

When it comes to design tools, I'm a bit consistent with my choices.

My sketchpad, sticky notes, and pencil.

Taking it up a notch, I work daily with Adobe Illustrator, Photoshop, XD & Figma

I honestly can't live without Adobe Illustrator (not literally, but yeah!😅)

UX = how users see + understand your app and then how easy for them to use.

Centring the user when building your tool.

UX says "understanding the user, and working with that understanding to meet the user's need".

Do user testing and do it in a way that doesn't confirm bias!

There's a lot of 'fashionable' or 'trends' in design and UI and some of that is because big companies have found that it helps certain tools and actions. A simple example is, having AA+ accessible contrast colours on buttons, it helps mostly everyone because now people can see buttons clearly. Sometimes trends are good but sometimes they are bad, for example, the trend of using lots of gradients, or carousels on webpages/apps might seem like its a good thing to have because...well...other do it! but the best way to find out if your users can use it is to do testing.

The conclusion is something that 'looks good/cool' might be completely un-useable. So focusing on what works first and build from there :)

Working as a designer in the humanitarian and non-profit space we find accessibility and inclusion especially hard. Mostly because tech grants don't explicitly fund accessibility improvements unless that's a specific audience that the grant is funding.

I think having a specialist in accessibility is amazing and would love that on every team, but I strongly believe everyone across the team should care about accessibility and inclusion.

It has its nuances for sure 😅

From what I see, developers are very picky people with a lot of options, so the expectation of quality is really high. At the same time, this audience really appreciates a job well done!

If you care about them, they pay it back :)

Developers are also a part of the audience we design for. However, just like Eriol & Sid have earlier said, devs yet being part of the audience, are unique users having their own preferences, expectations, needs, etc.

Designing within the developer ecosystem is real; it is important to consider the peculiarities of these people, what sets them apart, and what brings them together; the things they care about, what they need to facilitate their processes, and perform effectively too!

It's important to understand the moving parts that make the "designing for devs & various audiences" work.

Developers normally have different requirements than other users :). Some of the UI can be obvious with developers (Github repo for example) but not friendly with non-tech person. Also, like Sid said, developers tend to be picky, and for me particular, like to be impatient when it comes to dealing with things outside of coding. So designing for developers need to take into consideration how useful and easy for them to navigate around (Netlify is a good example for this), or else they won't use and even bass the product publicly. But if you do it well, developers are the first ones to celebrate and appreciate them ;)

Great question, using a good foundation is one the quickest ways if you're like me and aren't an expert at accessibility. If you're in React land, reach-ui is my goto, I've heard great things about reakit as well.

Once you start getting into it, I think you'd really enjoying learning the tiny details which make elements accessible. The official WAI-ARIA guidelines and Inclusive components are my recommendations.

And finally, testing man! Loooots of testing :)

Hey Shad! Let me answer that in parts :)

what are the benefits

Testing components of a design system is similar to testing components of any product. It helps you avoid bugs and keep the overall quality high.

what concerns do we need to keep in mind

What's probably unique to components as part of your design system is:

1. these components need to provide a solid base to build things on top of. So if your components aren't responsive or accessible, it would be difficult to make a responsive or accessible product on top of it. Those are great tests to have.

2. you get a suite of scenarios and tests from the use cases of your components. When a component is used in a way that you did not predict, that can be brought back as a test suite.

And for your second question about typescript, I'd love for others to chime in on this one, I'm pretty new to typescript.

From my limited experience of using typescript for reusable components, it forces you to be accurate about the definition and usage of every variable/function/component which brings up edge cases that you wouldn't have thought of otherwise (example: can user.name be null, what should we render then?)

Personally, I'm just a fan of autocomplete for discoverability :)

Understood. Thanks for answering Sid

Should accessibility come under a feature of the design system or it should be taken care by the developer itself?

Like Eriol said, it's everyone's responsibility :)

You can't get one without the other. You need base components from the design system to provide an accessible foundation (I'm thinking of an Icon Button that has a aria-labelledby and a tooltip). At the same time, you'll need the application's context to put a useful message in the tooltip.

Part 2 of your question is very subjective :) There is no 1 true correct answer.

My personal approach is to keep things that do the same job in the same component even if they look different (that what variants are). Things that look the same but serve different purposes go in different components.

This was help Eriol Fox Sid Thank you. I think I got my answer.

Hi slim, I'm not a designer but from a developer's point of view, here are my takes :)

1. When designing a new system, it depends on the scale of the relevant projects - is it going to be used across different projects? What frameworks or languages are used (like TypeScript, React, Vue etc) in these projects? And most important, what are the use cases for each component of the system (how generic it should be etc)
2. Not sure I understand your question. Can you elaborate a bit?
3. I normally go with Sketch/Figma to understand the style guides (color, font size, padding, etc), then use utility framework (TailwindCSS or Tachyon) to create the default variables for the basic style guides together with CSS, then use Storybook to start creating and testing the component in different use case. Of course the best practice is to understand if there is a possibility of expanding the functionality / use case of a certain component. Discussion with designer is always a good thing to do :)
4. Never assume the cases given by designer are everything and never create any component just because it is simple to do so :).

Hi James! Here’s my little throw-in:

When it comes to design systems, I personally believe that they’re made to solve human problems. These problems would many at times pose to be around communication. Hence, I’d offer two recommendations here: Firstly, ensuring that all or at best, the basic constituents necessary, are in place. These would include but not limited to: a visual language understandable by the team; this may be reflected in a properly-outlined style guide, functional interface components, and a set of standards that would guide the use of those components. Secondly, for technical recommendations, I’d go with any of these tools to build your design team (might be a tad biased with my choices, but they work for me) - InvisionApp (invisionapp.com) & Figma (figma.com). My reason for these is, they both work as easy-to-use, flexible yet effective tools.

Just to add this for anyone who’d love to see this: most design systems are merely pattern libraries and style guides. A design system should embody a system of various concepts, and pose a shared platform where teams can create, collaborate, and build.

For my team we use Zeplin for design and Invision for prototyping. But it all depends on how your team work and what programming language your projects are based on. Hope it helps

+1 to all the tools mentioned by my peers on the AMA here but what I'm reeeeeeeeeeeeeally excited for is uxbox.io an open source design tool that is aiming for feature parity with Figma!!!! YES! I can finally host my own design software :D

Some links first:

a11yproject.com pa11y.org

but the longer answer is that accessibility isn't just about optimising code structure and meeting minimum technical accessibility requirements! It goes hand in hand with inclusion and diversity.

Some ways of making tool more accessible are about understanding how, when and where users are using a tool. I'd like to link this project from Internews for the amazing resources for being inclusive around privacy and security issues: usable.tools

A11y is not easy to understand, as it is full of high level definition. My tip is try to put yourself into the shoes of the users, which means testing your UI as if you can't do the common way, like navigating between component without mouse or touch, trying to set your app brightness to 0 (complete dark) and use it as if you are blind. There are laws and requirements that you can check and follow, but in general, no laws can help unless you yourself experience it ;)

Eriol Fox I still find the concept of contributing to open source as a designer very blurry.

As a newbie to open source, how can I contribute?

Saviour Akpanukoh

Ayye friend, this is a hard question because it is still very blurry!

Even though groups like opensourcedesign.net have been around for 5+ years and years before that, designers were always interested in technology and especially technology that empowers people freely there are still structural reasons open source design contributions are low and difficult...but we are making our path stronger each day!

I started writing a guide for this here on my Notion: notion.so/erioldoesdesign/Guide-to-getting-involv…

But there is lots missing. The best thing you can do as a start is to find other open source designer peers to lean on, build networks and discuss open source and design. You'll find those in the open source design forum: discourse.opensourcedesign.net

The frustrating part is the ground level work is more about helping the OSS projects, maintainers and developers understand what design is capable of offering their OSS and how to ask. It'll be more conversations, discovery and coaching at first (and also documentation writing!) but you'll also find some OSS project more than ready to receive design help across the spectrum of design from UX research to graphic design to usability testing!

Eriol Fox thanks so much for the response, I'll go through the guide on your Notion.

On finding other open source designer peers to lean on, I've followed you on twitter in addition to your other recommendations.

Again, thanks so much.

I'm gonna try and give a short answer here but one key thing to say is that the answer to this question will be different from designer to designer! Every designer has methods and concepts they favour and these are mine, it's kind of like when devs have favourite programming languages or frameworks haha! :D

These are more UX:

• Human-Centred Design (HCD) or User-Centred Design (UCD)
• Participatory Design (Methodology)
• Liberatory Design (Methodology)
• How to conduct user interviews

UI:

• Understanding design systems and how those work/compliment UI frameworks like...Ionic for example.