Enveloop Studio logo

We are Enveloop Studio, we prototype UX.

Hi, I’m Adam

I’ll be your guide and will do my best to make your time here worthwhile.

I need ~4 minutes of your time.

I would offer you a cup of coffee or tea, but under these circumstances, you know…

Just relax and swipe away!

What we do

We design User Experience of digital products.

Our projects are WCAG–compliant and on par with each platform’s navigational guidelines.

Our design is not flashy. We don't do it so it looks nice on Dribbble. It has to work and solve the problems you pay us to solve. It has to work for years.

We treat brand visual identity seriously. We don't just take 2 main colors and go nuts with everything else.

We’ll focus on a different aspect of our work—the deliverables. Think style guides, UI pattern libraries, and prototypes. If you’re familiar with Atomic Design, that’s what we do + prototyping on top of that.

Let me explain what that’s about.

Why Design Systems

When the job is to design 600 pixel–perfect screens, simple screen–by–screen workflow won’t cut it.

In projects like this, there are dozens of developers and other designers involved. The job, then, is to design components that will be reused. Those components have different states. Think empty state, 1 item, a few items, too many items, error, warning.

With this approach, a design system becomes a living documentation.

Why we prototype

To be sure that our (by our I mean “your and our”) vision of the product will work, we create prototypes.

We build them with components from the design system. We test them with people. We consider the feedback we receive, make changes and test again.

It’s much more than a few static screens connected in InVision, Marvel or Axure. Those are working apps and websites. They are mocked with real data and ready for real–world scenarios.

Managing change

Managing change is the biggest problem in big design projects.

It may not be obvious at first but just think about it:

Imagine you’re managing a project with 600+ hi–fi screens and you have a new idea, a great one. But to implement it, 120 of those screens need to be changed, manually! Someone has to open those files, make the changes, update InVision, Marvel, Axure etc.

“Who pays for that?”, “How does it affect the timeline?”, “Will it work in all contexts?”

What usually happens?

That’s right, you guessed it: Nothing! Everyone knows how painful it’d be, so usually nobody even tries. Sometimes, a few key screens get changed, which just creates a giant mess for everyone.

We hate that. We’re crazy about efficiency and that’s why we would fear to make changes like that.

We have all the great tools that software development offers. We use version control. We separate data from layout and reuse layouts. We can use responsive styling libraries for web and mobile.

All that gives us confidence that changes can be made quickly, can be tested easily and won’t break anything.

Product development perspective

Most tools for UX “prototyping” available now are just static images moving on the screen.

The results accurately represent neither the end experience, nor the platform of the product (be it web or mobile).

How do you show animations and inertia? Tools like Framer or Origami work well for prototyping isolated interactions, transitions. But they don’t solve the problem of showing them on 600 screens with variations.

Working with developers

We have the pleasure of working with outstanding developers. We highly respect their work. Naturally, they are not UX designers, they are developers. Usually, the project files they get from designers lack around half of the context needed.

Then, usually one of the 2 following scenarios happen:

  1. They ask about every little thing: spacing, animations timing, interaction states, etc. That’s better for quality but very time–consuming. Another side–effect is that most of those answers aren’t well–thought out. They are rather improvised.

  2. They do things the way they think is OK. This is obviously worse—unless you’re working with some UX–gifted developers. Usually the result is not what we aim for, to put it nicely.

Technology we’re using for prototyping

We build tools on top of technologies like React, Polymer, Tachyons, Firebase, and GraphQL. We have years of experience solving these kinds of problems so we know how to use these technologies efficiently. What we deliver works on the native platform of the (soon–to–be) product—mobile, tablet, web, etc.

Developers can use their tools to check every implementation detail, such as spacing, colors, dimensions, and animation timing. We also ship a Storybook that showcases all components in all states.

Testable, real data

We use real data, scraped from real sources if possible. We do so in order to see edge cases for real–world scenarios. We can swap around or use different sets of data for tests with real users in believable conditions. Something that relates to them directly.

Here’s a story: One of our projects was location–based. When we knew exactly where we would test it with people, we put stuff on the map nearby the test location. People were sure it was real data in the live app.

This leaves no room for misunderstandings or cognitive fatigue. Try testing a map app (zooming, panning, selecting) on linked static screens.

How we work

In brief

We believe life is too short to waste it on doing dumb things. That’s why we use Scrum to run our projects.

If we (and by we I mean “you and us”) are wrong about any assumptions, we want to know ASAP and react accordingly.

First, we deliver a Minimal Viable Product—we pick crucial functions and develop them first. Then, we test them. When we know what works and what doesn’t, we move forward with the next features.

In more details

You don’t know everything from day one. You assume plenty and just think you know. It’s not just you—it’s us all, all humans.

That bold plan, those beautifully aligned Gantt charts, they quickly become irrelevant when you put them up against what you learn during the process of creation.

Sticking to them isn’t very smart. That’s why we don’t want to be forced to do so. We don’t want our clients to be, either. That’s what fixed–priced contracts enforce and it’s not good for anyone involved.

In the world of digital products, swift and agile is way better than slow and “waterfall”.

In very down–to–earth terms

  • We work on understanding the idea and business model
  • We work internally for a while (about 3–5 days)
  • We come back with a tangible concept for a workshop together
  • When we’re on the same page, we work on the visual design
  • When we agree, we build a prototype
  • We iterate the visual design and overall UX on the prototype in one–week sprints
  • When the concept feels right, we start to include users in iterations (~2–3 weeks from the start)
  • First version (or MVP) is ready for development and to receive feedback from real users
  • We start iterating on the next features and the process continues
Who we work with


NGO.pl is the biggest non–governmental portal on the Polish internet. It’s 16 years old (think about what you were doing in 2001). More than 1 million people visit every year. It serves the NGO community in Poland extremely well.

We’re responsible for the whole redesign. We work together to introduce smart and viable monetization options.

We deliver fully working prototypes with scraped real data. They have a new information architecture, new navigation, a new visual design. They are fully responsive. On top of that, there is a full design system.

This project is ongoing and is estimated to be finished in the middle of 2018.

Orange Poland

Orange has a total of ~16 million customers in Poland. They’re the biggest mobile and landline operator here.

They’re the client we’ve done our biggest projects with. We’ve work with them on:

Self–care systems

Web, mobile, and tablet applications (Mój Orange). Full technical and UX analysis. We created a new information architecture, new navigation, and a new graphical design. RWD prototype. We helped to redesign the whole process from the ground up. It was a huge project. Overall, it was more than a year of work, and we created more than 600 hi–fi screens for this project alone.

Login and registration cycle

Web, mobile, and omnichannel process redesign. Big in terms of service design. Think about the security implications and legacy considerations in a company like this. We held more than 30 workshops with different departments. We delivered an RWD prototype with documentation.

Online knowledge base

The challenge was to create a more efficient KB and combine both client–facing and internal legacy knowledge bases. We actually analyzed (read!) Orange’s existing knowledge bases to create an information architecture map and content inventory. From that, we came up with a more natural and understandable information architecture. Based on that we delivered a working RWD prototype. We also designed a sophisticated search system.

Web sales process audit and recommendations

Selling contracts with mobile handsets isn’t easy. We audited the existing path, recommended changes and created flows for discovery and conversion paths. We delivered a report with our recommendations. Based on that, we developed a small prototype showing information architecture, micro–interactions, and transitions.

There were a few more I won’t cover in details: for example, we worked with their CSR on a system for utilizing old phones.

mBank Corporate Banking

mBank’s tagline is “Mobility Icon.” They’re considered #1 in mobile and online services among Polish banks. You should know, by the way, that banking systems and services in Poland are considered some of the most modern and sophisticated in the world.

We started with a UX audit for their new mobile and tablet applications. Then they asked us to help with the design for those. We delivered designs for mobile and tablet applications. We also helped with quality assurance during the project.

It was an interesting project with tight time constraints. It all happened within 3 months. Keep in mind that a corporate banking app is much more complex than B2C, with lots of extra features.

RR Donnelley Poland

RR Donnelley Poland is now Premedia Solutions

RRD is a Fortune 500 company founded 150 years ago in Chicago.

All projects done with this client are under a really strict NDA. We help this giant with digital product development for their giant clients.


Sorin and Cyberonics merger

LivaNova is a global medical device manufacturer. They develop devices used for cardiac surgery, neuromodulation and cardiac rhythm management.

We made a sales force iPad app together. By that I mean content, navigation, information architecture, and visual design.

We started this project by receiving training about heart diseases and how pacemakers work—all that so we could come up with something smart and specific. We think we did.

innogy Innovation Hub

Formerly RWE

innogy Innovation Hub is an acceleration program for startups. It was founded by innogy (previously known as RWE, the energy giant).

We had 6 weeks to create and test an assumption about a new technology, one that would help you find parking spaces in crowded cities.

We worked together on the functional scope of the app, created a prototype and tested it with people.

The prototype was buit in a way that testers were convinced that they were seeing real data. The project took only 4 weeks of the 6–week limit.

Date for Date

This was fun! We created a new mobile dating service for the Swedish market. From scratch. The only thing given was the name.

Together with Product Owner Glen, we figured out a new approach to dating, one that wouldn’t treat women as “objects,” that wouldn’t have that “meat market” vibe to it.

We conceived, designed and actually coded the app from scratch in less than 3 months. One of the most interesting projects of our lives.


Pracuj.pl is the biggest job posting site in Poland and this part of Europe. Think Polish monster.com.

We designed and coded mobile and tablet applications (iOS and Android).

The rating in stores went from ~3 to ~4.8 stars.

The funny thing was, our design was all flat, iOS 6 had just hit the shelves, and iOS was still skeuomorphic (think wood and leather).


Think of Gastronauci as the Polish yelp. The service was highly respected and widely used.

We designed and coded iOS and Android apps (before that, they’d only had web).

It was a big success. Gastronauci was acquired by Zomato.

We’ve done many more projects.

From prototyping an app for citizens to inform authorities what to fix in the city. It was done during a 48h hackathon in Stockholm.

To helping a startup from Silicon Valley to improve UX in their multi–platform, in–game leaderboard.

Bragging is tiring, let’s talk about…

We’ve done many more projects

From prototyping an app for citizens to inform authorities about what to fix in the city, which we developed during a 48–hour hackathon in Stockholm, to helping a startup from Silicon Valley improve the UX in their multi–platform, in–game leaderboard.

Bragging is tiring. Let’s talk about…

The Money

So, how much for the pleasure?

All this for only 59.99 EUR/hour!

Not the most formal company website you’ve seen in your life, right?

Seriously, we work for 60 EUR/hour. That’s for an actual hour of work. No lunch, no coffee breaks, no man–days—just work.

But we need an estimate”

Estimates are hard for software projects (not only here).

I’ll try to break it down into something tangible.

We usually need about 4 weeks to deliver the first MVP—analyzed, designed, and prototyped.

From that point, the development can start and we can work on the next iteration.

Those 4 weeks translate to around 9,000–11,000 EUR (2 people working about 5 hours a day). We can make it a fixed price, but it’ll take time to set the scope and the agreement and we’ll have to really sit down on the estimate. We all have to understand that it’s the cost of the scope written in the agreement. If any part of that scope turns out to not make sense, we’ll have to alter the agreement.

We’ll also have to add some margin in case we underestimate the project. It’s always better for everyone to go with Time & Materials.

That’s all, thanks

Think about it for a second.

You just read a business proposal that talks about lots of technical aspects of how projects are done. You must have expected it to be very formal and boring. I would have.

If I did a good job, you should “have a feeling” about us (or me) at this point.

You may think it’s unconventional, but I hope I’ve made you feel like you can trust us in the experience and engagement field.

Of course, I’m not sure if you actually read it all. I hope you did because it describes everything you need to know about who we are and how we do things. Or so I hope.