A few weeks back I had the pleasure of attending Config 2021. This virtual event was inspirational, and packed with information and insights I want to bring back to kreuzwerker. The conference was held on hopin platform and emphasised principles of equality and accessibility, aiming to make all attendees feel included and comfortable.
Over the course of two days I had the opportunity to hear from more than 60 speakers, coming from across the world and ranging from corporations to small agencies and independent professionals. Each day of the conference began with an opening keynote from Figma creators and continued with six half-hour slots on four different stages. The attendees could select one from four to five available talks in each slot. Needless to say sometimes the choice was tough to make.
When the conference was over, it left me excited about the upcoming Figma features, and also about a few topics, on which I’d like to reflect.
What’s on the near horizon in the Figma ecosystem?
The opening keynote from Figma’s CEO Dylan Field instantly heated up the atmosphere. The upcoming features include audio calls for even more seamless collaboration and increased limit of collaborators, but most importantly branching; a concept well known in development, which might be a real game changer when applied to a design tool.
Resolving merge conflicts in Figma
There were also other exciting announcements: Figma Community finally moving from beta to public, Figma mobile app with improved mirroring and project browsing features to be released soon, and a new remote collaboration tool called FigJam being added to Figma ecosystem. The last one has great chances to become a strong competitor to Miro and Mural among design teams, offering seamless integration with Figma files, audio communication and tons of design-oriented templates.
FigJam - a new whiteboarding tool from Figma
Making design process inclusive through low fidelity
How to break that wall between designers and non-designers? How to engage the stakeholders, developers and other team members early in the creative process? Daniel Sauble gave a very inspiring talk about how low fidelity could make this happen.
Moving too quickly to high fidelity can create barriers for exploring ideas and hinder the creative process: whether it’s an opinionated stakeholder wanting to get his best idea to go live as quickly as possible, or an overly polite user giving filtered and uninsightful feedback, or a disempowered developer spending a lot of time on building something aligned 1:1 with the design.
Allowing non-designer team members to take an active part in the exploration phase creates space for expressing one’s own ideas and communicating potential limitations early on. It can be achieved through iterating on visually-simplified design artifacts such as scribbles, storyboards and sketches.
At this point it’s not important how the solution should look, rather it’s about what’s the rough idea behind it. And instead of focusing on a single idea, it helps to have a small set of them, even if some seem imperfect.
Low fidelity exploration allows the team members to feel more engaged in the process, empowers their creativity and induces conversations around the feasibility early on.
Auditing design systems for accessibility
Another great talk was held by Anna E. Cook who touched the topic of accessibility in design systems. Whether it’s permanent, temporary or simply situational, disabilities can touch everyone at any time. It’s the only marginalized group that one can fall into from day to the next. In the context of web and technology, the inaccessibility leads to disability, leaving out those who need support.
According to WebAIM’s 2020 annual accessibility analysis of the top one milion home pages, about 98% of them suffer from accessibility issues. Just to list a few most severe types of problems: low contrast, missing alternative texts and form labels, and empty links and buttons. It looks like there’s a lot of work to be done, but also quite some space to improve on how we actually think about the users.
Thinking about accessibility early in the process can significantly lower the amount of accessibility bugs, leading to actually lowering the overall development costs. While it’s relatively easy to implement when working on a new project, it’s more challenging when it comes to improving accessibility of existing solutions. If a design system is already in place, auditing it is a good place to start. The same way the design is easily scalable with design systems, it also applies to easily scaling the accessibility.
The Web Content Accessibility Guidelines (WCAG) provides the standards on making online content accessible to disabled users. After collecting the findings into an inventory, each item needs to be checked against the relevant WCAG guidelines to document potential issues and ideas on how to fix them. According to the speaker, the most surfaced issues found during such audits are: color and contrast, content readability, hover and focus states, forms and validation, tab order, and link purpose. But the list can go on.
Ideally, fixing the problems should happen both on the design artifact level and also in code. Regardless if it’s done by using automated tools or by manually reviewing libraries and live pages, partnering with developers to audit the code can only benefit the whole process.
Sharing audit results with the team and opening up a conversation between the designers, developers, managers and other stakeholders creates a space for improvements and can change the way the team thinks about accessibility.
Design for Code
I’ve mentioned earlier the importance of bringing the team together at the exploratory stage of the project. Now, how about finding a common understanding when things are already in motion or when designing a new product feature? A great talk by John Meguerian explained how sharing knowledge and building trust can help teams achieve this goal.
Structuring design files with developers in mind can help designers find common ground with them. The idea is to have a conversation and learn what naming conventions are being used, and how the interface element structure actually looks like in code. Using capabilities of design tools like Figma makes this possible.
How to keep things tidy in the design file? The answer is: the file should mirror how the design will be implemented. Use separate pages for collecting components, building views out of those components, and finally connecting the views to create an interactive prototype. One element builds on top of another. What I love about it, is that with each edit on the component level the designer doesn’t need to worry about updating all of those views or the prototype. It happens automatically.
Apart from the naming convention, the important bit about documenting components is to capture their variants, states, behavior and anatomy. I’m talking about specific details that require designer comments rather than listing all element’s properties. Those can be accessed in Figma’s code panel.
Going one level up, the views should be composed of component instances. As mentioned earlier, this approach saves a lot of effort when updating components, because all changes are automatically propagated to all instances. In an ideal scenario, the designer would use real content inside component instances to assure the component or view layouts work and look as planned.
Last but not least, the prototype. It follows the atomic approach from above: the interactive prototype is built from views and nothing else. The important thing to remember while building a prototype is to make all the “happy paths” reachable, assuring the main flows are complete.
The bottom line is: understanding each other’s tools and using common language within the team unlocks the full potential of collaboration between designers, developers and stakeholders.
This covers only a part when it comes to all of the learnings from the Config 2021 conference. I’m excited to dig deeper into all of those topics, expand my knowledge and apply everything I learned from the conference talks to our work at kreuzwerker.