We also want to briefly touch on user research<\/strong>, which should come before product development. This is where you engage with your challenge or problem rather than the solution, and where you research your users’ behaviour and their needs – after all, you don\u2019t just want to build something based on your assumptions, but on data and evidence – you\u2019re aiming to build something that works for the people who need it. There are lots of different ways to approach this: Catalyst\u2019s User Research<\/a> resource bank contains a wealth of information on understanding user needs.<\/p>\n Once you’ve secured a budget, you can start building and designing. If you’re not yet at that stage, have a look at our resources on getting funding<\/a>, and even getting the rest of your team on board<\/a>.<\/p>\n So, what are you building?<\/strong> Let’s run with a hypothetical example that has enough moving parts to inspire plenty of jargon: an interactive map which shows the locations of empty, disused buildings. Let’s call it ‘Empty Property Finder’.<\/p>\n Now that you know what your service is going to do, it’s time to engage in some jargon-heavy conversations.<\/p>\n Your designer might talk about building a wireframe<\/strong> or a prototype,<\/strong> so that you can see the rough layout of how your Empty Property Finder will look, without any actual content. This will probably be thrown together in a popular design tool such as Figma<\/strong>, so that you can play around with the look and feel of your service. This is so you can decide things like what screen a user is taken to when they click the ‘add property’ button, for instance.<\/p>\n All of this stuff falls under the umbrella of UX,<\/strong> which is short-hand for user experience<\/strong>. This is a term widely used to describe what an app or service is like to use. A quick way to understand what UX is to actually use a bad<\/em> example: if you’ve ever found yourself thinking ‘where on Earth will this button take me when I click it?’ after filling out an online form, you’re probably interacting with some bad UX. Good UX is usually hardly noticeable at all.<\/p>\n Your designer will be collaborating closely with your software engineer(s), who will actually build the Empty Property Finder. An engineer will implement the designs so that they look exactly as the designer intended \u2014 this is what the frontend<\/strong> is; it’s the stuff that the users see. The other key engineering task is to get everything working behind the scenes, or in the backend,<\/strong> so when a user hits ‘add property’ all of the relevant information is sent to your service, and the map is updated. For more on the differences between types of design, see our design jargon blog<\/a>.<\/p>\n Something else you might hear about at this stage: APIs.<\/strong><\/p>\n The Empty Property Finder relies heavily on the use of an interactive map with dropped pins that contain key information, a lot like Google Maps. Building your own interactive map from scratch would be difficult and expensive, so it’s very likely that your engineer will simply use an API – which stands for ‘application programming interface’, and is:<\/p>\n The use of an API may seem very specific to our example, but engineers rely on them heavily to build higher quality products and services.<\/p>\n Finally for phase one, if you’re working with a product manager, they will be the one setting and prioritising tasks for the engineers and designers. To do this, they may use tools like Trello<\/a> or Jira<\/a>, which layout tasks in a kanban board<\/strong>. This is just a simple way for everyone in the team to track progress. A product manager may want to separate tasks into sprints<\/strong>, which are essentially blocks of time in which to achieve a particular goal. E.g. a sprint could be two weeks, and by the end of it the team should have built the frontend of the mobile app based on the wireframes provided.<\/p>\n You’ll notice the left-most column is called backlog<\/strong>. This is just the stuff that hasn’t been started yet \u2014 in a digital project like this one, it will basically consist of features and bugs<\/strong> (anything that might be broken) that have not yet been implemented or fixed.<\/p>\n You’ve played around with the prototype of the Empty Property Finder, and tested it on a handful of users, and are happy with how it works; the engineers have been working away to put it all together. Soon it will be ready for release. Perhaps you hear a lot of talk about releasing an MVP<\/strong>. This stands for minimum viable product, which is essentially an early version of your Empty Property Finder, which you will continue to improve.<\/p>\n This is exactly what iterating<\/strong> is: you continue to build, even when your service is live. It’s nearly impossible to know exactly where any problems might lie before anyone starts using it, so you identify these as you go along, and make regular updates.<\/p>\n Good job you’re working iteratively because would you look at that: you’ve started receiving emails about the ‘add empty property’ button not working. Something’s broken, but what? You can easily roll back to an earlier version so that people can still use your service while you figure out what went wrong. This kind of process is handled with Github.<\/strong><\/p>\n Engineers use Github to collaborate on the code they are writing. If multiple people are building the same thing, Github allows them to see who has added what code and when. This is even useful when it’s just one person building, because you can see all past versions of the code and jump back to when things were working.<\/p>\n Now that the Empty Property Finder is being used by a few different people and organisations, your designer will want to know how well the UX is working. They might do this by working with an engineer to implement an A\/B test:<\/strong> where you release two versions of the Empty Property Finder at the same time, to see which works best.<\/p>\n Something else you might hear about at this stage: user stories<\/strong><\/p>\n Your designer is going to be paying close attention to how your users are interacting with this service. Where are the pain points? Is there anything in the design that’s making the Property Finder harder to use? This is where defining user stories<\/strong> come in. These help you think about:<\/p>\n So a user story is literally a statement from the user’s point of view: “As a [type of user], I want to [goal], so that [benefit]” but with the gaps filled in. For your service, that might be “As someone working in VAWG, I want to find empty houses so that I have refuge space for survivors of domestic abuse”<\/p>\n For more on this, take a look at our blogs on taking action once you’ve written your user stories<\/a> – and turning your user stories into a prioritised action plan<\/a>.<\/p>\n You’ve seen a need for your service, which is why you created it \u2014 but ‘need’ isn’t always enough to get people to discover and access your services. We aren’t going to explain how to do this here, that’s a whole other article<\/a>.<\/p>\n However, digital marketing comes with its own jargon: a lot of it is to do with measuring performance. So you might notice \u2014 via analytics tools such as Google Analytics or Matomo<\/a> \u2014 that plenty of people are visiting the Empty Property Finder, but then they leave straight away. If the majority of visitors do this, you have a high bounce rate<\/strong> and will want to take steps to reduce it.<\/p>\n You may even use a tool, such as Hotjar<\/a> or Mouseflow<\/a>, that can create heat maps<\/strong>, which show you things like what buttons are most clicked, and which pages (or parts of a page) people seem to hover on the most. Looking at things like heat maps and bounce rates help you figure out what is and isn’t working in your service.<\/p>\n This brings us to the end of this jargon-busting guide \u2014 there’s just one more key buzzword that we’ve avoided using until now: agile.<\/strong> That’s because the majority of the processes described in this article are all part of the agile methodology<\/a>. Now that you understand agile in context, you can take a deeper dive into our comprehensive Guide To Agile<\/a>. If you’re pressed for time, the key thing to remember about agile is: most people who use it, do not talk about it. Most people who talk about it, do not understand it.<\/p>\n","protected":false},"featured_media":18966,"template":"","meta":{"_acf_changed":false,"inline_featured_image":false},"tags":[],"resource-category":[1973],"class_list":["post-18959","resource","type-resource","status-publish","has-post-thumbnail","hentry","resource-category-working-with-a-digital-agency-freelancer"],"acf":[],"yoast_head":"\nPhase one: product development<\/h2>\n
\n
![\"https:\/\/www.designveloper.com\/wp-content\/uploads\/2019\/12\/1_LixFIhv9HgDFEuCEQTXwJA.jpeg\"](\"https:\/\/promo.cymru\/wp-content\/uploads\/2024\/07\/614cde904bc06142f376b351_1_LixFIhv9HgDFEuCEQTXwJA.jpeg\")
<\/div>\n
![](\"https:\/\/promo.cymru\/wp-content\/uploads\/2024\/07\/614ce092b00473eb7fdbf8c7_Screenshot-2021-09-07-at-11.49.46.png\")
<\/div>Phase two: product deployment<\/h2>\n
![\"https:\/\/images.g2crowd.com\/uploads\/attachment\/file\/41115\/uploads_2F8fdd157e-4df9-4097-acf8-32c1dbec4b16_2FGitHub__.png\"](\"https:\/\/promo.cymru\/wp-content\/uploads\/2024\/07\/614cde8e32a41c69e87c3585_uploads_2F8fdd157e-4df9-4097-acf8-32c1dbec4b16_2FGitHub__.png\")
<\/div>\n
Phase three: marketing<\/h2>\n