How to choose the right software house

For almost three years we have been working with several software houses, small companies and corporations. We usually work in a team as a service type of collaboration which has a lot of pros and cons – we’re responsible for the product strategy, UX research and the product design, and the software house for the IT section. Of course, we had cooperations where we were extremely happy to be a part of. But what is more important for this simple note, we observe a lot of strange patterns we wanna share with you today. Below you can find a few observations that we find interesting.

Development vs Design

First of all, appropriate design implementation is extremely important for the user experience. If you create a product for people, they do not care about the back end and through which technology it was implemented. I do not mean it is not important but it is rather a strategic decision for the development of this product, not for users. Please ask your non-technical friend about in which technology is implemented Facebook or Instagram or even Youtube. They really do not care. 

Then ask them about the recent update of YouTube and they will probably tell you about recent improvements in tags, in video proportion. Ask about facebook and they will tell you about the latest messenger updates etc. Why am I writing about it? Because especially for MVP people usually try to save money on design and on the UX experience. From the back end to the front end, everything will work perfectly, but users will see just an app doesn’t fit their needs as a result 🙂

So how do you choose a software house that will be able to do both good backend and a great front end as well? 

Ask about the team

Also, ask how long developers have been involved in the process. Have they been working from the very beginning (they should be involved from the very first meeting!)? Asked when designers leave the project: after the last screen or do they finish the job a little later than developers? User experience is connected with implementation and Designers should take care of interactions! They should also do a review of what was implemented.

From our experience, if a software house is small, it doesn’t mean they are worse than others. It is not about the size of a company. It’s about their structure.  For example, it is better if they tell you they don’t have a UX/UI designer than for them to give you someone with no experience. 

Try to understand the way they work. Do they use SCRUM or are their actions are rather spontaneous? If they do, who is the Product owner? Do they have separate Scrum Masters?  Do they use other methodologies? How does it work? What is their flow? How do they collaborate?

Check what you prefer and what fits you best. There are no wrong answers! 

What is important in well-organised companies is that there is no difference if the team works together in one office or fully remotely. For example, Netguru, one of the largest software houses in Poland, operates completely remotely and probably most of their competitors would be impressed by how well they are organized. It is more about their process. How often they have calls together? Who is responsible for project managing? Which methodology they use etc. 

Also, ask how long developers have been involved in the process. Have they been working from the very beginning (they should be involved from the very first meeting!)? Asked when designers leave the project: after the last screen or do they finish the job a little later than developers? User experience is connected with implementation and Designers should take care of interactions! For example, in cooperation with Pragmatic Coders from Krakow after putting the project into implementation, I would sit down with Front-end (greetings to Jack) from time to time and check together what wasn’t working as it should be for the user.

Ask for the Designer’s portfolio

Ask for the designer’s portfolio. You should receive Dribbble or Behance links. A lot of developers work on a ready library, which is okay if you know how to use them. Unfortunately, we usually see that software companies use it in a random way. So,for example, they will use a button which is not dedicated to a certain action and the whole app looks crappy.

Ask also if they have an internal graphic designer or do they cooperate with external designers? In such cases, ask who will cooperate with you and who will be responsible for your project. The company will probably present you the most beautiful project made by someone who is no longer available for additional projects, or they will give you a Junior Designer. The result can be completely different and you will be disappointed with the final result.

Tools they use

There is no rule, but it is nice to know if developers and designers use the latest technology. For now, people who use Mac will probably use Sketch + Zepplin + Invision. This is a common combination for high-level projects. The flow of these 3 tools is really impressive. At the same time, you can design, prototype and send something to the front end with a ready code. It boosts the whole cooperation a lot so as a result, you will get a more accurate project delivered faster than you expect 🙂

On Windows people usually use Figma, which is ok, but most of the top-level designers would recommend sketch (but keep in mind Figma is peaking right now, its popularity increases every day and after a few attempts I also liked it).  We had occasions to do a few projects in Adobe XD but usually, it is used by companies who heard something about new solutions and they installed it because they used to use photoshop and they download it from the cloud for free.

In my opinion: Avoid designers who work in Photoshop. 2,5 years ago we also worked in Photoshop; but for now, it is hard to imagine how to create a complicated system in old and heavy photoshop. It is simply a waste of resources for all stakeholders. I mean at the end of a day there is no difference for you which tools are used; but if the designer uses those I’ve mentioned above, you will really save your money and time. 

Compare design with the final result

Software houses usually present their best work and they will not tell you about what went wrong. Sometimes the implementation looks great but it doesn’t mean that the software house did the whole job. Ask about wireframes, the design on which they based. Compare it with the final result. Check the space between sections, check titles sizes etc. The easiest way is to do a screenshot and place it next to the design

How much do the screens differ? If you see a significant difference then you should start asking the question: why it doesn’t look like the design? Usually, they will say there was no budget :). It is a common excuse, but in my opinion, good developers have very good accuracy in implementation and they do not need additional time for it. 

Why should you spend time on this? Usually, it will take a bit longer than usual, but you will save money from an unhappy cooperation. We often force with the project who was promised all pies in the sky but the final result wasn’t so good.

Details are important

Ok, the first impression is done. But what about the details? Does the design have hovers? Animations? What about loading speed? Do they have a style guide? How do they implement interactions? 

For example, in our projects, we prepare a small style guide with all interactions. it helps a lot to avoid “static design”. Keep in mind your user will leave the site if they find it is static or it looks like a heavy one. All small details like interactions after a click, state make the whole page come alive. 

Just take a look at how a simple page with explained states can look. It is a simple version of a style guide but it doesn’t take long for a designer to prepare, but it boosts a lot for developers. 

Implementation of RWD 

This is a common problem. Each software house has different practices and moreover, each developer inside a single software house has a different pattern for it. The best software house does not need designs for all screens and resolutions. They should organise their code in a way that RWD (Responsive Web Design) should take a few additional days. Communication with designers is also important here. 

For example, our practice is to use our own grid and the golden ratio system and we communicate it from the very beginning. We usually choose 16 px as basic font size and all font sizes are just size from proportion. For example, 16 px is 1 em. multiply should equal 1.618  to 2 em is 26px, 3 em is 42px and 4 em is 68px. When we want to do mobile we just change the multiple to 1.5, and it is only one line in CSS and as a result, we have mobile sizes on all screens :). And this just takes a second. This is our own system of how we collaborate with developers. For you, as an owner, it isn’t so important, but you should check if they have any knowledge about such collaboration.

Good developers should also organise space in a similar way so together with designers they should set 2-4 spaces for each case and for the smaller resolution they would change only a few values. We can do it on slack or on call and once again it should not take long. 

What to avoid? If developers need all RWD designs. There are two options: people don’t know what they are doing or they want to charge you additional costs. Of course, it might happen that the designer designed something specific and they need a separate view for the mobile version; but I really do not remember a project where we designed all screens for all resolutions. Once again good communication with developers and setting rules before entering a cooperation should solve most misunderstandings. 

It is also a good solution to save some time for a designer to verify development and RWD.

Conclusion

I understand that most of the projects have a limited budget. I understand that the cost of developments is enormous. Sometimes you should not save money by using people who do not know what they are doing. Maybe they really specialist in one area, but if they do not know what to do in another, do not risk your time and money on cooperation. 

And if you have something to consult about your new project just, let us know and we can take care of the UX and UI processes 🙂

Sounds interesting?

Would you like to organise such a workshop or your company or just to talk about your process?

Let's talk
Tomasz Osowski
Jestem odpowiedzialny za wdrożenie i koordynację projektu od początku aż do wypuszczenia na rynek. O sobie mówię: “Nie mam marzeń, mam cele”. Problemy zamieniam na wyzwania, a wyzwania po prostu realizuje. Jestem wychowany w “Better done than perfect”. Za priorytet stawiam delivery i wysokiej jakości usługę. Jestem bardzo mocno zajawiony w nowych technologiach. VUI, AI Smart home, fintech o których mogę czytać godzinami.

Find Us

Would you like to get to know us better? Check out our Social Media platforms to stay in touch.

Newsletter

Our own canvases, tools, articles and the latest information about our workshops - that's what you get in our monthly newsletter.