When I signed up for the Sparkbox UnConference I hadn't realised it was taking part over in the States, so I was a little early trying to log in at 11am BST today 😁 Five hours later and we're off. The event is split into four topics: Design Systems, Accessibility, UX, Software Development. Hoping to drop in and out on all of the topics, but we'll see how far I get as it gets later. Unfortunately, it's also overlapping with React London so... we'll see how it goes![1]
First quick note on the event as a whole: pre-recording the talks and adding captions is an excellent move. Reduces technical issues and improves accessibility, a real win-win!
Second note: love the interspersed messages from people like Ethan Marcotte and Miriam Suzanne ♥ Also, that song from Dan Mall 🔥🎹
Ethan Muller: Designing for Design Systems
What is a design system? Is it a style guide, code Lego, or a pattern library? Yes: it's all of the above. A style guide deconstructs an aesthetic to show you what makes it tick. A pattern library ensures consistency. A design system does all of this and more.
Breaking an existing product into components probably won't make a system that's useful to everybody.
Design decisions can be broken down into a "what" and a "why". What we're doing and why we need to do it. These what/why combinations belong in your design system.
How do you go about starting a design system? Ethan recommends starting with typography: fonts, heading styles, spacing. Next, consider colours. From both a brand and UI perspective i.e. state design. Next, figure out buttons. These are the most useful design elements.
Design systems are all about creating harmony, especially between design and development. Harmony isn't about singing the same note; it's about complementing one another.
Components are great, but they may not always be the best primitive for a design system. Skins are another unit which works well; skins are background colours, foreground colours, text colours, and link colours. There's a lot of room to get creative with turning design into development.
Ben Callahan: Selling Design Systems
[I had my own technical issues right at the start of this talk, but managed to catch the end and the whole Q&A. In short: in was great. I really wish I'd caught the start so I could actually blog about it as I went.]
Lina Calin: It Takes a Village: Building Organizational Buy-In For Your Design System
Ben talked about how to get funding for a design system and get key stakeholders on board, but once you have that you still have a major hurdle: getting the team on the same page. Buy-in is important because design projects tend to fail due to people reasons, not technical reasons. Adoption difficulties and a lack of executive champion are top of that list.
Step one is making sure you know about the core "why" behind your design system. Outline the benefits the system brings and ensure it touches on the existing problems you are looking to solve, as well as future issues that can be mitigated by it. Testing is a good example, but so is brand consistency and accessibility.
Step two is building allies. Design systems should empower your team, so make sure the team has a voice. Choose advocates within your team who are already influential or for whom the design system will have a major impact.
Step three, identify other key stakeholders. Y'know, the people who can influence the spread of the design system, budgets etc. Keep them in the loop and make sure they know what key milestones are and that you are hitting them.
Step four is to understand what those milestones are and how that might impact everything else. Prioritisation is key here: get the work done that will build quick wins, ensure happy stakeholders, and make sure the value is clear to the team.
Finally, create a support plan. Users may worry about long term maintenance requirements; ensuring this is thought of from day one will help build trust in the system. Simple things like clear versioning and release notes can go a long way, but also document contribution processes and ongoing employee surveys.
Don't forget, you're creating a living, breathing system that's stable and scalable in the long term. That's the aim of these tips. You don't have to get everyone's buy-in all at once. But you want to be strategic about who you build your partnerships with and in what order.
Corinne Ling: 5 Ways to Advocate for Accessibility
The only way we can make a better web is if everyone is a part of it. But it can be hard if some people aren't prioritising accessibility. Corinne is touching on five ways to advocate for that to change, whilst being aware of budget and time constraints that can create blockers to large scale change.
An easy way to help is to include accessibility requirements in tickets or cards when work is first assigned. For developers who are less used to considering accessibility requirements, this can provide easy learning examples and help guide them with what needs to be done. Similarly, include information on how to test with assistive technology. From screenreaders to keyboard navigation, just stating how to go about testing can be a major win in ensuring people help out. These tests do not replace user testing with people who actually have disabilities.
Pairing is a great method of knowledge sharing, so when you have accessibility tasks to work on offer to pair with them. That way, when they get to the accessibility issues you can help out and spread that knowledge throughout the team. It can also help you get better at teaching how to make things accessible.
Don't, though, make "accessibility" tickets a category. Accessibility bugs are just bugs, don't treat them differently. Similarly, don't deprioritise accessibility tickets; make sure these are done just like anything else. Don't shift them all to the end of the project, as that can be a lot more time consuming and expensive than considering it as you go along.
Corinne has some very cool resources in her footnotes:
- https://seesparkbox.com/foundry/category/accessibility
- https://bit.ly/test-color-contrast
- https://bit.ly/vo-shortcuts
- https://bit.ly/nvda-shortcuts
- https://bit.ly/keyboard-testing
Kasey Bonafacio: Understanding Accessibility: WCAG’s 13 Guidelines
Kasey starts with the fact that WCAG isn't the easiest thing to wrap your head around [agreed]. But it follows a clear structure, so let's look at that. WCAG operates on four key principles: a website should be Perceivable, Operable, Understandable, and Robust. These are a bit vague, so each is separated into specific guidelines, which all have even more specific success criteria.
Today, we're looking at those guidelines. These each have three levels of conformance: A, AA, and AAA. "A" is pretty easy to hit without really even trying. "AA" requires a little bit of work but should be possible for all websites. "AAA" is the strictest level and may not be possible for all sites. As a result, Kasey is focusing on "AA" for this talk.
Perceivable
First up, all images need to have alternative text that clearly describes what's happening. That includes CAPTCHA images, but obviously here we can't provide direct alt text as that would be too simple. In this case, CAPTCHA forms often have audio buttons that read aloud the content instead.
Second would be a similar concept but for "time-based media" i.e. audio and video. Think captions (lovely use of Convos With My 2-Year Old 😂) and audio descriptions; the latter can be particularly useful for video with little dialogue. Transcripts are also amazingly useful, particularly for dialogue-driven content such as podcasts.
The third stage is that content should be adaptable regardless of content. This basically seems to cover responsive design. Content should always be accessible, regardless of screen size or orientation, or access method. Consider tools like Safari's Reader Mode which heavily used.
Finally, content should be "distinguishable". In other words, the contrast should be strong enough to easily read text and distinguish things like foreground and background. Ideally, the text should have a contrast ratio of 4.5. This also applies to audio. Background audio (i.e. music) should be 20 decibels quieter than the main audio track i.e. dialogue.
Operable
All content should be keyboard accessible. Definitely elements here of Jen's talk Button vs Div from React Conf 😉 Similarly, links shouldn't be buttons. Links are for linking to content somewhere else on the site or internet; buttons should be used for actions.
Content should be able to be consumed at the pace the user wants. For example, videos should be pausable or able to be started/stopped. That includes elements like animations or GIFs, as well as forms with timers such as log out notifications which give them the change to stop a logout within a time limit.
Animations and videos should not flash more than three times per second. Why? To avoid seizures and other physical reactions.
The fourth requirement is that the website is clearly navigable. Think focus states, as well as things like page titles, breadcrumbs, and other navigation markers which can help someone understand where they are on the website. Within content, linked headlines and contents boxes are also preferred.
Finally, websites should be accessible by other devices other than keyboards. That means mice, touchscreens, screen readers, speech-driven assistants like Alexa etc.
Understandable
Content should be readable and easy to understand. Simplify language, avoid or define jargon, and do use the `<abbr>` element.
All web pages must have an `<html lang="">` element with the language specified e.g. `en`. If you then have text in other languages, you can wrap it in `<span>` elements with language tags e.g. `<span lang="fr">` which helps screen readers correctly pronounce text.
Pages should operate predictably. For example, if you have a blog and move around between articles, you would expect the navigation to stay at the top of the site with links in the same order. Basically, template your sites as much as possible and make them as consistent as possible.
Input forms should be clear about what they're for. For example, include labels and clearly mark errors in forms, as well as provide examples; don't just rely on colours but use label changes and error messages as well.
Robust
It's a simple one: make sure your website works with current and future assistive technology. We can't predict the future, but we can futureproof our code by writing semantic HTML. Why? Because new technologies will be built with existing standards in mind.
You can also use ARIA to extend HTML. The preference is to use the HTML you have for the purposes it was meant for; ARIA is there for when you need it only.
[Wow, that was an incredible talk with a lot of information. What a whirlwind!]
Q&A
How to convince my team about accessibility? Sparkbox have an accessibility taskforce which talks to people during lunch and learns or team meetings. Sharing that information makes it clearly
How valuable is IAAA certification? It depends. It provides validation that you know what you're talking about; great for client certainty.
What are the forgotten parts of inclusive design? Don't just think about screen readers. Test for the whole suite. But also, consider cognitive disabilities and do try to build the web in ways that your own bias. For example, associating "Learn More" buttons with the text above it isn't always clear if you're not sighted.
What's the worst accessibility issue you've found? Carousels. They're basically awful.
Is automated testing enough? No. It'll catch a lot, so it's worth setting up, but it's not going to be able to understand alt text, for example, and know it's correct. You need a person looking at the code.
What tooling do you use? Pa11y is a great CI tool that is integrated directly into the build process [yes'm!] which catches a lot of colour contrast issues and ARIA. The Lighthouse feature tool for Chrome is great, as most people know. Axe and Wave are both great and help inform other tools like Lighthouse.
Julie Young: Putting the “User” in UX
Julie is looking at how to add user research to your projects, including the hard part of actually finding participants. User research is talking to people who are actually using your service; the marketing or product teams are often the best place to find out who these people might be. Once you know who to ask, it's time to start asking them.
Normally that involves user interviews and user observations. Things like "Tell me about the last time you..."? Followed up by "And then what happened?" or "And when you did X, what happened?" depending on what you want to know. Once you have the information, you can start creating user journeys and personae.
Ultimately, the goal of user research is to know the user well enough to share that understanding with the rest of the team and to provide evidence-based rationale for the decisions that go into your product.
So why aren't we doing user research? It's expensive, it's time-consuming, and it's difficult... right? Plus, if we've not needed it in the past, why now? Well, user research doesn't need to be expensive or time-consuming. After all, if you're doing no research now, even the smallest piece is a big benefit.
Best tip? Offer some kind of reward to users (gift cards are great) for taking part in user research. Then, whenever someone says yes, make sure to ask them if they know anyone else who might be interested. You can also send emails out to marketing lists or promote posts on LinkedIn. Those surveys are useful, but you can include questions which ask if they'd be willing to participate in a more detailed phone call.
But what about specialised populations? These are people with certain jobs or interests that you just can't find by randomly searching. Find out if there are specialist places online, things like subreddits, slack channels, or forums which are targeted specifically at that demographic. Lurking around on these sites is often good research in its own right, then you can start sending DMs to key people who are clearly engaged. There may even me IRL meetups that specialise in that area which would be a good place for networking and finding out about the wider community.
Of course, if you actually have a budget, user research ads on social media platforms definitely works. There are also PAYG websites who can source users for you, alongside marketing recruitment firms.
Once you have some users, ensure you have informed consent. That means telling the user exactly why you're talking to them, how you're using their information, and be transparent about how you're recording the information. Also, do use incentives. A $1 a minute is a good rule of thumb and yes, gift cards are fine. However, for more specialist data or embarrassing topics then consider a $50 minimum or more.
Bryan Braun: How to Build a Zero-Maintenance Web Application
Bryan is kicking off the sustainable software track, the final section of the day. [It was a lightning round so I skipped the tweeting.]
Here's the idea: launch a project and never come back to it. Zero maintenance. It's probably not possible, but let's consider how we can get as close as possible. To begin with, let's consider software that prioritises backwards compatibility. Take Rails vs PHP: PHP code written ten years ago still works today; Rails code written five years okay probably doesn't. PHP is more resilient because it always maintains backwards compatibility. Another great example is the Space Jam website (that old classic). It uses HTML and CSS so it still works.
The second thing to keep in mind is to avoid the "cutting edge". If you're using new techniques, you simply don't know what is going to stand the test of time. Instead, look for mature technologies that have had their edges worn off. The same argument goes for design (Daring Fireball is used): minimalist designs and clean typography never go out of style.
We also need to eliminate dependencies: third-party packages or services leave you dependent on other people's code. Your site or application is stale the moment one of those services shuts down or terminates your version or simply stops being maintained itself. You can locally host third-party code as a middle ground.
Think about automation. Make sure old logs or databases are automatically managed using CRON jobs or similar techniques. Ditto for renewals like SSL or hosting. Simply thinking "Can I automate this" goes a long way.
Finally, KISS. Simplify wherever you can. The fewer features you have, the less that could possibly need maintenance. Make your application do one thing extremely well and you'll never need to touch it again (probably).
All of that said, you can take it too far. A zero-maintenance application can become unuseable if it's too simple, too pared back, too ugly. But still, the principles are useful to consider for any project.
Ryan Cromwell: Foundations of Sustainable Software
For makers, theres is no better feeling than seeing something you've made being used.
What is sustainable software? It's a way of building software that meets three criteria:
- Having confidence in your efforts;
- Feeling in control of the process, so you are in the driving seat;
- Can build projects consistently over time.
However:
We'll know more tomorrow than we do today. We need to be able to lean into this idea that we don't have all the answers. We may feel confident, but we need to be sure to leave room to learn as we go along.
So you need to find a balance between confidence and control whilst still leaving room to learn. Or do you? Perhaps you can just do it all at once.
Ryan calls this Continuous Discovery. The idea that any project is cyclical, going through planning -> design/build -> feedback -> refine -> planning etc. Sure you will (hopefully) ship something somewhere around that design/build phase and feedback, but it still keeps going through the loop.
A technical vision enables decision making.
So map it out. Do it with diagrams, do it with words, do it however it most makes sense to you and your team, but have it recorded somewhere. Make it high-level, but map out API interactions, gives reasons for why certain tools or technologies are being used and where they fit, and once you've sketched it out make sure it's accessible.
A great build and pipeline encourages collaboration and transparency.
If you have automatic deployments and good cross-team communication (UX, Design, Developers etc.), with constant back and forth, planning sessions, etc. then you're constantly moving forward and everyone's confidence grows, individually and in the project as a whole. It creates a momentum that would otherwise be impossible.
That confidence comes from a clear, shared vision. A robust technical pipeline, that can tell us that what we're building is what we expected. And that our technical skill is being used in the right place and heading in the right direction.
Feedback is a more data-focused section of the cycle. Analytics tools, both for users and for internal feedback, are all important and useful in gaining insights. We often lack a good feedback mechanism for the health of our architecture. Mapping churn vs maintainability can plug that gap. Churn is how often a file or section of the codebase is edited. Maintainability can be estimated based on the complexity of a feature or section. If you map that out with churn on the X-axis, you end up with a heat map that can help highlight areas for additional testing or potential refactoring.
Critically, those feedback loops need to empower learning. Insights and value stream metrics are useless unless they result in positive change.
Q&A
What are some diagramming tools that are useful? There aren't many truly great ones out there. Draw.io is useful [yep 😉]. You can get a lot of out of Keynote and Powerpoint.
If a project has deployed recently then I know we're building up assumptions over time and that's something that I want to avoid; we want to deploy more frequently.
---
And we're done! What an amazing afternoon/night 😀 This was my first major conference that used Zoom and I thought it worked really well, particularly the Q&A section, though it did lack a feeling of community. I guess React Summit had a tighter feeling because of the Twitter counter going by constantly, it let me see that there were loads of other people getting involved. UnConference, by comparison, often felt like a private live stream. Not sure one is necessarily better than the other, it's just a slightly different vibe. Still, the cameos and mini-breaks were great, I thought UnConference had a better overall structure, and absolutely zero technical issues. 👍👍
