5 React Architecture Best Practices

There can be no doubt that React has revolutionized the way we build user interfaces. It’s easy to learn and greatly facilitates creating reusable components that offer your site a consistent look and feel. However, as React only takes care of the view layer of an application, it doesn’t enforce any specific architecture (such as […]

Continue reading %5 React Architecture Best Practices%

Source: Sitepoint

Sharing Code Between Projects: Lessons Learned In The Trenches

Sharing Code Between Projects: Lessons Learned In The Trenches

Sharing Code Between Projects: Lessons Learned In The Trenches

Jonathan Saring


About a year ago, we came to a crossroad that changed the way we build software today. Like many other teams, we were working on a few things at a time, developing different projects for our web and mobile applications, with shared ingredients in the form of common Node.js code between our back-end repositoriess and microservices, and common React UI components with some slight visual and functional differences between our apps.

As our team grew and code lines multiplied, we began to realize that with every passing day we were writing the same code over and over again. Over time, it became harder to maintain our code base and develop new features with the same speed and efficiency.

Finally, we decided to find a solution that would enable us to share and sync common components of code between our projects. Here is what we learned along our journey, which eventually gave birth to Bit.

Sharing code components between projects

Code components as building blocks. (Large preview)

Common Code In The Wild

While Git is great for collaborating on a single repository, sharing code between multiple projects can be more challenging than we think.

To get started, we looked into our own code base to learn how many times we duplicated our own integration to our user service. The unbelievable result was no less than 86 instances. After the initial shock, we started thinking that this must also be happening elsewhere.

Code shared in multiple projects

Using the same code in different places. (Large preview)

We asked some friends working in a few different organizations of various sizes to run a simple copy-and-paste detection on their code base, looking for duplicates of code longer than 100 lines. The result blew us away: On average, more than 30% of their code base was duplicated.

Finally, we decided to look deep into the open-source projects on GitHub, checking for both duplications and re-implementations of a simple isString function in the 10,000 most popular JavaScript GitHub projects.

Amazingly, we found this function was implemented in more than 100 different ways and duplicated over 1,000 times in only 10,000 repositories. Later studies claim that over 50% of the code on GitHub is actually duplicated. We realized we were not the only ones facing this issue.

Looking For A Solution

Before building Bit, we looked for a tool that would help us turn the smaller components that our apps are built from into building blocks that could be shared between our projects and synced across our code base. We also wanted to organize them and make them discoverable for our team. Here’s a short summary of what we learned.

A Micro-Package Arsenal With NPM

At first, we considered publishing all of our UI components, utility functions and smaller modules as packages to NPM. This seemed like the obvious solution for modularity for our software’s building blocks. However, we quickly learned that this solution came with huge overhead.

Trying to publish a few files from our project to NPM forced us to split our repository and create new ones just to share this code. When dealing with hundreds of components, this meant having to maintain and make changes across hundreds of repositories.

We would also have to refactor our code base, removing the newly created packages from their original repositories, boilerplating the packages in the new repositories and so on.

Even then, we had now a simple way to organize these packages and make them easily discoverable to our entire team. Another major problem was the coupling between the packages and the owners of their origin repositories, which made it nearly impossible for other people to quickly make updates to the packages while working on their own projects.

This kind of overhead was too much for us to handle. So, we quickly decided to look for a better way to share our code.

Lerna Monorepos

The next option we came up with was to use Lerna in order to refactor our code base into a few multi-package repositories, often referred to as “monorepos”.

The Hydra of Lerna

Lerna multi-package repository. (Large preview)

The upside of this solution was that it would allow us to maintain and publish all our packages from a single repository. However, this option, too, came with a set of drawbacks, particularly when working with smaller components.

Choosing this option meant we would still have to effectively keep multiple packages with multiple package.json files, multiple build and test environments and a complicated dependency tree to handle between them. Updating these packages must also go through the main repository, still making it hard to modify these package from other projects when working with a few separate monorepos.

For example, take the popular Material-UI React UI library. Even though it uses Lerna to publish five different packages from the same repository, you would still have to install the entire library to use each of its components. Making changes would still have to go through that project as well, and discoverability for these component didn’t improve.

Monorepos can be great for some cases (such as testing or building a project as a whole) and can definitely work for some teams. However, refactoring your entire code base just to share common code between projects while still having to struggle with the issues mentioned above made us drop this option as well.

Shared Libraries

This option was quickly dropped, too. In a lot of way, it resembles using a CD-ROMs instead of an iTunes playlist. First, it made no sense to force an entire library of React components and an entire utility library and so on on each of our projects.

Secondly, every project using it would be tightly coupled to the development of this library, making it impossible to adjust its components for each project. This becomes most painful when sharing common Node.js code between our microservices, which would now be coupled to the library.

Thirdly, discoverability within the library is bound to be poor and would involve a lot of work with its documentation and usage in different edge cases.

Because it makes very little sense to couple and slow down our development, we try to minimize the use of these libraries as much as possible. Even popular JavaScript utility libraries such as Lodash are working hard to make their smaller components independently available via NPM.

Git Submodules

Finally, we turned back time and looked into working with Git submodules.

Git enables you to make one repository a subdirectory of another repository, creating a single working tree for the entire project, so that a repository can utilize code from another repository.

As for many other teams, this solution did not last for us. First, submodules only work on the master branch, which causes problems for rapid development. Secondly, submodules increase coupling between projects, which makes it hard to work on cross-repository assignments. Finally, a submodule repository is oblivious to its own nesting and the existence of dependent repositories.

After trying these different solutions, we realized that it shouldn’t be this complicated. There really should be a simpler way to organize, share and develop components of code from different projects. So, we decided to build it, and called it Bit.

Building Bit

Our vision for a solution was simple: turn our components and modules into building blocks that can be easily isolated from any project, organized in the cloud and used in any project.

Bit sharing workflow

Isolate, share and organize your reusable code. (Large preview)

When building it, we set a few guidelines for what we needed from the project.

  • Make it seamless to isolate and share code components from any project, without having to create new repositories or manually configure build and test environments and dependencies for each component.
  • Enable two-way development, so that each component could be changed and updated from any project, while changes would be synced across our code base.
  • Make it simple to organize and share our components, while making them discoverable for our entire team with useful visual information.

After hard work and extensive research, in 2017 we released the first version of Bit to GitHub.

How It Works

Bit’s workflow is made of three simple steps:

  1. The first is to simply tell Bit which components of code you would like to share from your project, and it will immediately start tracking them in all of the projects you share them in.
  2. You can then tag a version for these components so that Bit automatically defines and locks their dependency tree for both file and package dependencies, and creates an isolated environment for each component to build and test in isolation.
  3. Finally, you can share the components to the cloud (or your own remote server), where they will be organized, will be made discoverable and can be installed with NPM or Yarn like any other package.

You don’t have to create new repositories, split your code base or refactor a single line of code.

Source: Smashing Magazine

Introducing the SitePoint Blockchain Newsletter

Whether it’s being hailed as a game-changer or derided as hype, these days blockchain is everywhere. But it’s hard to get trustworthy, unbiased news and tutorials about the tech. If you’re trying to enter the blockchain dev world, there’s a high price of entry.

This newsletter will offer a curated collection of links – news, tutorials, tool and projects – that’ll highlight some of the more interesting and exciting developments in this emerging field. These will be sourced by me, Adam. You may know me from my weekly Back-end and Design newsletters, or from Versioning, my daily newsletter focused on the bleeding-edge of web dev and design.

I promise this will be both on-the-chain and off-the-chain! Sign up here!

Still unsure? Here’s the first edition!

Bright Spark


First up, links to two programming languages for writing smart contracts on Ethereum.

For the latter, here’s a collection of programming patterns and best-practices

A new idea: crypto composables, allowing one non-fungible token to own another. The (useful, for me) metaphor used in the article was buying a house – you’re actually buying the title for land, the house is just part of the transaction.

Advice for those using React Create App to build DApps – the React Service Worker may trip you up.

DAppy Gilmore


An intro to a 2-month study plan for learning blockchain, and the links for the various subjects mentioned.

An intro exactly what DApps are.

5 very interesting DApps.

If you haven’t already, check out the Golem network, given it’s a very prominent example of a non-cryptocurrency application of the blockchain, here’s an intro to what that thing is.

An intro to EOS, the Epic Operating System, set to launch June 7.

A good podcast discussion of Popula, a blockchain-powered, censorship-proof(? maybe) publication.

Cryptocurrency vloggers are literally being robbed because they’re sharing waaaaay too much information about their logins, portfolios etc.

Whole Latte Love

Fun stuff

This Seattle startup is combining coffee and the blockchain and virtual reality to transform the coffee industry. Is it possible, and just go with me here, that they are maybe throwing too many things into the mix here? Just me? OK.

Finally, CryptoWorldCup is a DApp on the Ethereum blockchain that allows you to securely, transparently bet on the Russia World Cup. If you’re curious, this thread on /r/ethdev has a nice little critique of the structure of the DApp – might be handy to all y’all Dapp-ists out there.

There’s the inaugural Blockchain Newsletter! I hope it was to your liking – please, please, please let me know if you have ideas or requests for improvements. On my end, it’s fun to explore this world that I usually just glimpse and slowly back away from.

Continue reading %Introducing the SitePoint Blockchain Newsletter%

Source: Sitepoint

Continuous Learning of Your iOS App Using App Center

This article was created in partnership with Microsoft. Thank you for supporting the partners who make SitePoint possible. App development is an iterative process, the work you do on version 2 of an app is largely based on the things you learned from building and releasing version 1. In order for your development efforts to […]

Continue reading %Continuous Learning of Your iOS App Using App Center%

Source: Sitepoint

Working Together: How Designers And Developers Can Communicate To Create Better Projects

Working Together: How Designers And Developers Can Communicate To Create Better Projects

Working Together: How Designers And Developers Can Communicate To Create Better Projects

Rachel Andrew


Among the most popular suggestions on Smashing Magazine’s Content User Suggestions board is the need of learning more about the interaction and communication between designers and developers. There are probably several articles worth of very specific things that could be covered here, but I thought I would kick things off with a general post rounding up some experiences on the subject.

Given the wide range of skills held by the line-up at our upcoming SmashingConf Toronto — a fully live, no-slides-allowed event, I decided to solicit some feedback. I’ve wrapped those up with my own experience of 20 years working alongside designers and other developers. I hope you will add your own experiences in the comments.

Some tips work best when you can be in the same room as your team, and others are helpful for the remote worker or freelancer. What shines through all of the advice, however, is the need to respect each other, and the fact that everyone is working to try and create the best outcome for the project.

Working Remotely And Staying Connected

The nomadic lifestyle is not right for everyone, but the only way to know for sure is to try. If you can afford to take the risk, go for it. Javier Cuello shares his experience and insights from his four years of travel and work. Read article →

For many years, my own web development company operated as an outsourced web development provider for design agencies. This involved doing everything from front-end development to implementing e-commerce and custom content management solutions. Our direct client was the designer or design agency who had brought us on board to help with the development aspect of the work, however, in an ideal situation, we would be part of the team working to deliver a great end result to the end client.

Sometimes this relationship worked well. We would feel a valued part of the team, our ideas and experience would count, we would work with the designers to come up with the best solution within budgetary, time, and other constraints.

In many cases, however, no attempt was made to form a team. The design agency would throw a picture of a website as a PDF file over the fence to us, then move on to work on their next project. There was little room for collaboration, and often the designer who had created the files was busy on some other work when we came back with questions.

It was an unsatisfactory way to work for everyone. We would be frustrated because we did not have a chance to help ensure that what was designed was possible to be built in a performant and accessible way, within the time and budget agreed on. The designer of the project would be frustrated: Why were these developers asking so many questions? Can they not just build the website as I have designed? Why are the fonts not the size I wanted?

The Waterfall versus Agile argument might be raised here. The situation where a PDF is thrown over the fence is often cited as an example of how bad a Waterfall approach is. Still, working in a fully Agile way is often not possible for teams made of freelancers or separate parties doing different parts of the work. Therefore, in reading these suggestions, look at them through the lens of the projects you work on. However, try not to completely discount something as unworkable because you can’t use the full process. There are often things we can take without needing to fully adopt one methodology or another.

Setting Up A Project For Success

I came to realize that very often the success of failure of the collaboration started before we even won the project, with the way in which we proposed the working relationship. We had to explain upfront that experience had taught us that the approach of us being handed a PDF, quoting and returning a website did not give the best results.

Projects that were successful had a far more iterative approach. It might not be possible to have us work alongside the designers or in a more Agile way. However, having a number of rounds of design and development with time for feedback from each side went a long way to prevent the frustrations of a method where work was completed by each side independently.

Creating Working Relationships

Having longer-term relationships with an agency, spanning a number of projects worked well. We got to know the designers, learned how they worked, could anticipate their questions and ensure that we answered them upfront. We were able to share development knowledge, the things that made a design easier or harder to implement which would, therefore, have an impact on time and budget. They were able to communicate better with us in order to explain why a certain design element was vital, even if it was going to add complexity.

For many freelance designers and developers, and also for those people who work for a distributed company, communication can become mostly text-based. This can make it particularly hard to build relationships. There might be a lot of communication — by email, in Slack, or through messages on a project management platform such as Basecamp. However, all of these methods leave us without the visual cues we might pick up from in-person meetings. An email we see as to the point may come across to the reader as if we are angry. The quick-fire nature of tools such as Slack might leave us committing in writing something which we would not say to that person while looking into their eyes!

Freelance data scientist Nadieh Bremer will talk to us about visualizing data in Toronto. She has learned that meeting people face to face — or at least having a video call — is important. She told me:

Nadieh Bremer

“As a remote freelancer, I know that to interact well with my clients I really need to have a video call (stress on the video) I need to see their face and facial/body interactions and they need to see mine. For clients that I have within public transport distance, I used to travel there for a first ‘getting to know each other/see if we can do a project’ meeting, which would take loads of time. But I noticed for my clients abroad (that I can’t visit anyway) that a first client call (again, make sure it’s a video-call) works more than good enough.

It’s the perfect way to weed out the clients that need other skills that I can give, those that are looking for a cheap deal, and those where I just felt something wasn’t quite clicking or I’m not enthusiastic about the project after they’ve given me a better explanation. So these days I also ask my clients in the Netherlands, where I live, that might want to do a first meeting to have it online (and once we get on to an actual contract I can come by if it’s beneficial).”

Working In The Open

Working in the open (with the project frequently deployed to a staging server that everyone had access to see), helped to support an iterative approach to development. I found that it was important to support that live version with explanations and notes of what to look at and test and what was still half finished. If I just invited people to look at it without that information we would get lists of fixes to make to unfinished features, which is a waste of time for the person doing the reporting. However, a live staging version, plus notes in a collaboration tool such as Basecamp meant that we could deploy sections and post asking for feedback on specific things. This helped to keep everyone up to date and part of the project even if — as was often the case for designers in an agency — they had a number of other projects to work on.

There are collaboration tools to help designers to share their work too. Asking for recommendations on Twitter gave me suggestions for Zeplin, Invision, Figma, and Adobe XD. Showing work in progress to a developer can help them to catch things that might be tricky before they are signed off by the client. By sharing the goal behind a particular design feature within the team, a way forward can be devised that meets the goal without blowing the budget.

Screenshot of the Zeplin homepage
Zeplin is a collaboration tool for developers and designers

Scope Creep And Change Requests

The thing about working in the open is that people then start to have ideas (which should be a positive thing), however, most timescales and budgets are not infinite! This means you need to learn to deal with scope creep and change requests in a way that maintains a good working relationship.

We would often get requests for things that were trivial to implement with a message saying how sorry they were about this huge change and requests for incredibly time-consuming things with an assumption it would be quick. Someone who is not a specialist has no idea how long anything will take. Why should they? It is important to remember this rather than getting frustrated about the big changes that are being asked for. Have a conversation about the change, explain why it is more complex than it might appear, and try to work out whether this is a vital addition or change, or just a nice idea that someone has had.

If the change is not essential, then it may be enough to log it somewhere as a phase two request, demonstrating that it has been heard and won’t be forgotten. If the big change is still being requested, we would outline the time it would take and give options. This might mean dropping some other feature if a project has a fixed budget and tight deadline. If there was flexibility then we could outline the implications on both costs and end date.

With regard to costs and timescales, we learned early on to pad our project quotes in order that we could absorb some small changes without needing to increase costs or delay completion. This helped with the relationship between the agency and ourselves as they didn’t feel as if they were being constantly nickel and dimed. Small changes were expected as part of the process of development. I also never wrote these up in a quote as contingency, as a client would read that and think they should be able to get the project done without dipping into the contingency. I just added the time to the quote for the overall project. If the project ran smoothly and we didn’t need that time and money, then the client got a smaller bill. No one is ever unhappy about being invoiced for less than they expected!

This approach can work even for people working in-house. Adding some time to your estimates means that you can absorb small changes without needing to extend the timescales. It helps working relationships if you are someone who is able to say yes as often as possible.

This does require that you become adept at estimating timescales. This is a skill you can develop by logging your time to achieve your work, even if you don’t need to log your time for work purposes. While many of the things you design or develop will be unique, and seem impossible to estimate, by consistently logging your time you will generally find that your ballpark estimates become more accurate as you make yourself aware of how long things really take.


Aaron Draplin will be bringing tales from his career in design to Toronto, and responded with the thought that it comes down to respect for your colleague’s craft:

Aaron Draplin

“It all comes down to respect for your colleague’s craft, and sort of knowing your place and precisely where you fit into the project. When working with a developer, I surrender to them in a creative way, and then, defuse whatever power play they might try to make on me by leading the charges with constructive design advice, lightning-fast email replies and generally keeping the spirit upbeat. It’s an odd offense to play. I’m not down with the adversarial stuff. I’m quick to remind them we are all in the same boat, and, who’s paying their paycheck. And that’s not me. It’s the client. I’ll forever be on their team, you know? We make the stuff for the client. Not just me. Not ‘my team’. We do it together. This simple methodology has always gone a long way for me.”

I love this, it underpins everything that this article discusses. Think back to any working relationship that has gone bad, how many of those involved you feeling as if the other person just didn’t understand your point of view or the things you believe are important? Most reasonable people understand that compromise has to be made, it is when it appears that your point of view is not considered that frustration sets in.

There are sometimes situations where a decision is being made, and your experience tells you it is going to result in a bad outcome for the project, yet you are overruled. On a few occasions, decisions were made that I believed so poor; I asked for the decision and our objection to it be put in writing, in order that we could not be held accountable for any bad outcome in future. This is not something you should feel the need to do often, however, it is quite powerful and sometimes results in the decision being reversed. An example would be of a client who keeps insisting on doing something that would cause an accessibility problem for a section of their potential audience. If explaining the issue does not help, and the client insists on continuing, ask for that decision in writing in order to document your professional advice.

Learning The Language

I recently had the chance to bring my CSS Layout Workshop not to my usual groups of front-end developers but instead to a group of UX designers. Many of the attendees were there not to improve their front-end development skills, but more to understand enough of how modern CSS Layout worked that they could have better conversations with the developers who built their designs. Many of them had also spent years being told that certain things were not possible on the web, but were realizing that the possibilities in CSS were changing through things like CSS Grid. They were learning some CSS not necessarily to become proficient in shipping it to production, but so they could share a common language with developers.

There are often debates on whether “designers should learn to code.” In reality, I think we all need to learn something of the language, skills, and priorities of the other people on our teams. As Aaron reminded us, we are all on the same team, we are making stuff together. Designers should learn something about code just as developers should also learn something of design. This gives us more of a shared language and understanding.

Seb Lee-Delisle, who will speak on the subject of Hack to the Future in Toronto, agrees:

Seb Lee-Delisle

“I have basically made a career out of being both technical and creative so I strongly feel that the more crossover the better. Obviously what I do now is wonderfully free of the constraints of client work but even so, I do think that if you can blur those edges, it’s gonna be good for you. It’s why I speak at design conferences and encourage designers to play with creative coding, and I speak at tech conferences to persuade coders to improve their visual acuity. Also with creative coding. 🙂 It’s good because not only do I get to work across both disciplines, but also I get to annoy both designers and coders in equal measure.”

I have found that introducing designers to browser DevTools (in particular the layout tools in Firefox and also to various code generators on the web) has been helpful. By being able to test ideas out without writing code, helps a designer who isn’t confident in writing code to have better conversations with their developer colleagues. Playing with tools such as gradient generators, clip-path or animation tools can also help designers see what is possible on the web today.

Screenshot of Animista
Animista has demos of different styles of animation

We are also seeing a number of tools that can help people create websites in a more visual way. Developers can sometimes turn their noses up about the code output of such tools, and it’s true they probably won’t be the best choice for the production code of a large project. However, they can be an excellent way for everyone to prototype ideas, without needing to write code. Those prototypes can then be turned into robust, permanent and scalable versions for production.

An important tip for developers is to refrain from commenting on the code quality of prototypes from members of the team who do not ship production code! Stick to what the prototype is showing as opposed to how it has been built.

A Practical Suggestion To Make Things Visual

Eva-Lotta Lamm will be speaking in Toronto about Sketching and perhaps unsurprisingly passed on practical tips for helping conversation by visualizing the problem to support a conversation.

Eva-Lotta Lamm

Creating a shared picture of a problem or a solution is a simple but powerful tool to create understanding and make sure they everybody is talking about the same thing.

Visualizing a problem can reach from quick sketches on a whiteboard to more complex diagrams, like customer journey diagrams or service blueprints.

But even just spatially distributing words on a surface adds a valuable layer of meaning. Something as simple as arranging post-its on a whiteboard in different ways can help us to see relationships, notice patterns, find gaps and spot outliers or anomalies. If we add simple structural elements (like arrows, connectors, frames, and dividers) and some sketches into the mix, the relationships become even more obvious.

Visualising a problem creates context and builds a structural frame that future information, questions, and ideas can be added to in a ‘systematic’ way.

Visuals are great to support a conversation, especially when the conversation is ‘messy’ and several people involved.

When we visualize a conversation, we create an external memory of the content, that is visible to everybody and that can easily be referred back to. We don’t have to hold everything in our mind. This frees up space in everybody’s mind to think and talk about other things without the fear of forgetting something important. Visuals also give us something concrete to hold on to and to follow along while listening to complex or abstract information.

When we have a visual map, we can point to particular pieces of content — a simple but powerful way to make sure everybody is talking about the same thing. And when referring back to something discussed earlier, the map automatically reminds us of the context and the connections to surrounding topics.

When we sketch out a problem, a solution or an idea the way we see it (literally) changes. Every time we express a thought in a different medium, we are forced to shape it in a specific way, which allows us to observe and analyze it from different angles.

Visualising forces us to make decisions about a problem that words alone don’t. We have to decide where to place each element, decide on its shape, size, its boldness, and color. We have to decide what we sketch and what we write. All these decisions require a deeper understanding of the problem and make important questions surface fairly quickly.

All in all, supporting your collaboration by making it more visual works like a catalyst for faster and better understanding.

Working in this way is obviously easier if your team is working in the same room. For distributed teams and freelancers, there are alternatives to communicate in ways other than words, e.g. by making a quick Screencast to demonstrate an issue, or even sketching and photographing a diagram can be incredibly helpful. There are collaborative tools such as Milanote, Mural, and Niice; such tools can help with the process Eva-Lotta described even if people can’t be in the same room.

Screenshot of the Niice website
Niice helps you to collect and discuss ideas

I’m very non-visual and have had to learn how useful these other methods of communication are to the people I work with. I have been guilty on many occasions of forgetting that just because I don’t personally find something useful, it is still helpful to other people. It is certainly a good idea to change how you are trying to communicate an idea if it becomes obvious that you are talking at cross-purposes.

Over To You

As with most things, there are many ways to work together. Even for remote teams, there is a range of tools which can help break down barriers to collaborating in a more visual way. However, no tool is able to fix problems caused by a lack of respect for the work of the rest of the team. A good relationship starts with the ability for all of us to take a step back from our strongly held opinions, listen to our colleagues, and learn to compromise. We can then choose tools and workflows which help to support that understanding that we are all on the same team, all trying to do a great job, and all have important viewpoints and experience to bring to the project.

I would love to hear your own experiences working together in the same room or remotely. What has worked well — or not worked at all! Tools, techniques, and lessons learned are all welcome in the comments. If you would be keen to see tutorials about specific tools or workflows mentioned here, perhaps add a suggestion to our User Suggestions board, too.

Smashing Editorial

Source: Smashing Magazine

On Failures And Successes: Meet SmashingConf Freiburg 2018

On Failures And Successes: Meet SmashingConf Freiburg 2018

On Failures And Successes: Meet SmashingConf Freiburg 2018

Vitaly Friedman


Everybody loves speaking about successes, but nobody can succeed without failing big time along the way. It’s through mistakes that we grow and get smarter. So for the upcoming SmashingConf Freiburg 2018 (Sept. 10–11), we want to put these stories into focus for a change and explore practical techniques and strategies learned in real projects — the hard way. Aarron Walter, Josh Clark, Tammy Everts, Morten Rand-Hendriksen & many others. Sept 10–11. Early-Birds are available now →

SmashingConf Freiburg 2018
One track, two days, honest talks, live sessions, and a handful of practical workshops. That’s SmashingConf Freiburg 2018! Excited yet?

The night before the conference we’ll be hosting a FailNight — a warm-up party with a twist. Every session will be highlighting how we all failed on a small or big scale, and what we all can learn from it. With talks from the community, for the community. Sounds like fun? Well, it will be!


As usual, one track, two conference days (Sept. 10–11), 12 speakers, and just 260 available seats. The conference will cover everything from efficient design workflow to design systems and copywriting, multi-cultural designs, designing for mobile and other fields that may come up in your day-to-day work.

First confirmed speakers include:

First confirmed speakers
Aarron Walter and Tammy Everts are two of the first confirmed speakers.

Conference Tickets

€499Get Your Ticket

Two days of great speakers and networking
Check all speakers →

Conf + Workshop Tickets

Save €100 Conf + Workshop

Three days full of learning and networking
Check all workshops →

Workshops At SmashingConf Freiburg

Our workshops give you the opportunity to spend a full day on the topic of your choice. Tickets for the full-day workshops cost €399. If you buy a workshop ticket in combination with a conference ticket, you’ll save €100 on the regular workshop ticket price. Seats are limited

Workshops on Wednesday, September 12th

Josh Clark on Design For What’s Next
Josh ClarkSpend a day exploring the web’s emerging interactions and how you can put them to work today. Your guide is designer Josh Clark, author of Designing for Touch and ambassador of the near future. As you move into newer design tools — speech, bots, physical interfaces, artificial intelligence, and more — you’ll learn the tools and techniques for prototyping and launching these new interfaces and get answers to foundational questions for all your projects. Read more…

Seb Lee-Delisle on JavaScript Graphics And Animation
Seb Lee-DelisleIn this workshop, Seb will demonstrate a variety of beautiful visual effects using JavaScript and HTML5 canvas. You will learn animation and graphics techniques that you can use to add a sense of dynamism to your projects. Seb demystifies programming and explores its artistic possibilities. His presentations and workshops enable artists to overcome their fear of code and encourage programmers of all backgrounds to be more creative and imaginative. Read more…

Vitaly Friedman on Dirty Little Tricks From The Dark Corners Of eCommerce
Vitaly FriedmanIn this workshop, Vitaly will use real-life examples as a case study and examine refinements of the interface on spot. You’ll set up a very clear roadmap on how you can do the right things in the right order to improve conversion and customer experience. That means removing distractions, minimizing friction and avoiding disruptions and dead ends caused by the interface. Read more…


As always, the Historical Merchants’ Hall located right in the heart of our hometown Freiburg will be the home of SmashingConf Freiburg. First mentioned in 1378 and having retained its present-day form since 1520, the “Kaufhaus” is a symbol of the importance of trade in medieval Freiburg, and, well, its beautiful architecture still blows our audience away each year anew.

Historical Merchants’ Hall
The “Kaufhaus” (Historical Merchants’ Hall) will be our Freiburg venue also this time around. (Image credit: John Davey)

Why This Conference Could Be For You

Each SmashingConf is a friendly and intimate experience. A cozy get-together of likeminded people who share their stories, their ideas, their hard-learned lessons. At SmashingConf Freiburg you will learn how to:

  1. Use production-ready CSS Grid layouts,
  2. Performance audits,
  3. Recognize, revise, and resolve dark patterns and misleading copy in your own products,
  4. Design and build a product with a global audience in mind,
  5. Extract action-oriented insights from real user data,
  6. Create better e-commerce experiences,
  7. Create responsible machine-learning applications,
  8. Get leading design right,
  9. … and a lot more.

Download “Convince Your Boss” PDF

You need to convince your boss to send you to Freiburg? No worries, we’ve prepared a neat Convince Your Boss PDF that you can use to tip the scales in your favor. Fingers crossed.

Diversity And Inclusivity

SmashingConfs are a safe, friendly place. We care about diversity and inclusivity at our events and don’t tolerate any disrespect. We also provide student and diversity tickets.

See You In Freiburg!

We’d love you to join us for two memorable days, lots of learning, sharing, and inspiring conversations with friendly people, of course. See you there!

Smashing Editorial
(ms, cm, il)

Source: Smashing Magazine

WP Crowdfunding: The Complete Solution for Fundraising Websites

This article was created in partnership with JoomShaper. Thank you for supporting the partners who make SitePoint possible.

Remember the days when you thought that creating a crowdfunding platform like Kickstarter or Indiegogo would cost you a fortune? Wait, you still do? No wonder people call you old school! Let me tell you this: making a crowdfunding website is very easy these days.

You can do it with WordPress — just adding a WordPress crowdfunding plugin would be enough to make a fully-fledged crowdfunding site within an hour. There are a lot of crowdfunding plugins out there, but since you’re a busy person and researching on your own will be very time consuming, I’m going to recommend you my favorite one: WP Crowdfunding, which is by the way the best-selling WordPress plugin in it’s category.

What does the WP Crowdfunding plugin have in it for a fundraising site?

WP Crowdfunding is entirely based on WooCommerce, which allows you to use your familiar WooCommerce interface in the backend. And for your campaign owners, they don’t need to worry about roaming on the dashboard because this WordPress crowdfunding plugin comes with front-end form submission to submit their campaigns/projects and many other frontend operations to run their campaigns/projects properly.

Let’s have a look at the key features of WP Crowdfunding plugin.

  • A theme designed for crowdfunding sites

  • Based on WooCommerce to provide a familiar and solid platform

  • Unlimited rewards for each campaign

  • Stripe Connect payments

  • PayPal adaptive payments to easily split payments

  • Email notifications option

  • More detailed analytical reports

  • Google reCAPTCHA to protect from spam

  • Custom project start date & end date option

  • Minimum, maximum, and recommended price option

  • Campaign end method with different types

  • Display the backer in project single page

  • Template overriding system for developers

  • Multiple methods to end campaigns- monetary goal, date, or unlimited

  • Native wallet payment system

Now let’s dig deeper into some of the core features.

Full control over the platform

As the owner of the platform, you might want to have complete control over the the platform. It will help you protect against misuse and everything will happen right before your eyes. This WordPress crowdfunding plugin lets you have control over sign up, project publishing, withdraw request etc. You can configure the settings from the backend.

I like the project approval settings because it lets you approve all campaigns manually, so you have the complete control of what kind of campaigns you want to run on your fundraising platform. You can also set the limit of minimum and maximum withdraw request from the backend as well.

Dedicated WordPress theme

You can use this WordPress crowdfunding plugin on any WordPress theme, but to enjoy a smoother experience and to have a friendly user interface, the paid version of this plugin provides a special crowdfunding theme inside the package. The plugin integrates with the theme properly so you need not worry about buying other themes.

Template overriding

The WP Crowdfunding plugin supports template overriding, so if you want to change anything, you can customize the style of the page/element very easily. New enhancements will stay the same even after updating the plugin to a new version. If you want to know more on how to change the template style you can checkout this link.

User dashboard to manage profile and campaign details

In order to make your fundraising platform stand out from others, you’ve got to provide your users with a super-friendly front-end environment. This WordPress Crowdfunding plugin offers a few predefined pages that will take care of all of your front end operations. Dashboard, My Account, Campaigns list and Add New Campaign are the key pages of the frontend operation. You can create other important pages using shortcodes. Check out these handy shortcodes from this link.

Let’s have a detailed look at the front end operations.


Summary: One of the things that you definitely want to have on a Dashboard page, it will let you see the overview of all of your campaigns. You can see the summary of the total fund raised, and total number of pledges received. There are few predefined ranges but you can select the date range to get a specific summary.

My Campaigns: All of your campaigns will be listed under My Campaigns. To give you a quick access to all the campaigns, the list is provided on the dashboard page. You can get to the main campaign details page right from here. Let’s have a look at the campaign overview page.

The campaign detail page provides four sections: campaign story, backer list, updates and reviews. All of them are pretty self-explanatory — campaign story shows the details of the campaign, backer list shows the list of backers that have contributed to this campaign so far. If you want to make the backer anonymous you can do that as well.

My Campaigns: All your campaigns will be shown here and you will have the access to modify them. There is an “Update” button using which you can post an announcement regarding any particular campaign. The “Edit” button will allow you to make changes in your campaign.

Add New Campaign

You can create a new campaign from this page. All the options in this page are pretty self explanatory but I’ll highlight the key features. The frontend editor offers the same visual and text editor as found the default one on the WordPress backend.

Project customization

Project customization of this WordPress crowdfunding plugin lets the campaign creator customize their campaign. It offers interesting features like recommended amount and predefined pledge amount. Users can select their project goal and thus the project ending method.

There are actually four project ending methods in this WordPress crowdfunding plugin – Target Goal, Target Date, Target Goal & Date, and Campaign Never Ends.

As mentioned earlier, if the campaign owner does not want to show the backer information on the site, they need to enable “Contributor Anonymity” from the Add New Campaign page.

Continue reading %WP Crowdfunding: The Complete Solution for Fundraising Websites%

Source: Sitepoint

Retrofit Your Website as a Progressive Web App

There’s been a lot of buzz around Progressive Web Apps (PWAs) lately, with many people questioning whether they represent the future of the (mobile) web.

I’m not going to get into the whole native app vs PWA debate, but one thing’s for sure: they go a long way to enhancing mobile and improving its user experience.

With mobile web access destined to surpass that of all other devices combined, can you afford to ignore this trend?

Woman in a 1950s, retro scene looking at a tablet with Progressive Web App icons

The good news is that making a PWA is not hard. In fact, it’s quite possible to take an existing website and convert it into a PWA. And that’s exactly what I’ll be doing in this tutorial. By the time you’re finished, you’ll have a website that behaves like a native web app. It will work offline and have its own home-screen icon.


What Are Progressive Web Apps?

Progressive Web Apps (referred to as PWAs) are an exciting innovation in web technology. PWAs comprise a mixture of technologies to make a web app function like a native mobile app. The benefits for developers and users overcome the constraints imposed by web-only and native-only solutions:

  1. You only need one app developed with open, standard W3C web technologies. There’s no need to develop separate native codebases.
  2. Users can discover and try your app before installation.
  3. There’s no need to use an AppStore, abide with arcane rules or pay fees. Application updates occur automatically without user interaction.
  4. Users are prompted to “install”, which adds an icon to their home screen.
  5. When launched, the PWA displays an attractive splash screen.
  6. The browser chrome options can be modified if necessary to provide a full-screen experience.
  7. Essential files are cached locally so PWAs respond faster than standard web apps. (They can even be faster than native apps.)
  8. Installation is lightweight — perhaps a few hundred KB of cached data.
  9. All data exchanges must occur over a secure HTTPS connection.
  10. PWAs function offline and can synchronize data when the connection returns.

It’s early days, but case studies are positive. Flipkart, India’s largest ecommerce site, experienced a 70% increase in sales conversions and trebled on-site time when they abandoned their native app for a PWA. Alibaba, the world’s largest business trading platform, experienced a similar conversion rate increase of 76%.

Solid PWA technology support is available in Firefox, Chrome and the other Blink-based browsers. Microsoft is working on an Edge implementation. Apple remains silent, although there are promising comments in the WebKit five-year plan. Fortunately, browser support is mostly irrelevant …

Progressive Web Apps are Progressive Enhancements

Your app will still run in browsers that don’t support PWA technology. The user won’t get the benefits of offline functionality, but everything will continue to work as before. Given the cost-to-benefit rewards, there’s little reason not to add PWA technologies to your system.

It’s Not Just Apps

Google has led the PWA movement, so most tutorials describe how to build a Chrome-based, native-looking mobile app from the ground up. However, you don’t need a special single-page app or have to follow material interface design guidelines. Most websites can be PWA-ized within a few hours. That includes your WordPress or static site.

Demonstration Code

Demonstration code is available from GitHub.

It provides a simple, four-page website with a few images, one stylesheet and a single main JavaScript file. The site works in all modern browsers (IE10+). If the browser supports PWA technologies, the user can read previously viewed pages when they’re offline.

To run the code, ensure Node.js is installed, then start the provided web server in your terminal with:

node ./server.js [port]

In the above code, [port] is optional, and defaults to 8888. Open Chrome or another Blink-based browser such as Opera or Vivaldi, then navigate to http://localhost:8888/ (or whichever port you specified). You can also open the Developer Tools (F12 or Cmd/Ctrl + Shift + I) to view various console messages.

Open website in browser

View the home page, and perhaps one other, then go offline by either:

  1. stopping the web server with Cmd/Ctrl + C, or
  2. check the Offline checkbox in the Network or Application – Service Workers tab of the Developer Tools.

Revisit any of the pages you viewed earlier and they’ll still load. Visit a page you’ve not seen to be presented with a “you’re offline” page containing a list of viewable pages:

offline pages

Connect a Device

You can also view the demonstration page on an Android smartphone connected to your PC/Mac via USB. Open the Remote devices panel from More tools in the top-left three-dot menu.

remote devices

Select Settings on the left and click Add Rule to forward port 8888 to localhost:8888. You can now open Chrome on the smartphone and navigate to http://localhost:8888/.

You can use the browser menu to “Add to Home screen”. Make a couple of visits and the browser should prompt you to “install”. Both options create a new icon on your home screen. Browse a few pages, then close Chrome and disconnect your device. You can then launch the PWA Website app. You’ll see a splash screen and be able to view pages you read previously, despite having no connection to the server.

There are three essential steps to transform your website into a Progressive Web App …

Continue reading %Retrofit Your Website as a Progressive Web App%

Source: Sitepoint

Notifications in Laravel

In this article, we’re going to explore the notification system in the Laravel web framework. The notification system in Laravel allows you to send notifications to users over different channels. Today, we’ll discuss how you can send notifications over the mail channel.

Basics of Notifications

During application development, you often need to notify users about different state changes. It could be either sending email notifications when the order status is changed or sending an SMS about their login activity for security purposes. In particular, we’re talking about messages that are short and just provide insight into the state changes.

Laravel already provides a built-in feature that helps us achieve something similar—notifications. In fact, it makes sending notification messages to users a breeze and a fun experience!

The beauty of that approach is that it allows you to choose from different channels notifications will be sent on. Let’s quickly go through the different notification channels supported by Laravel.

  • Mail: The notifications will be sent in the form of email to users.
  • SMS: As the name suggests, users will receive SMS notifications on their phone.
  • Slack: In this case, the notifications will be sent on Slack channels.
  • Database: This option allows you to store notifications in a database should you wish to build a custom UI to display it.

Among different notification channels, we’ll use the mail channel in our example use-case that we’re going to develop over the course of this tutorial.

In fact, it’ll be a pretty simple use-case that allows users of our application to send messages to each user. When users receive a new message in their inbox, we’ll notify them about this event by sending an email to them. Of course, we’ll do that by using the notification feature of Laravel!

Create a Custom Notification Class

As we discussed earlier, we are going to set up an application that allows users of our application to send messages to each other. On the other hand, we’ll notify users when they receive a new message from other users via email.

In this section, we’ll create necessary files that are required in order to implement the use-case that we’re looking for.

To start with, let’s create the Message model that holds messages sent by users to each other.

We also need to add a few fields like to, from and message to the messages table. So let’s change the migration file before running the migrate command.

Now, let’s run the migrate command that creates the messages table in the database.

That should create the messages table in the database.

Also, make sure that you have enabled the default Laravel authentication system in the first place so that features like registration and login work out of the box. If you’re not sure how to do that, the Laravel documentation provides a quick insight into that.

Since each notification in Laravel is represented by a separate class, we need to create a custom notification class that will be used to notify users. Let’s use the following artisan command to create a custom notification class—NewMessage.

That should create the app/Notifications/NewMessage.php class, so let’s replace the contents of that file with the following contents.

As we’re going to use the mail channel to send notifications to users, the via method is configured accordingly. So this is the method that allows you to configure the channel type of a notification.

Next, there’s the toMail method that allows you to configure various email parameters. In fact, the toMail method should return the instance of IlluminateNotificationsMessagesMailMessage, and that class provides useful methods that allow you to configure email parameters.

Among various methods, the line method allows you to add a single line in a message. On the other hand, there’s the action method that allows you to add a call-to-action button in a message.

In this way, you could format a message that will be sent to users. So that’s how you’re supposed to configure the notification class while you’re using the mail channel to send notifications.

At the end, you need to make sure that you implement the necessary methods according to the channel type configured in the via method. For example, if you’re using the database channel that stores notifications in a database, you don’t need to configure the toMail method; instead, you should implement the toArray method, which formats the data that needs to be stored in a database.

How to Send Notifications

In the previous section, we created a notification class that’s ready to send notifications. In this section, we’ll create files that demonstrate how you could actually send notifications using the NewMessage notification class.

Let’s create a controller file at app/Http/Controllers/NotificationController.php with the following contents.

Of course, you need to add an associated route in the routes/web.php file.

There are two ways Laravel allows you to send notifications: by using either the notifiable entity or the Notification facade.

If the entity model class utilizes the IlluminateNotificationsNotifiable trait, then you could call the notify method on that model. The AppUser class implements the Notifiable trait and thus it becomes the notifiable entity. On the other hand, you could also use the IlluminateSupportFacadesNotification Facade to send notifications to users.

Let’s go through the index method of the controller.

In our case, we’re going to notify users when they receive a new message. So we’ve tried to mimic that behavior in the index method in the first place.

Next, we’ve notified the recipient user about a new message using the notify method on the $toUser object, as it’s the notifiable entity.

You may have noticed that we also pass the $fromUser object in the first argument of the __construct method, since we want to include the from username in a message.

On the other hand, if you want to mimic it using the Notification facade, it’s pretty easy to do so using the following snippet.

As you can see, we’ve used the send method of the Notification facade to send a notification to a user.

Go ahead and open the URL http://your-laravel-site-domain/notify/index in your browser. If you’re not logged in yet, you’ll be redirected to the login screen. Once you’re logged in, you should receive a notification email at the email address that’s attached with the user 1.

You may be wondering how the notification system detects the to address when we haven’t configured it anywhere yet. In that case, the notification system tries to find the email property in the notifiable object. And the AppUser object class already has that property as we’re using the default Laravel authentication system.

However, if you would like to override this behavior and you want to use a different property other than email, you just need to define the following method in your notification class.

Now, the notification system should look for the email_address property instead of the email property to fetch the to address.

And that’s how to use the notification system in Laravel. That brings us to the end of this article as well!


What we’ve gone through today is one of the useful, yet least discussed, features in Laravel—notifications. It allows you to send notifications to users over different channels.

After a quick introduction, we implemented a real-world example that demonstrated how to send notifications over the mail channel. In fact, it’s really handy in the case of sending short messages about state changes in your application.

For those of you who are either just getting started with Laravel or looking to expand your knowledge, site, or application with extensions, we have a variety of things you can study in Envato Market.

Should you have any queries or suggestions, don’t hesitate to post them using the feed below!

Source: Nettuts Web Development

Redesigning A Digital Interior Design Shop (A Case Study)

Redesigning A Digital Interior Design Shop (A Case Study)

Redesigning A Digital Interior Design Shop (A Case Study)

Boyan Kostov


Good products are the result of a continual effort in research and design. And, as it usually turns out, our designs don’t solve the problems they were meant to right away. It’s always about constant improvement and iteration.

I have a client called Design Cafe (let’s call it DC). It’s an innovative interior design shop founded by a couple of very talented architects. They produce bespoke designs for the Indian market and sell them online.

DC approached me two years ago to design a few visual mockups for their website. My scope then was limited to visuals, but I didn’t have the proper foundation upon which to base those visuals, and since I didn’t have an ongoing collaboration with the development team, the final website design did not accurately capture the original design intent and did not meet all of the key user needs.

A year and a half passed and DC decided to come back to me. Their website wasn’t providing the anticipated stream of leads. They came back because my process was good, but they wanted to expand the scope to give it space to scale. This time, I was hired to do the research, planning, visual design and prototyping. This would be a makeover of the old design based on user input and data, and prototyping would allow for easy communication with the development team. I assembled a small team of two: me and a fellow designer, Miroslav Kirov, to help run proper research. In less than two weeks, we were ready to start.


Useful tip: I always kick off a project by talking to the stakeholders. For smaller projects with one or two stakeholders, you can blend the kick-off and the interview into one. Just make sure it’s no longer than an hour.

Stakeholder Interviews

Our two stakeholders are both domain experts. They have a brick-and-mortar store in the center of Bangalore that attracts a lot of people. Once in there, people are delighted by the way the designs look and feel. Our clients wanted to have a website that conveys the same feeling online and that would make its visitors want to go to the store.

Their main pain points:

  • The website wasn’t responsive.

  • There wasn’t a clear distinction between new, returning and potential clients.

  • DC’s selling points weren’t clearly communicated.

They had future plans for transforming the website into a hub for interior design ideas. And, last but not least, DC wanted to attract fresh design talent.

Defining the Goals

We shortlisted all of our goals for the project. Our main goal was to explain in a clear and appealing manner what DC does for existing and potential clients in a way that engages them to contact DC and go to the store. Some secondary goals were:

  • lower the drop-off rate,

  • capture some customer data,

  • clarify the brand’s message,

  • make the website responsive,

  • explain budgets better,

  • provide decision-making assistance and become an information influencer.

Key Metrics

Our number-one key metric was to convert users to leads who visit the store, which measures the main goal. We needed to improve that by at least 5% initially — a realistic number we decided on with our stakeholders. In order to do that, we needed to:

  • shorten the conversion time (time needed for a user to get in touch with DC),

  • increase the form application rate,

  • increase the overall satisfaction users get from the website.

We would track these metrics by setting up Google Analytics Events once the website is online and by talking with leads who come into the store through the website.

Useful tip: Don’t focus on too many metrics. A handful of your most important ones are enough. Measuring too many things will dilute the results.


In order for us to gain the best possible insights, our user interviews had to target both previous and potential clients, but we had to go minimal, so we picked two potential and three existing clients. They were mostly from the IT sector — DC’s main target group. Given our pretty tight schedule, we started with desk research while we waited for all five user interviews to be scheduled.

Useful tip: You need to know who you are designing for and what research has been done before. Stakeholders tell you their story, but you need to compare it to data and to users’ opinions, expectations and needs.


We could reference some Google Analytics data from the website:

  • Most users went to the kitchen, then to the bedroom, then to the living room.

  • The high bounce rate of 80%+ was probably due to a misunderstanding of the brand message and unclear flows and calls to action (CTAs).

  • Traffic was mostly mobile.

  • Most users landed on the home page, 70% of them from ads and 16% directly (mostly returning customers), and the rest were equally divided between Facebook and Google Search.

  • 90% of social media traffic came from Facebook. Expanding brand awareness to Instagram and Twitter could be beneficial.


There’s a lot of local competition in the sector. Here were some repeating patterns:

  • video spots and elaborate galleries showing the completed designs with clients discussing their services;

  • attractive design presentations with high-quality photos;

  • targeting of group’s appropriate messages;

  • quizzes for picking styles;

  • big bold typography, less text and more visuals.

Large preview


DC’s customers are mostly aged between 28 and 40, with a secondary set in the higher bracket of 38 and 55 who come for their second home. They are IT or business professionals with a mid to high budget. They value good customer experience but are price-conscious and very practical. Because they are mostly families, very often the wives are the hidden dominant decision-maker.

We talked with five users (three existing and two potential customers) and sent out a survey to 20 more (mixing existing and potential customers; see Design Cafe Questionnaire).

User Interviews

Useful tip: Be sure to schedule all of your interviews ahead of time, and plan for more people than you need. Include extreme users along with the mainstreams. Chances are that if something works for an extreme user, it will work for the rest as well. Extremes will also give you insight about edge cases that mainstreams just don’t care about.

All users were confused about the main goal of the website. Some of their opinions:

  • “It lacks a proper flow.”

  • “I need more clarity in the process, especially in terms of timelines.”

  • “I need more educational information about interior design.”

Everyone was pretty well informed about the competition. They had tried other companies before DC. All found out about DC by either a reference, Google, ads or by physically passing by the store. And, boy, did they love the store! They treated it like an Apple Store for interior design. Turns out that DC really did a great job with that.

Useful tip: Negative feedback helps us find opportunities for improvement. But positive feedback is also pretty useful because it helps you identify which parts of the product are worth retaining and building upon.

Personal touch, customer service, prices and quality of materials were their main motivations for choosing DC. People insisted on being able to see the price of every element on a page at any time (the previous design didn’t have prices on the accessories).

We made an interesting but somehow expected discovery about device usage. Mobile devices were used mostly for consumption and browsing, but when it came to ordering, most people opened their laptops.


The survey results mostly overlapped with the interviews:

  • Users found DC through different channels, but mainly through referrals.

  • They didn’t quite understand the current state of the website. Most of them had searched for or used other services before DC.

  • All of the surveyed users ordered kitchen designs. Almost all had difficulty choosing the right design style.

  • Most users found the process of designing their own interior hard and were interested in features that could make their choice easier.

Useful tip: Writing good survey questions takes time. Work with a researcher to write them, and schedule double the time you think you’ll need.

Large preview


User Journeys Overview

Talking with customers helped us gain useful insight about which scenarios would be most important to them. We made an affinity diagram with everything we collected and started prioritizing and combining items in chunks.

Useful tip: Use a white board to download all of your team’s knowledge, and saturate the board with it. Group everything until you spot patterns. These patterns will help you establish themes and find out the most important pain points.

The result was seven point-of-view problem statements that we decided to design for:

  1. A new customer needs more information about DC because they need proof of credibility.
  2. A returning customer needs quick access to the designs because they don’t want to waste time.
  3. All customers need to be able to browse the designs at any time.
  4. All customers want to browse designs relevant to their tastes, because that will shorten their search time.
  5. Potential leads need a way to get in touch with DC in order to purchase a design.
  6. All customers, once they’ve ordered, need to stay up to date with their order status, because they need to know what they are paying for and when they will be getting it.
  7. All customers want to read case studies about successful projects, because that will reassure them that DC knows its stuff.

Using this list, we came up with design solutions for every journey.

Large preview


The previous home page of Design Cafe was confusing. It needed to present more information about the business. The lack of information caused confusion and people were unsure what DC is about. We divided the home page into several sections and designed it so that every section could satisfy the needs of one of our target groups:

  1. For new visitors (the purple flow), we included a short trip through the main unique selling points (USPs) of the service, the way it works, some success stories and an option to start the style quiz.

  2. For returning visitors (the blue flow), who will most likely skip the home page or use it as a waypoint, the hero section and the navigation pointed a way out to browsing designs.

  3. We left a small part at the end of the page (the orange flow) for potential employees, describing what there is to love about DC and a CTA that goes to the careers page.

Large preview

The whole point of the onboarding process was to capture the customer’s attention so that they could continue forward, either directly to the design catalog or through a feature we called the style quiz.

Browsing designs

We made the style quiz to help users narrow down their results.

DC previously had a feature called a 3D builder that we decided to remove. It allowed you to set your room size and then drag-and-drop furniture, windows and doors into the mix. In theory, this sounds good, but in reality people treated it much like a game and expected it to function like a minified version of The Sims’ Build Mode.

The Sims’ Build Mode, by Electronic Arts. (Large preview)

Everything made with the 3D builder was ending up completely modified by the designers. The tool was giving people a lot of design power and too many choices. On top of that, supporting it was a huge technical endeavor because it was a whole product on its own.

Compared to it, the style quiz was a relatively simple feature:

  1. It starts out by asking about colors, textures and designs you like.

  2. It continues to ask about room type.

  3. Eventually, it displays a curated list of designs based on your answers.

Large preview

The whole quiz wizard extends to only four steps and takes less than a minute to complete. But it makes people invest a tad bit of their time, thus creating engagement. The result: We’re improving conversion time and overall satisfaction.

Alternatively, users can skip the style quiz and go directly to the design catalog, then use the filters to fine-tune the results. The page automatically shows kitchen designs, what most people are looking for. And for the price-conscious, we made a small feature that allows them to input their room’s size, and all prices are recalculated.

Large preview

If people don’t like anything from the catalog, chances are they are not DC’s target customer and there’s not much we can do to keep them on the website. But if they do like a design, they could decide to go forward and get in touch with DC, which brings us to the next step in the process.

Getting in Touch

Contacting DC needed to be as simple as possible. We implemented three ways to do that:

  • through the chat, shown on every page — the quickest way;

  • by opening the contact page and filling out the form or by just calling DC on the phone;

  • by clicking “Book a consultation” in the header, which asks for basic information and requests an appointment (upon submission, the next steps are shown to let users know what exactly is going to happen).

Large preview

The rest of this journey continues offline: Potential customers meet a DC designer and, after some discussions and planning, place an order. DC notifies them of any progress via email and sends them a link to the progress tracker.

Order Status

The progress tracker is in a user menu in the top-right corner of the design. Its goal is to show a timeline of the order. Upon an update, an “unread” notification pops out. Most users, however, will usually find out about order updates through email, so the entry point for the whole flow will be external.

Large preview

Once the interior design order is installed and ready, users will have the completed order on the website for future reference. Their project could be featured on the home page and become part of the case studies.

Case Studies

One of DC’s long-term goals is for its website to become an influencer hub for interior design, filled with case studies, advice and tips. It’s part of a commitment to providing quality content. But DC doesn’t have that content yet. So, we decided to start that section with minimal effort and introduce it as a blog. The client would gradually fill it up with content and detailed process walkthroughs. These would be later expanded and featured on the home page. Case studies are a feature that could significantly increase brand awareness, though they would take time.

Large preview

Preparing for Visual Design

With the critical user journeys all figured out and wireframed, we were ready to delve into visual design.

Data showed that most people open the website on their phones, but interviews proved that most of them were more willing to buy through a computer, rather than a mobile device. Also, desktop and laptop users were more engaged and loyal. So, we decided to design for desktop-first and work down to the smaller (mobile) resolutions from it in code.

Visual Design

We started collecting visual ideas, words and images. Initially, we had a simple word sequence based on our conversations with the client and a mood board with relevant designs and ideas. The main visual features we were after were simplicity, bold typography, nice photos and clean icons.

Useful tip: Don’t follow a certain trend just because everybody else is doing it. Create a thorough mood board of relevant reference designs that approximate the look and feel you’re going after. This look should be in line with your goals and target audience.

Simple, elegant, easy, modern, hip, edgy, brave, quality, understanding, fresh, experience, classy.

Mood board. (Large preview)

Our client had already started working on a photo shoot, and the results were great. Stock photography would have ruined everything personal about this website. The resulting photos blended with the big type pretty well and helped with that simple language we were after.


Initially, we went with a combination of Raleway and Roboto for the typography. Raleway is a great font but a bit overused. The second iteration was Abril Fatface and Raleway for the copy. Abril Fatface resembles the splendor of Didot and made the whole page a lot more heavy and pretentious. It was an interesting direction to explore, but it didn’t resonate with the modern techy feel of DC. The last iteration was Nexa for the titles, which turned out to be the best choice due to its modern and edgy feel, with Lato — both a great fit.

Useful tip: Play around with type variations. List them side by side to see how they compare. Go to Typewolf, MyFonts or a similar website to get inspired. Look for typefaces that make sense for your product. Consider readability and accessibility. Don’t go overboard with your type scale; keep it as minimal as possible. Check out Butterick’s summary of key rules if in doubt.

Large preview


DC already had a color scheme, but they gave us the freedom to experiment. The main colors were tints of cyan, golden and plum (or, rather, a strange kind of bordeaux), but the original hues were too faded and didn’t blend with each other well enough.

Useful tip: If the brand already has colors, test slight variations to see how they fit the overall design. Or remove some of the colors and use only one or two. Try designing your layout in monochrome and then test different color combinations on an already mocked-up design. Check out some other great tips by Wojciech Zieliński in his article “How to Use Colors in UI Design: Practical Tips and Tools”.

Here’s what we decided on in the end:

Large preview

Source: Smashing Magazine