You can have a look to recipes by category, or even subscribed to a category and get notified!

Designed and developed from scratch.

Users who register in this webapp will be able to contact with other users that are nearby, or that belong to the same sports club.

Public feed with messages, photos and updates from institutions and sport lovers.

First, this is not an anti-Figma post. We need many tools and processes for the many designers and design challenges out there. This is a post describing why I no longer use Figma and what process has proved more efficient for me.

Figma is an ambitious—and pretty cool—piece of software: it improves collaboration and makes project handoff tidier than previous tools.

My work, like yours, is a particular flavor of UX and Design: I work in web development; Our programming team works in 2-week agile sprints; we’re a non-profit; and so on. For me in my current role, and despite its cool features, I found that Figma was building in inefficiencies and contributing to misunderstandings on our team’s path towards a working product.

Below I share the drawbacks of Figma we ran into, an alternative workflow, and it’s benefits.

Drawbacks

1. With Figma, handoff is baked into the process. As described on their own website, Figma can “create responsive components that map closer to code, making developer handoff more seamless.” Closer to code is a long ways from being code, and a more seamless handoff is still a handoff. Just one example of this is Figma’s lack of breakpoints: any breakpoints you want to demo must be build by hand in Figma, and then redone in code. Unnecessary handoffs are not an efficient use of design time.

2. Figma can’t directly contribute to our agile team goals of building, testing, and improving by incremental product iterations for a simple reason: it generates a design artifact and doesn’t contribute to the product itself.

3. Everyone can understand a website, not so with a mockup. Figma’s outputs also require accompanying descriptions and documentation of intent to be understood by all parties, or we risk creating comprehension debt.

4. Figma’s front-loading of design is more aligned with waterfall processes. I am not anti-waterfall, it is a great pattern when specifications are known up front and change is unlikely… but that does not describe any software project I have ever worked on.

5. Programmers who rely on assistive technology are blocked out of the process until Figma has been translated to code. Figma projects are born inaccessible, the opposite of what we are working towards. Figma’s accessible prototypes are in beta, but even when completed AT BEST they will deliver a very limited version of the accessibility that HTML already offers.

6. Another consequence of siloing the design process is that programmers are left holding the accessibility hot potato. Designers should be deeply involved in the building and testing of accessible layouts, too, and the project is weaker for fragmenting building and testing a product from designing it.

7. Lastly, Figma is a tool for visual design and, while it does not dictate a polished outcome, it certainly encourages it. A good-looking artifact too early in the process shifts attention away from requirements and usability and towards layout. Design is a powerful tool of persuasion, but achieving buy-in too quickly kills discovery.

An alternative

My alternative process is to work directly on functional prototypes written in HTML. Some designers start to get pretty nervous at this point, but bear with me a little longer: as designers we have a long history of over-emphasizing the difficulty of coding, and we also have more options all the time to make code accessible. There are nocode options like Webflow or Quixi that may meet your needs. Or if you need full control there are many, many UI component libraries and CSS frameworks that make simple front end prototyping much easier.

On my team we use CSS/HTML frameworks and component libraries for rapid prototyping, and it almost becomes a copy/paste exercise. It is not hard; in fact, it is so easy I often feel like a fraud, perhaps because my design training taught me that coding websites is both hard and someone else’s job. But I ignore that voice because prototyping at the level I need is doable, produces useful code, and accelerates our project goals.

Benefits

1. The biggest benefit is that a functional prototype speaks everyone’s language out of the box: engineers, designers, end users, everyone, we all understand web functions presented in a browser. It taps into mental models we already share. As Teresa Torres urges us, we should continually “visualize our thinking” in ways “that are easy for other people on your team to understand.” I know of nothing as easy to understand across a diverse group of people as a functional prototype in HTML.

2. Working on a functional prototype mitigates handoff because the prototype IS the product. Sure, at some point my coding hits a wall (and often pretty quickly) and then it is time for developers to dive in. The prototype makes that transition much easier. It acts as a living specification, clarifies intent in myriad ways, and is a single reference point for all parties.

3. Furthermore, no design can think of everything up front. As Raj Naggapan puts it, “The necessity to pivot based on feedback from a working demo is not a far fetched idea.” With a prototype, change requirements can be worked on by designers and engineers as they arise, and in a shared environment, without the need for additional handoffs.

4. Responsiveness and accessibility can be tested in their native habitat, and with standard tools, from the earliest stages of the project. Accessibility is not an enforced afterthought due to designing in non-web native tools; instead it becomes a natural part of each stage of the project build. And if you are lucky enough to have an engineer on your team who relies on assistive technology themselves, there is no delay to their involvement. Unlike when working in Figma, we can ensure our product is born accessible, even in very early stages.

5. The one constant we can rely on is that projects change and morph, which is what agile strives to embody for programming. With this process, design can be iterated upon too, and be informed by the continuous user testing that this way of working empowers.

Conclusion

On my product team, front loading design has too many drawbacks. We have dropped a Figma-based design process in favor of rapid prototyping in HTML/CSS using frameworks and UI libraries. Here is a recent case study I wrote, just one example of what this process can look like. For myself, iterative functional prototyping makes UX and design far too enjoyable and efficient for me to return to a front-loaded, handoff-dependent way of working.

This article originally written by Shamsi Brinn and published on Medium

The religion of fast product

As the Facebook doctrine for success goes, move fast and break things. This is a ritual practised by many of the most evangelical product companies out there, but all too often it ends up being the people that get broken.

Burnout is a product of the constant self-flagellation of overworking, over-committing, and overstressing. Sure, if this is the cost of success then fine, it's your choice, however, this culture has become pervasive. It is a disease that has spread beyond the individual, throughout the company, and throughout the industry. Now if this was the only way to be successful, then cool, by all means, basque in the golden glory of the product gods, go to battle and if you shall fall, eat in the hall of Valhalla. But it's not the only way to succeed, it's just one way to do it and an inefficient way at that, with extremely high casualties. What worked for Mark Zuckerburg won't work for everyone, and if it did, what kind of world would we live in? Facebook is a mediocre product trading on the insecurities of humanity and the leader has mistaken himself for a god surviving on the misfortunes of others. What we need are real tools that improve the human experience, and to do that we need a doctrine that respects humanity from the beginning, we need to move humbly and create things.

As the old adage for success goes, work smarter not harder. If product people are still focusing instead on moving fast and breaking things, it makes me wonder how committed they really are towards doing things in an intelligible way. It seems like the easy way out of a complex pickle, spray and pray. Instead of planning and strategising, they jump to conclusions and brute force their way through the problem, leaving everyone stressed when the ends fray. As they say, there is no such thing as a free lunch, but I believe, if you go about it smartly, you could get something delicious without breaking an arm.

The cost of dancing with the devil

According to the US National Institute for Occupational Safety and Health (NIOSH), Health care expenditures are nearly 50% greater for workers who report high levels of stress. This is because of the way your body reacts to being exposed to long endured and constant stress. Your body becomes fatigued by the constantly tense muscles, the overproduction of hormones and the overly active nervous system. Your body wears out and you become prone to illness and injury.

This not only impacts the person as an individual, but when you place a stressed person in a team, it stresses everyone else out. Stress is viral and it spreads through organisations prolifically. Stress becomes a part of the culture.

Within the context of a product development team's work, there are certain recurring factors that erode their well-being more than others. For them to do their work, they need everything upstream of them in the product development process to have been done completely and competently. They need clear product visions, strategies and goals. When they are left to do their work without these things, it's like being asked to run a race without shoes, a map or even knowing where the finish line is.

Teams are not only sacrificing a large piece of themselves to the product gods for the ascension of their companies into the pantheons of power but they are also the ones left paying the cost long after they leave. Dance with the devil and he will forever have you in his grips.

Stress is a multi-headed demon

Fast process or slow process, pace isn't the real meat with the potatoes. Pace is just a vanity metric, an easy-to-measure façade that distracts the uninquisitive from taking off their rose-tinted glasses and seeing the demon for what it is. Stress is ugly and complicated. Perhaps that's the source of this conundrum, that the move fast and break things ideology has been an easy-to-comprehend distraction from the fact that things are emergent and we really don't know what's going on, we are all actually on magic carpets flying by the seat of our pants.

The reality is that the world is chaotic, and our primal instinct is to make sense of it. Things pop up like snakes all around us all the time, continuously competing for attention, but we can only cut down one at a time. We are stretched thin trying to focus on too many things at once and this will leave us overwhelmed and we will get bitten.

Culture is everything

The culture of an organisation is the sum of the behaviours that the team members do. It is important to remember that product development is a team sport. We often refer to cultures as either being great or toxic. These terms are highly subjective and vague so I prefer to look at it in terms of cultures that promote product success or inhibit it. Of course, even though the hiring managers will be bragging to all their candidates about how great their culture is, no culture is perfect. It is filled with all the complexities and flaws that we humans have, that’s just the way it is and we need to own it. Smart companies look to create ecosystems that nurture a culture to become more promoting of product success (Through retros, feedback, and focusing on soft skills). Others simply ignore it entirely and instead focus on the business results ( They typically tell their employees to work more efficiently or else!). The reason Facebook used the motto move fast and break things was not because it sounded cool, but to deploy a way of working throughout the organisation. They wanted to build a culture around certain expected behaviours. They wanted people not to worry about quality, and just focus on disrupting. However, optimising for maximum disruption leaves a lot of things broken in its wake. I believe that in order to build great products that can solve the world's problems, we need to start optimising for something else completely. We need to optimise the experience of the people at the heart of the organisation, because if the employees have a great experience, then that will filter through to the work they do, meaning better products and better customer experiences.

Summary

Moving fast and breaking things has been a recipe for the short-term success of a few people, however as a result, it has left the majority of us broken (employees and users). But now the tide is turning and more and more people are wanting a different future, one that supports the people behind the products and one that creates meaningful experiences for the users. Now is the time to do things differently, so ask yourself, do you want to move fast and break things? or would you prefer to move smart and create things?

Last month, I had the chance to attend CSS Day in Amsterdam, a two day event split between a “UI day” focusing on the intersection of design and development and a “CSS day”, with speakers who covered more in-depth, technical CSS subjects. The talks were as diverse as the background of the speakers themselves, but there was one common thread: In this era of rapid change, are we, as product people, equipped to design for automation, machine learning, and AI?

What does automation mean for designers?

It's hard to work on a product team that hasn’t automated some part of their workflow in the name of productivity. If machines can take care of the repeatable tasks and heavy lifting, designers can focus on doing more meaningful work. But how does this affect the way we use the work being created by machines?

Josh Clark, founder of design studio Big Medium, provoked the audience with this very question during his talk, ‘A.I. is your New Design Material’. Some of the most impressive advancements in recent technology are things like facial recognition, predictive text, and image search, all powered by machine learning. But it's important to remember—all of these technologies are still built on code. The upside is less room for error. No real emotions, expectations, or feelings get in the way of the job it was designed to do.

Yet, as humans, we assume that when facial recognition fails, the whole process is inherently flawed. But was it really?

According to Josh, that is the most fundamental thing to understand when it comes to machines. Not meeting our human expectations, doesn’t automatically make the technology itself a failure. These things were, by definition, built on logic, which begs the question: Can a robot's solution actually be wrong?

The point of introducing machine learning into our products was never to have them do all the work. Instead, algorithms and logic-based solutions ought only provide humans with better insight so as to empower us to arrive at better solutions, faster.

This fundamental understanding our users that really helps us make better products. This might be a simple example, but if a computer can figure out how to walk on it's own, maybe it's time to start investigating why and how these solutions were formed.

How do we design for the unknown future?

Jared Spool, Co-Founder of UIE asks, “What was the most important thing you learned yesterday, and how will it impact what you do in the future?”

As designers and researchers, we essentially always need to think about how we design products for the future, even as we’re meeting the demands of present day design. A tall order, especially when things move as fast as they have been over the last decade.

To start, Jared advocates for looking back at the ways in which our design processes have already changed.

Remember when UX/UI wasn't a priority for many companies? As a consultant during a time when the Internet had yet to hit mass market appeal, Jared was able to steer many companies into a mindset that considered the user experience of a product.

But this also lets us gain input into how UX and UI has looked over the years, which might give us a better idea of what these concepts will look like moving forward. Jared describes a term called "The UX Tipping Point", with great actionable steps on how to get there.

In the past, designers had to fight for a seat at the table. If today you’re not starting from a place of advocating for user experience (like they were 10 years ago), they’re likely not starting at that tipping point. As a result, designers still have to ensure that the role of UX matures within the company, as well as the understanding of what makes UX important. When an organization hits the last stage, and fully embraces UX design from everything the company does, they fully hit The UX Tipping Point.

Are we designing for users or ourselves?

People don't always know what they want, even if they think the do. As Joe Leech, a UX psychologist says, "People want more choices, but can't deal with them.”

So how do we design for our users, if our users aren’t always telling us the truth? This is one of the most important questions, and something that extensive UX research helps us accomplish.

Back in the 2000s, psychologists Sheena Iyengar and Mark Lepper ran a study regarding consumer choices. They went to a local supermarket, and instructed the store to only sell 6 varieties of jam one week, followed by 30 varieties the following week.

They ran a study on how much jam was sold, and to everyone's surprise, more jam was sold on the week with only 6 choices. But interestingly enough, when the consumers were asked which week they preferred more, they responded with the week that had 30 choices.

Using this analogy, Joe makes a point that is hard to argue with, “A designer who doesn't understand psychology is going to be more successful than an architect who doesn't understand physics".

User research, and a wide variety of it, helps teams get as close as possible to the root of a user’s needs, over their wants. Studying responses on a larger scale is more work, but it helps form the foundation for true UX.