A few weeks ago, we asked our readers and the community to use everything they could to make their websites and projects perform blazingly fast. Today, we’re thrilled to show off the results of this challenge and announce the winner who will be awarded with some smashing prizes indeed!
What prizes, you ask? The winner wins a roundtrip flight to London, full accommodation in a fancy hotel, a ticket to SmashingConf London 2018, and last but not least, a Smashing workshop of their choice.
(This is a sponsored post). What do UX designers do on a daily basis? A lot of things! UX professionals need to communicate design ideas and research findings to a range of audiences. They use deliverables (tangible records of work that has occurred) for that purpose.
The list below contains the most common deliverables produced by UX designers as they craft great experiences for users. For better readability, I’ve combined the deliverables according to UX activities:
User interface design has changed dramatically in the last few years, as traditional computers have ceded dominance to smaller screens, including tablets, mobile phones, smartwatches and more.
As the craft has evolved, so has its toolset; and from one app to rule them all — looking at you, Photoshop! — we have gotten to a point where it seems like a new contender among UI design tools crops up every month.
Sketch is known for its tricky, advanced facets, but it’s not rocket science. We’ve got you covered with The Sketch Handbook which is filled with practical examples and tutorials that will help you get the most out of this mighty tool. In today’s article, Christian Krammer gives us a little taste of all the impressive designs Sketch is capable of bringing to life. — Ed.
Music plays a big role in my life. For the most part, I listen to music when I’m commuting, but also when I’m exercising or doing some housework. It makes the time fly, and I couldn’t imagine living without it.
However, one thing that has always bothered me is that the controls of music apps can be quite small and hard to catch. This can be a major issue, especially in the car, where every distraction matters. Another issue, in particular with the recent redesign of iOS’ Music app, is that you can’t directly like tracks anymore and instead need to open a separate dialog. And I do that a lot — which means one needless tap for me.
When working in a team, it’s important to stick to rules. A common challenge is to build all your projects with a similar or the same toolset and coding guidelines. Only yesterday I discussed how we could port over a project that outgrew its initial codebase over the years to a fresh, React.js-based source code.
The decision for this wasn’t easy, since we had invested quite a lot of work and money into this project already, and a move to React would require quite some time, too.
Although it’s April 1st, and people go all crazy making up jokes and spreading hoaxes, I’m sending out this edition to you without any April fools. Instead, I want to challenge you to put more effort, more thoughts into your code.
Instead of blindly following a given path to build the solution with the least effort, what about thinking more about your users? Wouldn’t a lot more users benefit from you spending an additional hour on building a form on your own instead of relying on a third party that involves tracking?
Working on very different projects, in different teams and with different people can sometimes be a challenge. But one thing that works out remarkably well is doing retrospectives with your team.
In retrospectives, you talk about how a certain project went, and the whole team shares what problems/challenges they faced, what was good and what was annoying people, why people were unhappy. And after each person has written this down on a wall (you can use Post-Its), you try to find useful solutions, small improvements that avoid conflicts, that avoid people feeling bad in a project, and that avoid unnecessary stress situations.
When they hit the front-end landscape a few years ago, preprocessors were heralded as the saviour of CSS, bringing modularity, meaning and even a degree of sexiness. Terms like “Sass architecture” became commonplace, ushering in a new generation of CSS developers who occasionally went to excess with their new-found power. The results were marvellous, and sometimes undesirable.
One of the unpleasant side effects was a preprocessor elitism that continues to persist. Neophyte designers who were just getting their hands dirty with CSS were overwhelmed by an influx of must-have tools and confused by the bitter partisan wars in web development forums.
I’ve travelled 2517 miles to try to solve 50 problems in 50 days using design, a journey that challenged me to fundamentally rethink my understanding of the user-experience design process.
I set myself a challenge. I wanted to test the limits of design’s ability to solve problems — big and small. To do this, I left the comfort of my computer chair and set out into the unknown. Every day, I had 24 hours to observe a problem, attempt to solve it and then communicate the solution.