I'm Marcin, CEO of UXPin: design, prototype, collaborate all in one place. Ask me anything!

@de Thank you for being a loyal user Dan! I really appreciate it! You're right. There's so many new design tools these days! Generally speaking, this is great for us. More competition forces us to be always on our toes, devoted even more to the quality of our product and focus on providing overwhelming value. There are however, some challenges: 1. "New Tool Fatigue" – with so many new tools, plenty of organizations just don't want to go through another change. To overcome that we have to be 10x better than any competitor. I think we are, but it has to be obvious in the eyes of the customer. 2. Over-reliance on trends in the community – designers, more than any other group of professionals that I know of, rely on trends. A tool that is trendy in a given year takes the market by the storm, only to start losing the grasp the next year. We have to create loyalty by being close to our customers and deliver outstanding quality. 3. Difficult fights for attention with companies that have access to enormous capital. This one is the most difficult. We're a profitable company with 50 awesome teammates. But we have to fight with companies that either raised hundreds of millions of dollars or are publicly traded giants with nearly infinite financial resources. The only way to win this battle is by being true to who we are and focusing on our strengths! Thank you!

@marcintreder I love this! Thank you for the answer, I've been through "New Tool Fatigue" a few times, so I always tend to go with the tool that allows me to do my job the most effective way, while providing a great user experience. The fact that you've focussed in on quality and loyalty shows in your product, rather than simply chasing trends. Keep up the great work!

@rishijash I appreciate you digging into my background! I found psychology to be very helpful in my career. It doesn't mean though that you have to follow my steps and spend five years at the University :). After high school, I spent three years studying philosophy (B.S). I started to be very interested in mathematical logic (super helpful in coding), philosophy of mind, and cognitive science. The last two were critical to my career as a UX designer. My curiosity about the human mind (especially cognition and perception) led me to my first gigs as a UX Designer. I've decided to take a deeper dive and study psychology (5 years, full M.A. course). Money was tight, so I had to study psychology on the weekends and work as a full–time UX designer during the week. What in particular was helpful? - Learning about the scientific research and statistics helped me with quantitative research and data analysis. Both were critical in my career. - Taking a deep dive into cognitive psychology was a fantastic way to deepen my understanding of how people may experience products that I create. - Learning about psychological therapy, psychology in management, and business helped me be a more self-aware manager. All of the above was critical to my career, but I'm sure there are other paths. Perhaps less time-consuming.

@abadesi thank you for a fantastic question and an opportunity to travel back in time! UXPin had two, very different, "early days" phases. The company was started as a side project back in November 2010 (back then I headed design at an eCommerce startup). Long story short, we've created a paper prototyping notepad to solve the problem of a lack of collaboration between designers and engineers. About one year later, in December 2011, we've launched the first version of UXPin the app. Shortly after, we've raised the first round of funding, which started the pro days of UXPin as a company. 1. "User Acquisition" tactics in the notepad days (11/2010 – 12/2011). This part of the UXPin story is likely the most surprising and the least professional. We didn't do much to promote UXPin. UXPin notepad very quickly gained popularity, and we can't claim that we had anything to do with it, apart from building the right product for our market. We launched UXPin on November 11th, 2010, with low expectations, but lots of pride in building something "cool" for the community. We didn't know that we're starting a real company. All three founders had good full–time jobs and a couple of failed startups under our belts. UXPin was supposed to be a fun project focused on the problem that we felt personally. How different things turned out to be! We've announced UXPin on Twitter with a simple tweet. Forty–eight hours later 400 notepads from our initial production order were gone, and we had a massive backorder. Later on, I showed UXPin on a couple of meetups and conferences, and I wrote one or two blog posts to major UX publications. That's it. We didn't do ads, e-mail marketing, or any other forms of promotion. Organic growth was enough to sell more than we were able to produce without lowering quality. Fun fact, I remember that one of our top traffic sources was... Delicious. Does anybody remember Delicious? 2. "User Acquisition" tactics in the early days of UXPin the app. We launched the app in December 2011. The initial version of UXPin was quite different than UXPin we have today. The primary use case for the app that we've envisioned as not only critical to the design industry but also extremely cool, was an automatic translation of paper prototypes into HTML prototypes. Yes! You could have taken a photo of your paper prototype created in the UXPin notepad, send it to the app, and our system would automatically build a digital prototype. Awesome, right? Well, we didn't get much traction here. Right from the get-go, we've learned that the foundation of a solid business is a great product that answers real problems. Products solely based on technological capabilities and vision are doomed to fail. After this initial failure, I've started calling all of the early UXPin customers. We had fantastic conversations about the real problems that they were experiencing every day. Those conversations informed our roadmap decisions for months to come. In the meantime, the money became tight. Our initial VC investment was paid in tranches (the European VC market was brutal). Every quarter we had problems with meeting our financial objectives. Every quarter felt like we could go out of business. It felt desperate. And this desperation informed our user acquisition tactics. I didn't know how to do all the smart marketing things like paid acquisition, or SEO, but I figured that I could write about design. We've started to rely on content marketing. Our tactics included: - Regular blogposts in key traffic sources (publishers). Instead of publishing one piece of content in a given place, I always offered publishers a series of posts with one theme. I figured that it would create a more lasting impression and help people remember UXPin. - A series of blogposts were turned into email gated ebooks. I remember that the first eBook deal that we had was spectacular. I wrote a series of articles for .Net Magazine and those articles were republished as an ebook co–created by UXPin, and .Net. The ebook was hosted on our servers. We didn't know what to expect and we didn't assign sufficient resources to the eBook landing page. Once tens of thousands of people started to download the eBook, our servers died. - E-mail marketing. Around that time, we started to engage email marketing to promote UXPin to folks who downloaded our eBooks. The results were spectacular! - Actionable content. We started to produce UI Kits for UXPin and other platforms. Here's a thing though, the most important lessons that we've learned in those early days is that growth marketing is all about the discipline. If your weekly goal is to get 100 new customers and in order to get there you have to get 10000 trial sign-ups, you have to figure our a sufficient number of tactics that has 50% higher projected returns that your goal. Then measure things daily and if you're missing – add more tactics. This approach brought us spectacular results in the early days. Later on, I've learned that a lot of marketers hate it and prefer to rely on long term plans. I've never seen those working as well as our scrappy methods of the early days.

@marcintreder This is amazing! I would love to learn a little more about how Delicious came into play, how many followers did you have when you tweeted your initial release, and what markets/forums/groups did you tap into to create brand awareness? Let me know!

@marcintreder Thanks for the reminder that discipline is key! These tactics are super helpful.

@marcintreder definitely! thanks

@raquel_winiarsky I wish I could provide some numbers, but it was 9 years ago and no details survived the passing time :(. I do remember that our UXPin twitter account had very few followers. Probably less than 100. Delicious was purely "earned". People just started to save the link to UXPin on their accounts. I guess for a design tool we went semi-viral :) We've posted links to UXPin on bunch of UX groups on Facebook and Linkedin. I don't remember the details :(. I wish I could be more helpful!

@marcintreder I am goona frame this: "A product that offers great user experience will beat a product that has more features." 🙈 Thank you for this GOLD!

@marcintreder Marcin - on behalf of the Product Hunt community we thank you for taking time out of your busy schedule to share some incredible learnings with us. So excited for the future launch! Makers, this discussion is now closed but you know where to find Marcin in future 😊

@nvdb31 regarding your concern about the ability to export to code, you can find it in a low-code platform UI Bakery - a prototyping tool that generates Angular code.

@nvdb31 Awesome question. Thank you! Before, we'll jump into a time machine and travel to the future, let me tell you why UXPin doesn't export code. Technically, we could do it! UXPin operates directly in the browser rendering engine, and everything that is created in UXPin is rendered as html/css/js. So why aren't we allowing to export it to production code? UXPin is typically used by mid-size and large organizations as the primary tool to drive the design process. In those organizations designers usually work on existing products – building new features and improving old ones. Code export would have to fit in into this existing environment and comply with existing coding standards. That means that UXPin would have to first understand the existing code and then generate appropriate code for the provided environment. This is not an impossible task, but it would be very difficult to commit to it AND at the same time, build the best prototyping tool in the world. We're a profitable company with 50 awesome people on board. In such a small company we have to be very selective in our investments. Down the road, I could imagine UXPin working with smart folks from companies operating closer to the no–code movement, like the excellent team at Webflow (👋 @callmevlad). Now – the future. I think the market will change significantly in the next couple of years. I believe that a significant part of the market will be served by no–code solutions. A lot of websites and apps are going to be built by people who are not "programmers" in the classic sense of the word. Imagine the impact on the macroeconomy and, more importantly, on the lives of people who are entrepreneurial, but are unable (or don't want to) express themselves in code. This is going to be a massive change. Going back to your original question – in this no-code (post-code? 🧐) world, there's no hand-off. Design and development are going to become one. The rest of the market will remain in the classic "code" world. It doesn't mean however, that this part of the design–engineering universe, won't see any changes. I believe that design tools will get significantly closer to code, allowing designers to design, and prototype incredibly realistic experiences. Those prototypes are going to be automatically ready for 'development' and are going to include: - accessible markup and visual accessibility checks - real markup and styles for layouts - interactive, stateful, components - real data structures If you follow what we do at UXPin, you probably know that in the last couple of months, we've introduced accessibility tests, interactive, stateful components and connectivity to data. The process where designers design use vector graphics and developers translate them to code will disappear. Instead, designers will use tools that can render design decisions directly in code. That will also open the opportunity to import production code to the design tool. With the import of code designers will be able to build new experiences with production code, without knowing how to code. We're actually already allowing some of our customers experiment with that thanks to our new technology – UXPin Merge (https://www.uxpin.com/merge). OK, I could talk about it forever. Let's stop here. Hope this is helpful!

@callmevlad @marcintreder Cool. I've been working on a design-to-code tool myself, it's called Handoff (www.handoff.design). I'm also using the box model for rendering, but also with React/Vue export capabilities. I was just wondering why UXPin doesn't do code export, but I totally get it now. The direction I'm taking is quite different from UXPin, but nevertheless your insights and stories have been quite inspirational for me, on this crazy and incredibly hard journey towards a working product and happy users. Thank you for that! 👋🏼👍🏼

@elrumo1 Thanks for the question! 🙌 You're absolutely right. There are more and more tools on the market, and some of them are growing into huge companies! And to think that back in 2013 when we were raising the first round of capital in Silicon Valley, most of the VCs questioned the market size for design tools 🤐. I don't think anybody could question the market size today. It is truly enormous, and I'm sure, it will suffice for multiple companies to become huge and, some will likely IPO. Now how UXPin is staying relevant? 1. UXPin is fundamentally different than any other tool on the market. We're on the mission to merge design and engineering and in order to achieve that we've built our tool in a different paradigm than most of the design tools out there. Unlike Sketch, XD, Figma, or InVision Studio, UXPin is not relying on vector graphics to render designers' intent. Instead, we're using the browser rendering engine, and we're rendering designs as html/css/js. Here's why this is important: - The render of your design will look the same in the design tool, and, after development, on production servers. We're using the same rendering engine. - You can create highly realistic prototypes that are impossible to create in other tools. You can use real HTML inputs, create stateful components, apply conditional logic, use variable... lots of awesome stuff. 2. UXPin prioritizes quality. UXPin has been created by designers to solve the key problems troubling our industry. With that in mind, we're focusing on all the details of the experience of our users. Instead of entering the arms race with big companies, we're focusing on building the right thing at the right level of quality. Ah and we're proudly profitable with over 50 teammates on board! 3. We're always researching critical problems in our industry, and we don't hesitate to invest in innovation. One of the results of this strategy is UXPin Merge – a technology that can sync the production code repository with UXPin. With UXPin Merge all the code components in an organization are accessible to designers. Even if designers had no idea how to code! UXPin Merge is in a limited access phase right now. To sum up, we're staying relevant by operating within the right paradigm for prototyping tools that our vector competitors can't beat, focusing on the quality of our solution and bringing to the market the relevant innovation. Thanks!

@new_user_238ffefa58 Hey! I'm sorry to hear that you didn't have a perfect experience. Good news – we've built a completely new Sketch upload earlier on this year. Now you can simply drag&drop Sketch file to UXPin and it becomes 100% editable. No plugins are necessary. Details: https://www.uxpin.com/docs/getti... Hope this is helpful!

@ty_fairclough first of all – thank you for being our loyal user 🥰. There was probably not a single day in the last 9 years when I didn't ask myself what is slowing down UXPin. The answer that always comes up to my mind, and is likely the closest to the truth, is the following – "it's the fault of this idiot the CEO". I've made a lot of bad decisions. Business and product strategy, hiring, firing, raising capital, forming partnerships... you name it, I likely screwed it up. Over a decade ago, my design career started to accelerate quickly. At 22, I started to manage design organization for a company getting ready to IPO (I still wonder how and why?), at 24 I co-founded UXPin. I had to learn everything on the go. And things were changing quickly. Before I knew it, we had capital, dozens of employees, and I relocated from Poland to the US. And let me tell you – I was not ready for it. I feel comfortable working on the product, and design, leading design, and product teams. All of the sudden my charter of responsibilities had sales, marketing, investors, hr and processes all over it. I lost my way more times that I can count. But here's the good news. UXPin is learning, and I'm doing my best to learn as well. Every day we're getting stronger. As an organization, we're trying to eradicate ego and defensiveness and instead, see the world with open eyes and minds. We're currently undergoing a massive product change. Instead of focusing on features, we're polishing all sorts of details of the experience and performance. We're all extremely excited, and we think this is going to be substantial in gaining a larger market share. Something that we still have to get better at is sales and marketing. It's not in our DNA. After multiple attempts, I've learned that I have to focus on my strengths (design and product leadership) and let others grow the business. We're profitable, we're over 50 people strong, and we're learning how to be better every day. We'll likely fail many times, but as long as we'll keep our minds open and we'll continue to learn, I'm sure we will reach the market share that we deserve.

@tim_reznich great question! First of all, the team at Framer X does a fantastic job, and their solution is definitely worth giving a try! There are some similarities between UXPin and Framer X, but both tools differ dramatically when it comes to the overall workflow. Both UXPin and Framer X are "code–based," which means that all the design elements are rendered as html/css/js. UXPin and Framer are significantly different though when it comes to the execution. If you want to prototype rich experiences with Framer X, you have to code them manually with React.js. With UXPin, you can build them without any manual coding. UXPin offers convenient UI for things like: – advanced interactions triggered by any user actions or state changes – conditional interactions – stateful components – connection to data – sending API requests If coding is not part of your prototyping workflow, UXPin is the tool to use!