Flemming Rasmussen, Head of User Experience & Design - Planday

Thank you all. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. a completely redesign and rebuild of our main product. And in just six months, we need to ship this product by January the 1st of 2016. And I won't be showing you the result of this, given that we're right in the middle. This started three months ago, so we're right in the middle of this process, but I will guide you through the process and how we go about this. A little bit about Plan Day. We aim to be the leading workforce collaboration solution there is out there globally. That's what we work to become. And we manage employees' schedules, HR, and payroll for shift-based businesses. And still, the majority of these types of businesses, small to medium-sized businesses, they still handle their employee schedules either by paper or doing it manually with physical boards, pen and paper, or using spreadsheets. And they completely miss out on all of these advantages in communication and in collaboration that we have today using modern technology. So who are we? Well, just over a year ago when I started at Plan Day, we were about a little over 30 people. Today, we are 70 plus people with headquarters in Copenhagen. We got offices in Oslo, Aalborg, Hanoi, London, and we really, recently, a month ago opened up a new office in New York City. And where do we come from? Well, I want to be totally honest today and share some of the flaws that we have in our product, in our product today, but because we have flaws, of course, and how we, at the moment, are in the process of actually changing these at Plan Day. Plan Day was founded in 2010. Since 2004, we still call us a startup, I know, but we really aren't, but we are redefining ourselves, so we are actually working on as a startup with some quick products that need to get to the market. Since 2004, we've had a healthy and organic growth for those 11 years, primarily with customers in Denmark and in Scandinavian countries. In 2014, last year, we got an investment from Creandum, which is now being used for this global expansion to new markets and to become what we want to be the best there is in the industry. But we have a problem. Over the 10 years of building the current product that we have out there, the roadmap for our product has been so much influenced. By customer feature requests and Scandinavian labor and union rules, which are more strict than you see in most or a lot of other countries, at least. And this product then becomes way too complex for new markets and the new customers that we want to target today. And we know that new customers, they need less features and not more features. And a feature-heavy product that we have out there today can be very... very hard for new customers to onboard when we try to explain the concepts and the complexity there is of a product like ours. So... That's why at Plan-A, we focus a lot on... Sorry, it skipped a little bit there. On onboarding. And what happens right after an online sign-up via our website for a product, we have a trial like ours that could make or break any web product. And you could have, like we do today, a long and detached process, multiple steps when talking onboarding. Or we can have an integrated and in-line, in-context onboarding process. And which one is the best? Today, at Plan-A and in our product, we explain the concepts of our product way before discovery. And way before you're inside the actual product. Concepts like departments, employee groups and positions are some of the terms that we explain in several onboarding steps prior to getting into the actual product. And in some cases, this might be a good way or the right way, but I don't think in our case that it actually is. Since we track a lot of users that either get stuck during this process or they simply drop off. And that's what I call onboarding overload. So, even those users that we see getting through that process, initial process of onboarding, well, they still are met with even more tour guides and help content when they are inside the actual system, before they start working with it and start setting up schedules for their employees. There's nothing wrong with that. That's fine, but it just shows how complex our product actually is to the users. And that's why that we, when we design products, we think product and we don't think features. Product is the most important thing. Always have that in mind first, instead of focusing on the individual features and what that will do for the users and the customers. And this will enable our design team and designers in general to build the right features that fits the overall product. Always think, does this serve a real user problem? Does it add value to the customer? I know these are general terms, you all know all about it. And does it fit into the overall product goal? So, that brings us to today. You can actually see the contrast is okay on these, right? So, that brings us to what we're actually working on today at Plan Day. The challenge is that we are redefining Plan Day in just six months from now. We're going to release a completely redesigned product for the first of January 16. This is for a new market that we know very little about, at least at Plan Day. And in a software company like ours or any, it's easy to push deadlines and say, well, if we don't ship this feature today, well, then we'll ship it next week or tomorrow or whatever. And coming from an agency environment, I love working on a tight deadline with a, like for the January 1st. So, we are to ship this. This product or die by January 1st. That's why we call this Plan Day Brutal internally. Because we're redefining Plan Day outside of Scandinavia where we are a large company right now. But we are targeting mainly USA. And then after that, we'll also, alongside that, we'll also be targeting the Northern European markets. But mainly we are focusing on the US right now. We're also focusing on the US. And then in the company, we agreed to say no to any other projects or any other tasks that was not related to Plan Day Brutal. Because we need all the time and all the resources that we have inside the company internally and also externally to allocate to working on this. And our key goals, they are, we of course need self-managed onboarding into a simpler and a far better product than what we have today. And this is to be built with UX in mind from the beginning. And we need faster scalability focusing on the US first. And then we build it from there. So, what does it actually require? Well, of course, as I've mentioned, self-managed sign-up and onboarding is a given. We need a drastically improved user experience. For our users. Also a completely new interface design and a front end as well. And online payment. Believe it or not, we don't have that today. And account management. And alongside that, of course, performance improvements in back end as well as in front end. But all of this in just six months. Well, online scheduling is actually easy. Anyone can put out a product with online scheduling. But what is it that revolutionized this? We want to revolutionize this industry. And the layers on top of the online scheduling is the part where you start collaborating and communicating between or with your managers and with your employees. And we think that that's where the actual revolution lies. And the reason we are going about this or are going about this right now is that we started out with doing analyzing and reviewing the best competition there is out there on the market today. And what do they do well? What do they do bad? We know we can always do better. We can always improve on how stuff is done. They struggle with it with the same issues as we have. And they have taken some short turns here and there. And we know that we can do it even better. And. It's a bit skipping ahead, sorry. Well, after that reviewing the competition, we map the features that we really, really need for a minimum viable product and what we actually have to have inside the product to lead with for new users. And on top of that, of course, we'll always consider what is our unique selling point compared to all the competition. Because, of course, we have competitors out there. And we want to become the number one in this industry. So you don't follow other footsteps and you won't ever get there. And at PlanDay, we work in a very agile environment. And we are constantly trying to improve and optimize how we in design collaborate the best way possible with development and all the other teams and departments that we have inside PlanDay. And we also use whatever tool we seem fit for the job. And believe me, we tried them all. And I really haven't heard of a company that really have nailed these types of processes. They're always getting iterated on how to actually optimize these collaboration or processes of building products. So please let me know if you have heard of any. And due to the spread out location of all our offices and our teams, we also have a lot of video conference calls and the product teams. But even though we document all the decisions. And actions that we need to address or take in a tool called Confluence. That's one tool that I strongly recommend over all of these. And that's your mouth for talking. That is, of course, we don't design isolated. Always talk to each other. And at PlanDay, we have these weekly meetings where we do show and tells about the progress where we are in design and UX. And to development and to sales and any key stakeholders there is in the company. And this we do weekly at least. And development should be involved in this process as early as they can in the process. And this goes when we discuss UX, wireframes and even UI. And vice versa. At the same time, also, any UX designers should understand the fundamental aspects there is regarding back end. As well as, of course, the front end development too. So, on top of that, how do we actually collect insights? Well, we have a product that has been out there for 10 years. That gives us a good share or a good amount of data that give us the insight, some of the insight that we need. And collectively, we have 100 plus years of experience in our brains. And we also talk with sales, support and on-premise. And we have onboarding teams for customer insights. Because they talk daily with our customers. So, they have a lot of knowledge. And we use that in our decisions for the overall product goal that we are aiming for. We track on practically everything inside both our apps and in our product. And we track on overall trends and individual customer behavior using a tool called Tatango. We send out nudge emails to assist users or we chat live with them via a tool called Intercom. When we see users are stuck anywhere inside the system, we see that live and we can address it right away and help them along the way. And also, based on general behavioral changes from the customer, we can actually forecast if there are any issues. And then we can prevent customer share in that way using these tools. But we always, I know that Chris was in on this as well, we always evaluate that data with common sense. And discuss any circumstances that can influence the data that we have. And compare that with common sense and anything that could have affected it. Because data doesn't always just tell the truth. So, for the UX designers in here, I mean, so how do we actually work when we talk UX and design? Well, I'll give you a quick walkthrough. Of the process and how we do it. Of course, pen and paper is still our preferred tool. It will never go out of fashion. And I think that when we start out, we quickly can solve complex UX challenges just by pen and paper. And we also, for more longer flows at this stage, use a tool called Balsamiq. That's one for the sponsors. And Sketch is a tool that is currently our preferred one that we use a lot for wireframing. And when we break down user flows. And we base this on personas to easily distinguish the user patterns there is in any use case. And then relate that to the personas that we have defined for as our customers. And these wireframes, we hang them up on the walls inside the office. And we discuss those and iterate on them regularly. These wireframes, we validate with internal user tests on sales and support members. They know the customers very well. They talk to them each and every day. They can give us a great picture of any friction that there may be in these user flows. And for this, we mainly use a tool called Envision to create these rapid click-through prototypes which we test on internal team members. And this might come as a shock to you. We do no user testing on real users at the office. We test on real users at this point. And that's a big oh, no, no, no. How can you actually do this? But user testing in a pseudo environment with paper prototypes and HTML markups. Well, that doesn't give us nearly as valuable insight and data as testing on the real product. Of course, this is good. But with the given timeframe we have and where we are at this point. But we want to quickly get to the point where we have the actual real product out and test it on real users. It's these users that will provide us with any necessary information to make better design decisions and help us prioritize on what to do next with the product. And then when we talk actual design, we start out with these UI patterns. We design those for consistency and identifying general needs. We design the patterns for our users and user behavior. And using these patterns, it's not supposed to be seen as a constraint for the creatives or the designers in our team. It's more that it will give you a faster and more consistent result when we start designing the actual individual pages and areas of our product. And when we start designing these pages using the UI, and the UI patterns in general, these will of course naturally evolve during that process. And again, Sketch is one of our, or is our preferred tool for creating visual designs. And it's fast, it's compliant with CSS. You can actually work with live data in it. And it has several plugins for better handoff to the development teams than, for instance, or like a dinosaur like me that has been used to when working with Photoshop for many years as a visual designer. And so back to onboarding. Well, self-managed onboarding is key to us at Plan A. And in order to scale on a larger market and a bigger market when we need to expand globally, but we cannot have sales and onboarding team persons calling by phone the new signups to help them get started with our product. That's a problem that we see today that we actually have to have. We have real persons helping them get online or get onboarded into our product. And that's why we need to focus so much on onboarding at Plan A. But not as a separate area before entering the system as we have it today, where we were to explain all of the concepts there is of the system. We want a far more integrated approach and inline and in context way of onboarding the users as they fill out data inside or into the system. And we want to use design to do this, to engage and to motivate the users to achieve their goals. And that's where gamification comes in. That taps into the basic desires and the needs of the idea of status and achievement for the users. And that's why we also look at game design when designing onboarding in Plan A. An example could be that some games let you earn money. Weapons based on achievements and goals. Going from a handgun to a machine gun to a bazooka. But maybe all you really, really want is the tank. And how do we guide the user inside or into a system and at the same time gaining value without showing all the features and complexity at once just to confuse them? Our approach at Plan A is to slowly, in the new product, is to slowly build up the system based on the actions that the user actually triggers. So that will happen inline and in context to aid the user's desire for achievement and for status anywhere inside the system. And not just in the initial phase of signing up for this product, but throughout the whole system. Because you will always keep learning and you will always progress and evolve through the system as you build or fill in data into the system. And at the same time, we need to accommodate the users that just wants to get started with scheduling and explore for themselves the users that really just want the tank. But we can't win the market alone on great onboarding. And anyone can build a good online scheduling system, I would say. But what is it that actually makes it great? It's not just about managing your workforce and setting up your employees in a schedule. There's far more to it than that. We need to integrate with other ecosystems like payroll services and POS systems. We track on all stats on employees, hours, pay, sickness, anything that we can use for reports for the management. But that's only good for managers and business owners who sign up for this. We think that the real strength and the real revolution actually lies in collaboration afterwards. And that's why we believe that easy and seamless collaboration and communication between employees and managers is key to this. It's everything that happens after the schedule is done. It's handing over shifts in our case. It's calling in sick, swapping shifts. It's messaging with anyone from anywhere that you are inside the system. Or on your mobile, your app, your iWatch, Apple Watch, or whatever, where you are. And this is not just a product feature that we're building. This is the product. And this adds great value to our users. And again, that's why I think product, not features. So, what will this actually bring us in the future, tomorrow? Well, this has... The product that we build will impact on all areas and a lot of areas of our business. What will happen with the existing customers we have, for instance? What about pricing and packaging? I mean, there's been a great shift in the whole users' expectation of modern SaaS pricing models over the last years, I think. People expect a free version, fully functional free version of your product, and not just a 30-day trial. It might be with limited features or with a limited amount of users, but that's what they expect these days. And this will also spawn off some new products for us and new ways of engaging with our users. A lot of the users we work with, they have multiple workplaces. And we have to engage with them in any way possible. They are ambassadors for us. And we currently work on how we can add value to our users by having partnerships with large employment networks, with payroll and POS systems. And imagine the possibilities that are out there. And we are working with tons of more stuff like this to engage and get a closer relationship and really add value to our users. So, will we fail or will we succeed with this? Well, we know that we will fail in some areas, at least. But as long as we are aware of this and we are ready to iterate and optimize and change fast, well, then I'm not worried, actually. And we need to get that product out there and test it on real users fast. And then we improve and then we optimize on all the aspects there is of the product. And that's why we will launch on January the 1st. And I hope you don't mind, Ingrid, that I use this opportunity. Amy! Yeah. Because I assume there's a couple of UX designers out there in the crowd. So, we are, of course, we are very busy and we have a lot of fun at Plan Day as well, as you can see. So, please don't hesitate to get in touch with me if, I mean, if your boss isn't here. And so, I'll be here today and tomorrow. Okay. Before we give him a warm applause, let's just see if we have any questions for Flemming. Why, you think? I have a little question. Because everybody uses Airbnb and I guess not that many uses Plan Day and that sucks. But that's how it is. So, I want to ask you the question. You've done a lot of consumer design. Yeah. And you've nudged people like we saw Chris did on Airbnb. And how is it different to design for people that are working? Is it different? Yeah. There are many ways it's different. Yeah, of course. But what really triggers me is working with the complexity of stuff. Often, if it's consumers, well, then you have one key, one thing you need to sell or whatever it is, right? So, you need to be, of course, very consistent in the stuff that you do and have a clear point of where you're going. That goes for products as well. But the complexity there is in this is what really intrigues me. And that, I think, is very UX complex. Yeah. And solving those problems is what I think is both hard and interesting. And just like with what Chris mentioned before, you think you've nailed it with a few extra form fields. Or less form fields on your website. But that didn't do it actually, right? So, do you experience the users to be different in this business setting compared to other jobs where you had consumers in the other end? There's a lot of differences. What I love about this also is that we actually have the time to collect. Well, of course, that's more of a personal thing that I didn't do this earlier. But that we have the time to. And the data that we get from. The usage of our system. And we can track on everything that they do. And we can see where can we optimize. But always the thing is that don't trust the data alone based on everything. All the outside things that affects it as well. Yeah. So, we have one. Kim? Can you say your name and company? Thank you. Yeah. My name is Kim Skjoldbog. I'm from a digital bureau called Dwarf. I was just wondering. Do you have a sort of open API to make it easy to collaborate with your software? Great question. Because that's exactly what we are working on right now. Because we have not had open API or APIs at all given when we started this 11 years ago. And APIs wasn't talk of town at that time. But now everything we build is based on that. And we open up that whole API. And of course we need to work also as I mentioned with payroll systems and with POS systems. And working with their APIs. And we will open up our end of it as well and working with APIs. Because also when we talk online payment and all that stuff. It needs to be built that way. But it just wasn't 10 years ago or as it evolved through these last 10 years. So, that's something that we are very focused on now. Yes. Okay. So, if it's just too early and the coffee ran out. And you are not ready for business talk with Flemming yet. You can find him. He is here all day today and tomorrow. Yes. Thank you, Flemming. Thank you. Thank you very much. Thank you, Flemming. Well, you know as of the day after tomorrow I don't have anything to work on. So, if you need a freelancer. So, my next speaker is.