We are Enveloop Studio, we prototype UX.

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!

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.

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.

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 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?”

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.

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.

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.

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.

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.

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.

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”.

• 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

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…

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.

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.

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.