Building software from scratch, the user-centric approach

Maggie: We can get started. Hey everyone, welcome to Codementor Events. For those of you who are joining us for the second event, welcome again. My name is Maggie. Thanks again for joining today. It's really great to have you all here with us, and I'm really excited to be here with our speaker Veerle, to listen to her, share more about her experience, building software from scratch and user centered approach.

Maggie: If you have any questions throughout the event, feel free to raise a virtual hand, to let her know. Alternatively, you can also type them directly in a chat and we'll make sure that we get to as many of them as possible at the Q&A section at the end. Veerle, the stage is all yours.

Veerle: Hi everyone. Thank you Maggie for welcoming me. I'm going to tell you something today about building software from scratch, the user centered approach. Let me share my screen and pull my presentation up.

Veerle: As Maggie said, and in the chat that has been said, if there are any questions, just raise your hand and feel free to interrupt me and I'll answer the question straight away. After the presentation, we will also have a Q&A session. So if you ask your questions via the chat, we will answer them later.

Veerle: So, today, building software from scratch - the user centric approach. What are we actually going to talk about today? First, I'll give a brief introduction. You know who is talking, also something more about my company and then we will go into an agile software development process and what that looks like. Then we'll talk about the challenges that often come up when you're building software. Then I will talk about my experiences and learnings that I felt that we have in our own company. I will do a quick wrap-up. And then as I said, at the Q&A section, I will answer all your questions. After this presentation, I will share the presentation slides with you as well. So if there's anything that you would like to take notes off, be aware that I will share everything afterwards.

Veerle: So who am I? I'm Veerle. I am calling in from the Netherlands today. I live there and I graduated as a data scientist in 2015 from Dilbert university. After that, I started working at various companies as data scientists. I worked at a large energy company. That was my first job. And then in 2018, I got into the healthcare sector or the pharmaceutical sector as a data scientist.

Veerle: When I was working there, I had the idea to start my own company. So I founded my own business, Hypebright, and I did some data science consultancy there. And during that time I met my current business partner, Greg, with whom I'm now running Analytics Health. I am a developer. I develop mainly in R and Shiny, but also in Node and Vue.

Veerle: That's a basic quick overview of me. Then a bit more about our company. So together with my business partner, Greg, and our head of operations, Jana, we develop tools and web applications for the healthcare sector. So we gather and analyze healthcare data in order to retrieve value from the data, because we believe we can accelerate innovation in healthcare by giving access to high quality data sources. And by providing healthcare professionals with the tools they need to analyze the data. We gather healthcare data from the UK on a daily basis, all via open source data sources. And we also use internal sales data from pharmaceutical companies. Most of the tools we develop are developed in R for example, we have Shiny applications, and we have APIs that are also within R. Besides that we have applications in Node and Vue.

Veerle: As you can see, we have three kinds of applications. We have Pharmly Analytics, and Pharmly Cloud Data, and then we have the Pharmly Portal. Pharmly Cloud Data is our marketplace for healthcare data, so this is the place where you can have access to all your high quality healthcare data sources in the UK. Now Pharmly Analytics is an application built on top of that data to provide you really with data insights and Pharmly Portal is the place where all those applications basically come together. That's basically our homepage, it goes on top of our Pharmly new products, we also developed some dedicated applications for some of our customers, which are mainly pharmaceutical companies.

Veerle: Let's start the agile development process. So how do you build software using a user centric approach? And now the first question which comes to mind, why do we need a process to begin with? Because we can just build software, right? We can just jump in, start to code and build features, but we do need a process because the process helps you to align expectations between developers, your team members, your stakeholders, or your users, but it also helps you with formalizing how you should deal with new requests or with bugs or with new thoughts.

Veerle: If you have a process in place or a plan, then it will prevent unnecessary rework in the end. Besides that it helps you to stay within budget and obviously a process helps you with plan. So I think having a process is a really good idea if you are building your software.

Veerle: And then the question, why do we care as a developer? Why do we care about such a process? Why do we care about being user centric? Because after all, the only thing we do is like coding, right? But, depending on the context, you as a developer might actually be involved in all parts of the process. So you can be part of a team with like say 20 developers and a couple of UX designers and dozens of project managers and all of that. Then your role will be obviously very different from a role, for example, in our company where we have a small development team of just 1-3 developers in which you are very close to the user. So as a developer, depending on the business you're in, you might be involved with different parts of the process.

Veerle: Besides that if you know about the process, and if you understand the process, you might also feel less frustrated when some decisions along the way change. I think we all recognize the feeling that we developed something, and then two weeks later it needs to change. You know, you made something, you put effort in it. And then a couple of weeks later, then everything needs to be 180 degrees different. That's very frustrating. And especially if you don't know where that's coming from, then it doesn't help you with understanding why you need to change that. So also being involved in the process makes you see the bigger picture. It makes you understand why you were doing things. And why you are developing in a certain way.

Veerle: Then I think that you deliver software as a team, always. Doesn't matter how small or big that team is, you're building a product together. So I think it's more than fair that you are like invested in the process. That the whole team is going through to build that software product. And it's not only like important for your big software projects or only when you're working in a company, but also your side projects might benefit from a proper approach because even your side projects, you can manage in such a way that you can deliver in the end to products that your users are happy with.

Veerle: I don't think I mentioned yet, but I'm a scrum master myself. So I have a lot of experience with agile methodology and I honestly love it and we use this intercompany to streamline our projects and I would definitely recommend it as well, if you're developing software.

Veerle: So what is it? If we're looking at what is agile software development, we're basically talking about little cycles or little iterations you're doing. For example, you see here such an iteration on the screen. You start off an iteration by planning and like, basically finding out what the requirements are. Then you start designing that feature. Then you start coding. Then you release, you get a feedback about this feature and you do it all again. So this constant loop of small iterations, normally a cycle takes like two weeks or something. This small loop of iterations keeps you basically involved for your users and your stakeholders. And it's a great way, and an efficient way to provide tangible software, like early on. Because every two weeks you’re aiming to release something, even though it's like a small button or it's a change of a styling of your app or whatever you aim to release as quickly as possible in order to get her feedback as possible. And that's very important if you are developing a user centric software.

Veerle: Why do we need to be agile? As I said, it's an efficient way to provide tangible software as soon as possible. Like every two weeks or something is like normal. Because you are like working in these small iterations, like constantly gathering feedback, like every two weeks, you're also able to quickly jump in on changing user requirements.

Veerle: And I think having these kinds of cycles and tools gives you a lot of transparency and constant feedback, so you can improve your products. Besides that normally in like such a neat duration, because you're gathering feedback, you really are engaging with your stakeholders and your users because you need to test the software if you users like it.

Veerle: So there's high involvement there. It's also great for expectations because normally, you know, exactly, in the next two weeks, we're going to do this and that. And then your stakeholders know, at the end of these two weeks, I can expect this button to be here or there where these functionality to be present.

Veerle: And I think it's less daunting to work in these kinds of smaller cycles compared to big projects. Because if you have a big project and let's say, this project will take eight months, go do it, have fun. I mean, I think that's quite daunting if you say, well, eight months, what do I need to do? How am I going to organize that? So chop it up into smaller bits. Then next to being agile. There's this other philosophy that if you are a bit involved with, you actually would know and we call it the user centered design. The user centered design is like another methodology next to agile, which is also about it's ratios here.

Veerle: Only the focus is really on the user and it's about designing your features and functionality so that it basically fits the users as best as possible. So first you're going to see, okay, what does my user need? You try to empathize with them and you're going to define like the requirements of a feature or functionality they're going to ideate or make ideas about it.

Veerle: It's brainstorming, then you're building a prototype and then you're going to test it. This user centered design principle is not about coding yet, but it is about like, does this future, how is this going to work for my user? Will they like it? And how can I best design? The focus is different here.

Veerle: Why would we need something like UCD or, the user centered design? Well, because it's basically minimizes guesswork by providing a mechanism against which design decisions can be found at the ages that this that's because constantly you're coming up with designs, which you'd take it back to your users so that your users can actually understand. Or you can understand if your users are going to like it or not. So in the end, a UCB provides you with a more useful and meaningful product. And that's because you did all that testing and get that feedback. So it also minimizes where you work. Because if you know what your users are going to think of for feature, then obviously your feedback will hopefully be along the lines of, wow, this is great. That saves you some work. It provides a way to deliver quality experiences. So then we talked about being agile and this user centered design.

Veerle: What's the difference? Is being agile actually being user centric? Honestly, we kind of talk about this whole discussion between agile and UCD. But what I wanted to tell you today is that if you look at the two philosophies that you will see in agile, that there is a focus on quickly releasing stuff, making sure that you're satisfied customers and UCD equity balance of that would be like, okay, we need to create or think about our end users.

Veerle: We need to make sure that they have the best experience possible when using our products. And I think if you can combine the two, if you can combine the methodology of being agile, like quickly releasing constant feedback, focus on tangible self. And if you can combine UCB with the extreme focus on okay, whatever I design needs to be right for my users, because they are going to use the product.

Veerle: I think if you are uniting the two, that's cool. And what I also want to mention is that, the most awesome thing with these philosophies, you don't need to see them as fixed. Like if agile prescribes you to do step one, two, and three, it doesn't necessarily mean that you need to follow it 100% in full detail.

Veerle: That's the same for UCB. You can follow all these steps in full detail and completely give yourself into the methodology, but it doesn't help. It's more about the thinking behind it. And the only thing that agile development wants is to make sure that you are close to your user, close to reality.

Veerle: By having these short cycles, I've gone asking for feedback and it's just to keep your mind so you can combine the two. So that's why I always say you have like this agile UCD process that you can follow. And this is just the process. And as I said, don't see it that's 100% fixed, but this is the process that you can follow to actually make yourself aware.

Veerle: So first you start by gathering requirements so that you have a clear sense. This is probably what my user wants. This is what we look for, my stakeholders want, so this is what we need to do. You need to find yourself a standardized way to basically document the requirements so that everybody on your team knows the requirements to know what they look like.

Veerle: Then you always start with designing things. So if you have a requirement, it's always good to have that visual representing what the requirement is. That doesn't need to be a full blown wireframe or a full-blown workup, maybe even a small particular sketch we'll do. As long as you do have anything that you can look to, and this will help you with guiding whatever you're working towards.

Veerle: And even though you have a sketch, you can present that to your users and say, hey, what do you think of that? You know, especially, if I may talk for my business, we developed a dedicated software for you. So we know our users pretty well. We talk with them like every two weeks, and then it's very easy.

Veerle: If you have a sketch, even though it's a quick sketch to show to them and then see, hey, do you see this working? Or do you like this? And then when you have the design, then you can actually start digging into the code. So you can actually start building and I would always recommend adults coding best practices and make code consistent across your team.

Veerle: Make sure that's in whatever team you are that you have like a standard set of rules that you're cohesive follow can be things like naming conventions, code styling and that kind of stuff, but just make sure that it's, it doesn't matter if person A or person B wrote the code, but that you have a stream of code.

Veerle: I see a question from Jen.

Jen: I'm raising my hand for one of our attendees. So Hyung, I'm sorry. I'm sorry if I pronounced your name wrong, did you want to raise your hand and then ask Veerle yourself? Can someone unmute him and see, okay. So, can you hear me now?

Attendee: Yeah. So I just had a question. I don't mean to interrupt because you're ongoing, but I just didn't want to miss this point in case at the end, if I had gone in the end. So I just want to check for your user centric design, which is like a smaller cycle of get during the use of feedback before you do a full blown cycle.

Attendee: Right? So like, do you have any advice for a good number of end users? Like 5 or 30? I mean, this is something that I'm also struggling with because I'm an indie developer myself. And I also see that you only have a team of three, so gathering many people is logistically very difficult. So do you have any good advice for the number of end users?

Veerle: Yeah. So that also depends on the context. So our applications, for example, have under 100 users. So that means that we're not going to ask 100 people for their feedback. Like if you have thousands of users, that 100 might be a reasonable number. So it depends on like how big your application is, how many users issues who's asked if you can.

Veerle: I would aim at like, well, somewhere along the lines, 1-5% of your user base. And then not, and you should also carefully consider for which features you are going to do a full-blown research, because sometimes it might be enough to take existing research. For example, if you need to think about colors of buttons or where to place close buttons and things like that, you can rely on existing research, and otherwise just spell, see that you need to like balance between, okay, is this feature going to be really big and really important and really fundamental? Maybe I should ask a bigger sample of my user base, but it all depends on the context really. Does that answer your question a bit?

Attendee: Yeah, I think so. I'm asking because, for me, I'm contacting end users by Instagram direct marketing, you know, so sometimes it's very, tiring and time-consuming, but I guess it really depends. Thank you for your answer.

Veerle: You're welcome. Okay. Another hand.

Attendee: I'm sorry, just to follow up on that. I know I'm part of Komen, but just kind of a, you said, you know, it really depends on the feature and like 1-5%, in terms of methodologies, do you usually use, let's say like surveys or do you distribute surveys to like 5% of people in this? I don't know, 10% from that to do user interviews and things like that.

Veerle: Yeah. So we're actually very lucky with our users because our users are very involved in our products. We develop very specialized products, for a limited number of people. So we have the luxury of just going into meetings with them, presenting what we have in mind and gathering their feedback.

Veerle: And we will get all this feedback from them, but that's a luxury that we have. If you have a really big app with thousands of people on it, for example, and that's going to be available in the app store, it will be a different story because it's very hard to gather feedback from people at that point in time.

But then for larger audiences, I would do something like A/B testing or setting up surveys. But that, again, depends really on the context, what you could do best.

Veerle: So where were we? So I was at the testing stage. If you developed your feature, it's also obviously very important that you test it. Because you can't release everything into production and then just hope for the best you need to test it. You can use unit tests for devs, but also just some user tests. You can get some users on it and gather some feedback.

Veerle: Then you can release, but release wisely because these two-week cycles are really aimed at release as quickly as possible, you know, do it as fast as possible, we want to see results now. But you should also do it wisely. So make sure that whatever you release is high quality, because you can only deliver a user centric software product, if you deliver a high quality product as well. So make sure whatever you release is really centered at the user and provides the user with the best possible experience.

Veerle: And then obviously very important. Take the time to get feedback. What I see too much happening in these agile methodology is say, we have this development cycle. We release some features. Now it's time for weekends as a matter of speed, but take your time to actually get feedback about the features that you just released so you can improve upon them or incorporate this feedback in later cycles of your development. So take the time for that.

Veerle: So then, a couple of challenges that you have with like software development. One of them is a very known concept known as technical debt. It's also known as design debt or code debt. It is a concept in software development that reflects the implied cost of additional rework costs by choosing an easy solution.

Veerle: Now, instead of a better approach, if we take. And this is something that's really, a risk when you're doing agile development. Because as I said, agile development is most often aimed at releasing as quickly as possible. Do it as fast as possible. We want to see tangible results after those two weeks, but often leads to developers making the easy choice.

Veerle: In the end you're going to regret it. Because if you make choices now and build on top of that, then you're building on more and more debts. And it's very hard to repay that. So Ward Cunningham, he is one of the authors of the agile manifesto. He once said that some problems with code are like financial debt, so it's okay to borrow against the future as long as you pay off. Ward used this term as a metaphor and he called it technical debt and has gained momentum ever since I think every software developer knows of this concept, and it is still a real problem in today's world because we see it all the time.

Veerle: So what actually causes this technical debt. Well, one of them is like for definition and requirements, too tight deadlines, too much pressure. As I said, if everything is targeted and aimed as do it as fast as possible, you might go for more easy solutions. And it's also underestimating the time it takes to complete a task.

Veerle: Because if you, especially, if you work in these agile cycles upfront, you plan like, this task is going to take me like this many hours. And what's happening is that we underestimate the time. And then at the end, there is some crisis or some stress to actually get the deadline that we choose for the easy solution.

Veerle: It's also a lack of knowledge, and a lack of test. So what are actually, if you summarize all of these, the causes of technical debts are for the software development process. If you make sure that you have a solid software development process, if you account for all these things, then you can minimize the amount of technical debt.

Veerle: Technical debt, we’ve all seen it. And it only takes you longer to build features on top of your product. It's dangerous and harmful for your product and you need to prevent it. And as a developer, you play a role in this as well. You have a role of educating the rest of your team and you have also the role of recognizing the risk of technical debt.

Veerle: So as a developer, if you're working in a team, please be aware. That's when you're making a choice, think for yourself, is this the easy choice because I want to deliver this as fast as possible? Or is it the best choice? Because, again, technical debts, your users are going to see that because if your users are expecting a ‘wow’ experience of your application, but it takes you like, I don’t know, months to build like this additional button, because you have chosen a framework which is not suited for it, then your users won't benefit from it.

Veerle: Then another challenge we often have when we're doing agile software development is, okay, that's all cool. And all this user centered approach and doing what the user wants, but unfortunately the user doesn't always know what he or she actually needs because there is a, what do users want versus what do users need?

Veerle: So a user might say, “oh, I want X,” but the user might not need X, but actually Y. So imagine like a couple of years ago, if you didn't know you needed an iPhone, but now we do, you know, that's exactly how it works. We don't know what we need and if you're building software, right, it's your job basically to figure it out.

Veerle: You need to try to figure out what the user or the stakeholder really needs instead of just delivering items on the way, because that's very easy, especially business stakeholders who might not be the same as the actual users of the products might just say, okay, give me this feature and that feature and that feature.

Veerle: And then we're having a good product. But always strive to be like the critical thinker and also ask is this really the best for our user. And then again, this comes back to, if you want to build user-centric approach, you need to understand your user and how can you do that while you can also, you can ask questions. So questions of your own questions really.

Veerle: Okay. So you want this, this button in your episode. Why, why do you need it there and how would it help you in your daily life? Instead of like, if you're designing an app for buying groceries online, you could say like, Why do you buy groceries online, but you can also ask other questions, like, okay, what do you do when you buy groceries online?

Veerle: What do you do before you go online shopping? What do you do after you go shopping? What doesn't work for you when you're buying groceries, or who are you with when you buy groceries in line? Who do you consult for advice? Like you can ask all kinds of questions around that to really understand this is probably what my user needs. Instead of just building an app where they can just buy groceries.

Veerle: Then another challenge is obviously choosing the right framework because if you start on a big software development project, then in the early stages, you already need to make a choice for the framework and which framework here.

Veerle: I mean like, are you going for Vue or are you going for React? Are you going for an Shiny application? There are so many frameworks that you can choose. So what should you actually choose? Because this in the end is also going to determine your technical debt. Because if you make a mistake in the beginning with choosing the framework, you might because it's the easiest framework or it's the framework you have the most knowledge about. You might end up with building something that's not suitable for you. So the things that you might want to consider and the most important thing in user centric, software development, your users. Please think about first, how your users are going to use the products, how are they going to open it on their PCs? How are they going to see it on the mobile? And depending on that, choose the framework that best suits the needs.

Veerle: For example, we developed our Pharmly Portal, which is basically a portal with all kinds of things. Smaller apps. That's because our model or pricing model will say, okay, users or clients can choose like different modules. So they might go from module A, B and C, or they might go for only module A or only C. So we thought, how could we best, which framework could we best choose to do that? In the end, we chose microphones and structure. And with this microphone structure, we have like all these independen apps, which are basically our modules.

Veerle: And then, these are like standalone mini apps. So to say, and it makes it very easy for our users to basically choose a package in which to say, I only want like this piece and that piece and that piece, and I want to have access to it. And that's why we made the decision, for the sake of our users to go with.

Veerle: Structure, but for you, it might look totally different because it all depends on your context and your users. So besides your users, you might want to take a look at obviously the development community. Is there a lot of talk about the framework you're choosing? Are there enough people active? If I don't know anything I want to browse stack overflow.

Veerle: Can I actually find something on stack overflow? And it's really important than the support either from the framework developers or from other developers, obviously things like is there enough technical documentation, is maintained. Is it easy to understand? Is it sustainable? And obviously you need to look at your team.

Veerle: You might want to build an app and react, but they've nobody on your team knows about debts. Then that's also another solid choice for you, right? So it's all a balance between, while disliked. And the current state of the art framework in today's dev community versus what do my users want and what is best suited for them versus what can I do for each?

Veerle: Do I have the resource naming skills? Yeah. Then I come to our learnings because having your own company, you learn a lot. I can tell you that. We've learned a lot from developing software. We have learned a lot from making mistakes. We are still learning a lot and I want to just share like learnings with you and our own experiences, so you might benefit from that as well.

Veerle: The first question is, okay, we are a small team. Yes, we are a small team. So can we do agile development? And yes, you can. I mean, To be a team of 10 or 50 people to implement like an agile methodology or an agile way of thinking you can be with any size. And as I said earlier, you can adapt methodology and your processes to your specific environments because context matters, you know, for us in our company, a startup company with a relatively small team of people, things and solutions might look different than from an established company that has been there for 25 years and has multiple development teams.

Veerle: So context is really important. When you are implementing anything, really any software development process that you're choosing, but you can do it. I honestly, I love to do it even in such a small environment, because it just keeps you focused like the small cycles of constantly releasing and it helps you to actually quickly see tangible results.

Veerle: That's why I like it so much. We do everything like in small cycles, but that's obviously not how we start straightaway. So let's say that you're just starting on this big project for a client or you're building a new effort from scratch. You're obviously not jumping into like these short sprint cycles as we call them straight away.

Veerle: What we do normally is we start off with multiple kickoff meetings. So that's, we just have brainstorm meetings about, okay, what's the app going to do? What’s it going to look like? We have also meetings about, okay, what is the longer term planning? Because the two week planning is not going to cut it every time you need to go.

Veerle: You need to know. In so many months I'm going to release this product. Or in so many months, I'm going to market with this product and we have kickoff meetings with, and without our stakeholders. So it's only our core team. We talk about the new project, but also with our stakeholders to brainstorm together with them.

Veerle: Then we have, like, normally what we do is like this big design. So we start with sketches and then we do have a UX designer who helps us occasionally and we let him turn it into wireframes and so did we have a broad design.This is what the applicants look like. Most often we take this design to our clients as well, “Hey, we have designed this. So you're like, this is what you do differently.” So that's very valuable to have that and make sure that you keep designs in that make, because if you're gathering feedback along the way, and if you're taking your designs to your users and if they say, well, no, I, I don't see how that would work or whatever, especially.

Veerle: If you have a dedicated product. I mean, we make products for pharmaceutical companies who have very specific needs and pharmaceutical company is not the other. So for us, it's very important to keep designs dynamic and to change them as we go. And then obviously before you start, you should decide on your framework and don't do that.

Veerle: Like overnights they'll do that in a one hour meeting. Think about it. See if it makes sense. Make sure that you don't end up with a huge technical debt because you made a wrong decision and also keep in mind your users, the goals which are products. And obviously it's like this delicate balance between the time that you have skills that you have in your team, the budget that you have said, well, that's all matter when making this framework choice.

Veerle: So I think we've done that like. General pre-process like, and we know with regard to bills, we know what framework we're going to use. We know it's going to look like stakeholders are happy with the idea. Everybody is like, I'm excited to start on it. Then we start our sprint cycles. So we've basically followed.

Veerle: Somewhat the steps that I mentioned earlier we get a requirement on the board can be any kind of board. It's just thought process can be like the git board or project board. We usenotion for it, but you also have liked JIRA or any other kinds of software. Then we, especially for smaller features, because if you can have something like your general design for your big app, you will see does whenever you're doing small add-ons or based on feedback, you might think of other features that you want to implement in your app.

Veerle: You're going to the needs designs sometimes. Either we all scholar creative UX designer to do something for us, or we make quick sketches, but make sure that whatever requirement you have that you have, like this clear understanding of, okay, this is what it's looking like in here. Then we actually develop, which is the fun part. And then what we do to make sure that we across our team have like a standardized way of coding and sending up our projects. We also tried to standardize the use of libraries and packages, because person A might like a specific library and person B and others, but it's nice. If you can come to a common ground, you know, it's not code that looks completely different every time.

Veerle: And then we do some testing as well, obviously. So we test the functionality. We see if it integrates a new feature, doesn't break anything else. If the requirements are met, obviously then we release, obviously when tasks fall that we release to production. And sometimes before we actually do the release, we will lay it back.

Veerle: Get some feedback from our users before we actually release, because sometimes a feature is so dedicated to a specific client or user as we actually say with them. Okay. Are you happy with that? So if you need to change before we actually do the release, so then we might shift the feedback and the release stage a bit.

Veerle: So again, that's dependent on your situation and yeah. And so when it's released, we get a feedback, basically all, all around. So every day we get feedback about our apps. We also welcome feedback from our users, obviously. If they say any new feature ideas or bugs, we fix them in the next cycle.

Veerle: There's a bit a quick loop into our process. And then some learnings. I want to share it with you. I have quite a few because we did learn a lot. My number one learning is like, don't get stuck in this particular framework or process. You don't follow the agile methodology or the UCD methodology, like step-by-step 100%, it's not black and white.

Veerle: Okay. You need to do what works for your team. As an example, normally when you are working agile with smaller tasks, you can have a lot of tasks on your plate. So you might have that a team member had like 10 tasks to complete in like a two weeks cycle. But actually we didn't like that in our team so much, we much more like to have like a big epic, which we call it a big subject basically, where we then work on.

Veerle: So we call it an epic and it's basically a very big task, which we pull all related tasks in. So it just makes it more comfortable for us to work with. So whatever you do, whatever process you choose do what works for you then also don't make the mistake. And don't say, well, I know it's going to end up with technical debts. I have covered definitely. I don't know any self project that doesn't have any amounts of technical depth. You will always have a bit because the choices you made in the beginning are going to, well, set you, you know, they are the choices you make will determine what future choices you can make. This will always be the case, but you can limit this and try to match it, but please always be aware of it that this happens.

Veerle: Then also whatever process you choose, maybe you invent your own process because you, it works for you. I don't care. You need to communicate clearly with your stakeholders. You need to make sure that your stakeholders know what you're doing and how your process looks like, because that prevents frustration on their sites.

Veerle: Then I'm aiming for protection. I think a lot of people have the tendency to do everything perfect. They won't go, but a drive to do it. It's a small step. So if you're developing software, try to do it like, I don’t know, first make sure that the functionality is there. And later on, you can optimize extra functionality. For example, if you want to make a feature, in which you can add shopping lists or something, well, first make sure that the functionality is there to add lists and to few them. And then maybe next on you can focus on actually changin the icon or the color or off the list, you know, of like making these more personalized changes.

Veerle: So focusing on quickly releasing at least something so that you can get feedback and then you can perfect the way, because if you're aiming for perfection straightaway, you might develop something that your users actually don't want it all, you know and as I said earlier, instead of focusing on stakeholder requirements and just fulfilling a wishlist focus on the, in the line motivation, because in the end stakeholders, I'll ask you to develop yourself for product.

Veerle: They asked you to develop something because you have expertise in developing software. So them saying that they want A, B and C on their list, doesn't mean that they know best. That doesn't mean that ABC is actually the best thing. So I'm always trying to get that underlying motivation so that you can actually help them to make or help to make the product a better product.

Veerle: Then another thing: don't underestimate our research. But also don't underestimate powerful, existing research. You don't need to reinvent the wheel. A lot of UX research has been done on how you can best do things. You can also think, look, you do your own research, similar apps. Look at them, see how they do things.

Veerle: They don't need to do everything from scratch necessarily. Then I think with every project, small or large side project or project for a company or working for planning is key. If you're just going round, as I will say, and just build features here and there, and just go as you, please. And this will not give you default.

Veerle: Delivery or user centric software. And then also, if you are choosing this agile software development process in which we have, like these short cycles, these iterations don't get stuck in this two week vision, because sometimes when you're working in an agile project, if my team, the two weeks, it's this time spend that you had the two weeks is everything that there is.

Veerle: And then it starts all over again. But don't lose track of the bigger, big picture, always know what you're working towards, and that is like the best self rep possible for your user. So don't forget that. And then if you want to prevent things like technical debts, and if you want to prevent making too quick decisions, because for the sake of time, Please make sure that if you are estimating design for a feature or functionality that you incorporate extra.

Veerle: So if you say, okay, this both in is going to take me 10 hours to put it. I don't know if it's with 50% or something, maybe 15, because, you're underestimate. And we've learned that the laws we still do, we still underestimate, the time things take. And yet, as I said, always design your features.

Veerle: Even if it's only a quick scratch, you don't need to do a full blown wireframe or whatever you don't need to be, especially a UX designer to do these kinds of things, even if you're on your own and developing a project on your own, make sure that you do a quick sketch so that you know what you're working through.

Veerle: Then a quick wrap up, but I told you today before we're going to the questions. I think the main takeaway that you can have from this presentation is don't jump straight into the code. You know, think, plan, get requirements before you actually start jumping into coding. And we all love to do that as developers.

Veerle: I know, but they've stepped back and focus on what might be best for you here. And it doesn't matter how big that project is small or large. We all need a process. We all need to design and we all need to be user centric. If we really want to be our software to be a success. And then building self right, is a team effort, you know?

Veerle: Don't get too isolated as a developer. I've heard people saying things like, yeah, I'm a developer. I don't need to know anything about. Oh, I'm a developer. I don't need to know anything about, I don't know, how things work, how user interface looks like I just code. But I think that you can only build skewed software if you understand for which you are building itself where a name for your user, and if you understand the full process, and if you do it as a team, like teams are there for a reason, themes are there, he goes, they work well.

Veerle: And because the individuals in the team, make sure that there's more failure from each individual team member alone. That's why teams are there. So please, even as developers, build a software as a team effort and not only focus on your coach, try to understand your user as well. And it will really help.

Veerle: And then it's right. Like, do it again. Get feedback. See what you can improve because the software is never finished. You can have the definition of finish. You can have a definition of done. You can have the definition of first release, but software has never finished. There's always things to improve.

Veerle: So if you iterate over that, you will actually get better and better at each step. And that's my main wrap up. Are there any questions? I think there's a lot happening in the chats, which I haven't been reading, but I will pull up. So let me see what we have.

Maggie: So I believe the first question is from Wayne. Wayne, do you want to unmute yourself and ask the questions yourself?

Wayne: Hi, how is everyone? Thank you very much. It's a really, really good presentation, first of all. Just a quick question, really. I'm intrigued around the phased approach that you have that you showed up in one of your earlier slides around the design phase. And I am intrigued to know, how do you test that?

The testing stage are you doing just like small tests? Are you using the designs? Do you have a QA that looks at that, and how you build that into your AC?

Veerle: So as I told, we are a very small team, so we don't have a full blown team. We test the design by going straight to our clients, which we are lucky enough to do. They are our users as well. We are lucky enough to have like these dedicated users that help us to build our products. So we go to them and it all stems like this is the design. Do you like it? Do you want to see any changes, etc? If you are working for a bigger audience, I would definitely do something with AB testing.

Veerle: So if you want to do find out quickly, if your design works for a certain group of people, just subsets, basically your large audience into a smaller bar, then show them one version of the app or the other version of the app and do some tests on that. And then obviously, because it's testing your design takes time. You should do that cycle before you actually develop. So always the design requirements cycles long cycle before you actually development cycles. Because if your development, if you're developing, you already need to know this is, this is going to be eight. That's what I would say. Does that answer your question?

Attendee: Yeah. Yeah, no, that's fine. It's fine. I know there's no explicit answers to this sometimes I think you're absolutely right. You are confirming definitely with the user base and that when you've done an iteration, you're going to get feedback. Yeah, thank you very much. Thank you.

Maggie: So if anyone else has any questions, feel free to raise your virtual hand and then Veerle can know. For the next question, he was asking in building a software product, is the choice of the framework really important? Also when using a framework, what is the best architectural approach? Sometimes a project gets overwhelming when it grows big in size. For example, having a good component of structure. Would love to hear from you and how you handle this.

Veerle: Is the choice of the framework important? Yes, it is, because not every framework is suitable for things that you want to do. For example, as I said, some things we develop in our Shiny, the other ones we develop in Vue and that's for a reason because, the Vue application is more of a CRM kind of system, which is not really suitable for a Shiny application while our Shiny applications are more dashboard style, like teams.

Veerle: So yeah, the framework that you choose, can definitely limit what you can do with an application. So it is important. And obviously when a project grows and gets bigger and bigger, it might be very overwhelming and that doesn't really matter which framework you're using. But if your project grows, you need to make sure that you do within components, that you don't repeat yourself, dry principle, and that you make it as manageable and efficient as possible.

Veerle: So even if you choose Shiny, if you choose Vue, if you choose Note, try to do it in components, try to split it up into smaller pieces to make it actually manageable. Component structure. Yes. I would definitely recommend that. And I think every framework nowadays supports that kind of structure. So I hope that answers the question.

Maggie: Okay. Thanks for answering that. So we do have a couple more questions from Donjung, do you want to mute yourself or. I think, okay. I think he said in the chat that he would like me to ask the questions on his behalf. So this question is how do you ensure that users are always motivated to collaborate and provide feedback, especially if they're the first time users? Do you provide compensation? If yes. What advice would you have to motivate your end users to get feedback?

Veerle: Do we provide compensation? No, we don't. You get a lovely chat with us. That's the compensation and you will get a product afterwards. So I think it's great motivation, but then again, we have a very dedicated user base. That's not the case if you're developing for talents or for individuals. So to say, what I would then do if you're doing survey-like things, I think it always works if you have like some kind of compensation for a survey, even though it's maybe extra points in a savings account that you have, or, maybe it's like an extra feature that's being unlocked or a small thank you. What'd you can also do, even if you are talking with clients, do something simple, give them a Starbucks coffee, you know, you have like these online vouchers that you can do. Just give them a thank you. Say that you really value their feedback. And also try to motivate people by making a survey fund, you know, give feedback in a fun way.

Veerle: You often see like these things that you can give a smiley face or a very, very mad face. Do the things that people are intrigued to quickly do, don't ask them like 7 billion questions and don't put in requirements. Your text needs to be applying to 300 charters. Nobody's going to make it a ton as possible. And I hope that that will motivate people to actually help you out. And also let people know what you did with that feedback, because nothing is more motivating for a user than if you said, okay, I want to see this feature that if you can say a couple of weeks later, Hey, we've built this for you. Go check it out. So try to keep track of who provided you actually with that feedback. Try to give that back to them. That's a really nice way I think.

Veerle: He had a follow-up question as well. Basically our experiments did using the UCD approach provides you with better outcome clarity on the design direction from one full fledged design or two specific pieces of design. We have to understand that our users might lack that attention, power with a patient schedule.

Veerle: That is certainly true. Well that, again, depends really on the context, you know, you might want to show the same user 3, 4, 5 different options of how the design could look like, which is obviously very heavy on the user because that takes a lot of time or are you going to divide your user base in hopefully deem well, graphically the same kind of samples, which you just provide with design A, B, C, D E you know. If you do debts on a statistically sound basis, you might get the answer that you're looking for.

Veerle: But as it really depends on the context, how you can manage that best. If there are any follow-up questions, just let me know then another question from Steve that was sent to me.
Question: What tools do you recommend for wireframes or sketching?

Veerle: I think wireframes is sketching. Figma is writing. Nice. And you also have mock-ups, Figma. I think maybe a bit more difficult to understand if you are not a UX designer, it's not hard, but it requires a bit of skill and mock-ups, everybody can really do that. And if you don't have access to mockups or Figma, you can also simply do stuffing comfort or something, you know?

Veerle: As long as you have a general idea, it doesn't need to be perfect. Doesn't need to be 100% accurate. As long as you have a general idea of what it's going to look like.

Question: Then a question. As a business side person, how can we ensure proper framework used by the developer?

Veerle: Well, I don't know if a business person necessarily knows whether it's the best framework, a business person. It depends on what kind of business side person and it is. I think you should leave the choice framework to the people who are actually have the most experience with frameworks. I would say developers, but again, this is a team effort. And as a team, you need to decide on the framework. Don't let one person on the whole team say, okay, this is going to be the framework you need to all agree on the framework you're going to use.

Veerle: And the framework you are going to use depending on a lot of things, the team skill that holds the data, all the things, as I mentioned, you know. Don't let it be a one-man decision. And I, we are almost out of sight. I see if we are out of time. I have time for one question. One last question.

Question: I am a software developer that has accumulated some technical depths, how do I find people to work with?

Veerle: How can you find people to work with? You can ask, like for freelancers who want to help you out, you can find, see if you can, like, I don't know, reach out to connection or Codementor, probably.

Veerle: On Codementor, you have a lot of developers who might be able to help you out or assist you in your projects. If he had LinkedIn via social networking, just, there are a lot of developers out there and those developers who might be really team up with you. So we definitely take a look at these kinds of platforms for debts.

Veerle: That's it. What I want to share with you. One last thing is, my LinkedIn. Please keep in touch with me. Send me a connection request or give me a follow. I occasionally share things about maybe to our programming language, but also about software developments and how we do things at our company.

Veerle: So if you think it's interesting, please reach out there and then thank you very much for your time and for all your questions. And if you have any more questions that you want me to ask, which I couldn't answer here, you can always reach out to me on LinkedIn. Thank you.

Maggie: Awesome. Thanks so much for this amazing talk, Veerle. As for taking the time to answer everyone's questions and stuff. Wonderful talk. And I personally learned a lot from this. So thanks again, everyone for joining our event and a huge thanks to our speaker, really for giving this talk today. So I hope everyone enjoyed this and stay tuned for our next event, which is titled how to overcome imposter syndrome in tech. It's happening next week on December the third, if everyone is interested in joining that and I hope to see everyone there, we posted some information in that chat.