Great Products Consulting

Tag: design

  • What is Technical Debt?

    What is Technical Debt?

    As your developers are building your online platform or mobile app, you might acquire something called “technical debt”. There’s a chance that you’ll never be told about it – and you won’t even know what it is, so I wanted to write this article to make you aware of its existence.

    What is technical debt?

    There is no single way to build a platform or app. Like writing an article, people will approach it in different way, and as a result, the final output will achieve the same result but actually look different.

    The choices made during development – either by accident or deliberately – create technical debt. Technical debt is the amount of re-work that you may have to do to your product in the future to get the functionality that you want.

    Why does it happen?

    There are lots of different reasons why technical debt gets created. Here are two that you’re most likely to come across:

    1. Initial decisions related to the overall technical approach
    2. Incomplete or changing requirements

    Both of these can create technical debt that has a great impact on your future plans.

    1. Initial decisions related to the overall technical approach

    Usually, you’ll make a deliberate choice about how you will develop your platform or app.  The overall approach taken can create technical debt.

    For example, one way to build an online platform is to use an existing platform as the basis for your new product. Wordpress is a common approach. Alternatively, you can have a completely customised solution. They may both give you the functionality that you want, but there are pros and cons for each. For mobile apps, the decision is often between using a hybrid platform or building from scratch as a native app.

    This technical decision is often based around money. You want to spend the least amount of money possible to get you to market, so that you can start making money. There are other factors too, but most will boil down to the initial costs and development time.

    2. Incomplete or changing requirements

    Developers can only make technical decisions about what they know right now. If you don’t have a complete picture of what you want, or if you add or change something down the track, then there’s a risk of creating technical debt.

    The developers will craft a technical solutions based on the requirements that you give them. If you’re thorough in defining what you want your product to do, and all of the nuances around it, the developer now has more information to work with.

    Imagine you tell a builder that want a single-storey, two bedroom house – and then halfway through you decide you actually want a 2-storey house. All of a sudden, the builder has to change the way in which the house is built. Some of what has been built may stay the same, but there’s a chance that some stuff may have to be ripped out and re-built.

    What does it mean for you?

    Some technical debt cannot be avoided. You don’t know what you don’t know. That becomes part of the cost of doing business.

    Another part of technical should be a conscious and informed choice that you make. You may choose to go with one option because it gets you to market sooner. This reflects the uncertainty associated with building new products.

    The final part is something that you can avoid. Be clear about what you want. Especially with an agile development methodology, developers focus on what’s immediately ahead of them. It gives you some flexibility to change your mind. However, it creates technical debt. The best case though is for a developer to be aware of what you want from the very beginning. Any re-work is a cost to your business, and it’s money that you could spend elsewhere.

    With your new awareness of technical debt and how it is created, you should now be able to start a conversation with your developer that allows you to make informed and deliberate choices about your future platform or app.

     

    Are you ready to turn your good idea into a great product?
    My idea to launch checklist is your plain-English guide to getting there.
    It’s available now for only $24.
  • What’s the Difference between UI and UX?

    What’s the Difference between UI and UX?

    This article is going to look at the topic of UI and UX. These two similar, but very different terms are often confused, and so I thought I’d take a moment to clarify.  At the heart of it, the difference lies in what each of them aims to accomplish. User interface (UI) is about aesthetics – making the system look good, while user experience (UX) is about a good (or great) customer journey through your platform or app.

    User Interface (UI)

    User interface is specific to what people see on the screen – colours, fonts, and styles. It also related to a persons interactions with objects on the screen, like buttons, links, tabs and scroll bars – the things that people click on or touch to use the system. 

    User experience (UX)

    User experience is all about how the user interacts with your platform or app. How do they complete tasks in a seamless and pleasant way.  It also extends to their whole experience when interacting with your business – from the time they find out about you, to when they buy and beyond. 

    True user experience goes back to the customer’s problems, need or goals. What are they trying to achieve and how does your platform help them to do that? Can your users solve their problems efficiently and effectively? How does your platform or app make it seem easy to solve their problem? At the end of the the day, it’s how they feel about your product.

    Great UI does not always mean great UX

    Icons are a great example for showing the difference between UI and UX. Icons look great from a UI point of view. A little picture to represent a feature or object instead of text. However, they’re not always that great from a UX perspective. 

    Some icons are universally recognised – a garbage can for “trash” or “delete”, or a magnifying glass for “search”. However, if you start creating icons for new functions that people don’t recognise, and they have to learn what that icon means before they know whether they want to use it or not – then you’ve created a bad UX. 

    But there are overlaps too…

    Let’s take a button as an example. 

    In UI, you look at the colour, shape and size of the button. You also determine the font, size and colour of the text,  as well as the location of the button on the screen relative to other elements. Sounds a little like UX doesn’t it? The way the button looks will also make it easy (or difficult) to use. Imagine a button so small that your thumb or finger can’t click on it, or one buried at the bottom of a page amongst some text where you can’t see it. 

    There are some UX pieces to this button as well. When your cursor clicks a button, it might change colour so that the user knows that the button has been clicked. Maybe there’s a tool tip when you hover over it to tell you what clicking the button will do. These UX elements can make your platform or app more user-friendly. 

    Hopefully, you’re starting to see how people can get confused between UI and UX. 

    Why you need to know the difference between UI and UX

    As you look at how to get your product built, you need people with good UI skills as well as good UX skills. Some people have both skills, but some don’t, so you want to understand a person’s capabilities before hiring them. Even if you go through an agency, it’s worth your time to find out how they deal with UI and UX. 

    Bottom line – things may be visually appealing and perform the function intended (good UI), but the user shouldn’t be frustrated because they can’t figure out how to use the function (bad UX). It turns out the two need each other if you want to make a great product, so keep that in mind as you head out on your development journey.

    Are you ready to turn your good idea into a great product?
    My idea to launch checklist is your plain-English guide to getting there.
    It’s available now for only $24.
  • What is a Wireframe?

    What is a Wireframe?

    A wireframe is a drawing of a screen as it might appear on a website, an online platform or a mobile app. Wireframes are very powerful tools for describing what you want to build, and for illustrating your idea. In this article, I’ll explain the different types of wireframes and how you can use them to create your platform or app.

    On the web and on mobile apps, screen design plays a key role in how your customer and users interact with your product. These designs are usually created by user experience (UX) designers; often with the input of graphic designers (some user experience designers have visual design skills as well).

    Wireframes in Product and Software Development

    Traditionally, screens would have been envisaged in the “design” phase of the development process. Developers and designers would sit together to determine how a user will move through the application, and what the screens should look like.  However, screens can play a vital role in explaining what a product should do. As a result, screen designs are edging their way into earlier phases of the software and product development processes.

    As you’re validating your idea during the “analyse” phase of product development, wireframes can used to test your product idea. You show the screens to potential customers so they can understand what you’re trying to do and what the product might look like. The screens can even be linked together so people can ‘navigate’ through a particular feature. The feedback is invaluable in terms of seeing how people interact with your idea.  You can also get their reaction to your solution and whether it solves their problem.

    In terms of defining your product (the “define” phase of product development and the “requirements” phase of software development), wireframes are a great way to illustrate to developers what you want your product to do. In some cases, people get UX designers involved here to get some detailed wireframes outlined before starting development. However, be aware that there’s often a strong dependency between what the screen looks like versus how things work behind the scenes. In some cases, the designed screens may have some technical constraints, so you might have to re-do some of the screens at a later date.

    Types of Wireframes

    Wireframes come in different levels of detail and each one of them has different uses when creating your product:

    1. Low-fidelity wireframes

    These wireframes are hand-drawn and very high-level. They show the overall placement of content on the screen using boxes to represent areas of content, and lines to represent text. These are often used to map out what screens are required, the flow of the screens and the high-level content (e.g. picture, text, button, menu bar, etc). The idea is that you don’t want to spend too much on the detail. You’ll use these “lo-fi” wireframes in the “analyse” and “define” phases as you’re just illustrating concepts.

    2. Medium-fidelity wireframes

    Lo-fi wireframes are converted into computerised images with software tools like Sketch or Balsamiq or even basic drawing tools like PowerPoint. The high-level content is replaced with additional details – such as what type of picture will be displayed, what content will be included (e.g. contact information, user registration), etc.

    3. High-fidelity wireframes

    High-fidelity (“hi-fi”) wireframes often look like graphical representations of the actual screens. User experience designers will provide actual fields on a form (e.g. field labels, field types – calendar, drop downs, radio buttons, etc), general spacing and navigation. Graphical or visual designers will fill in the pictures, colours, font types, logos, styling etc. Items on the screen are annotated to include design and development notes (e.g. click here to go to the home page).

    The diagram below shows the level of detail in different types of wireframes:

    In many cases, people don’t bother with hand-drawing screens, go straight to the computer, and call them lo-fi wireframes. Some people will skip that step altogether, and go straight to hi-fi wireframes. It doesn’t really matter what you do – it’s more a matter of how much time and money you want to spend on it. It’s much quicker to hand-draw something rather than to put it on a computer. If you end up with multiple iterations of your screens or end up with new screens altogether, you spend less time and money doing this when you’re drawing boxes and lines versus very detailed screens.

    It’s important to remember that during “analyse” and “define/requirements” activities, wireframes should be focused on “what” rather than “how”. You don’t want to restrict your developers by telling them “how” you want something done.  Wireframes should be used to show them “what” people should be able to do, and the outcomes or benefits they expect from using your product.

    Why should you care?

    Depending on your budget and skills, you need to determine whether you want to create your wireframes or get someone to do it for you. You may want to draw low- or even medium- fidelity wireframes, and then pass them on to a designer. Alternatively, you may decide that your strengths lie elsewhere, and you hire a designer to do the wireframes from scratch. If it’s the latter, then you’ll still need to provide some guidelines to your designers, and this can be done in your product definition.  This instructs the designer on what the product should do.

    Either way, knowing how to draw wireframes, and understanding the different levels of detail are important skills to have. Pictures are a very powerful communication tool, and can be used throughout the development process to show developers what you want them to do.

    Are you ready to turn your good idea into a great product?
    My idea to launch checklist is your plain-English guide to getting there.
    It’s available now for only $24.
  • Get from “idea to launch” with my new checklist!

    Get from “idea to launch” with my new checklist!

    If you’ve got a great idea for an online platform or mobile app, but you’re not sure where to start – you’re not alone. Tech can be intimidating for those that have never had any experience with it before. Sometimes you want someone to guide you through the process – but you just can’t afford to hire someone to help you.

    The good news is that building an online platform or mobile app is a process.  This means there are clearly defined activities that you can follow to reach your end goal. Once you know this, the whole thing becomes more manageable – you just have to take it one step at a time.      

    Introducing the idea to launch checklist

    Today, I’m pleased to introduce the “idea to launch checklist”. This downloadable checklist contains “must-know” tasks in 15 core areas, so you can turn your good idea into a great product. It provides a plain-English roadmap for your journey. You’ll see the main activities for developing a product, and the tasks involved in each step.

    The idea to launch checklist came about as a way to take non-technical people through the creation of a digital product. Like the design and manufacturing of any product or service, platforms and apps have their own brand of jargon and their own unique complexities.  This checklist needed to be written in a way that anyone could follow.

    I understand that not everyone wants to be an expert in software development. Business owners and working professionals certainly have enough things to do and learn! This checklist has been designed with you in mind. If you’re serious about building your own digital product, then the information in this foundational checklist is definitely in the “need to know” bucket. 

    Did you know that on average only 16.2% of software projects are completed on-time, on-budget and with the features and functions originally requested?

    Having worked on technology projects for almost 20 years, I’ve learnt a lot about software development – to a point where it’s mostly routine and I don’t have to think about what to do. Throw in 8+ years in product management, and there’s all of this experience that I took for granted.

    It made me realise that this lack of knowledge is costing people money.  I’m sure people would learn a lot from their experience, but I think they would prefer not to spend so much money on those lessons!

    As someone that’s been doing this for so many years, I really want to help people avoid this situation. So, I’m sharing my experiences and knowledge with people that have had their “light-bulb” idea, and are ready to do something about it.

    Here’s a taste of what you can expect from my checklist:

    • 21 ways to evaluate your idea. Let’s be real – you need to know if you’re backing the right horse.
    • 20 critical steps to finding the perfect developer. This is not the time for speed dating.  A bad decision will cost you time and money and could even delay your product going to market.
    • Plus 25 tasks that will ensure your product testing is rigorous and effective…. If you’re really going to do this, you want to do it right.

    Think about it – you can’t ride a bike the first time you try it. In fact, before you perfected riding on two-wheels, there’s a good chance you rode a tricycle or had training wheels. You also probably fell a few times.  Maybe you could only make it to the end of the driveway before putting your foot down. Eventually though, you made it to the end of the block and around the park a few times.  

    Building digital products is much the same as this. That’s just the way life is. It often takes a few goes around the block before you’re comfortable with what needs to be done. You can try it with two-wheels for the first time without the training wheels, or you can get some help to make it easier on yourself.

    This foundational checklist is all about action. I want to see you get that platform or app built, and I want you to get there in a straight-line path. So, if you’re ready to build your platform or app, click here to find out more.

  • What’s in a web application?

    What’s in a web application?

    You have an idea for a web application (a.k.a app or platform), but what does that actually look like? If you think about building a house, you have a foundation, a frame, walls, a roof, plumbing and electrical wiring.  All of these things are important to the finished product.  You should think about your application in the same way.  It’s made up of a bunch of different components.  Depending on the type of application, these components will be needed to make your product work.

    Since, I’m always trying to find ways to explain technical concepts to people with non-technical backgrounds, this article is going to take you through the components of your future product.  This will help you to understand what you’re aiming to build. Mobile apps are slightly different, so I’ll look at that in another article.

     Here’s a simplified diagram of your web app:

    As I started to create this diagram, I realised that there were a lot of things we just take for granted. We turn on our phones, open up a web browser, go to a website and it all just works. It’s obviously a little more complicated than that! So, when I say a “simplified” diagram, it really is! For now though, it’ll suit my purpose for explaining some basic concepts to you.

    Some of these explanations may sound obvious, but for the sake of making sure that everyone is on the same page, please bear with me.  

    Device (hardware and software)

    Let’s start at the top of the diagram. The device (your phone or computer) is a physical piece of equipment through which you access your application. This is called “hardware”. When you turn on your phone or your computer, the thing that makes it work is called “software”. Without software, you phone is like a paperweight – it does nothing! The software associated with making the hardware work is called “operating system” (or O/S) software. The individual programs and apps that allow you to do things on your phone or computer (e.g. a web browser) are also called “software” or “applications”.

    Software is a collection of programs that provides instructions to do something and it can be written in many different coding languages. Programs themselves are a collection code used to perform a function. The code uses specific terms and formats to instruct the device on what to do – this is dictated by the coding language chosen. I’ll save a review of different programming languages for a different post as there’s a lot to cover there.

    Front-End

    The “front-end” is composed of all of the things that you see on the screen. It also includes some smarts to help you navigate the app, capture information and trigger activities within your app.

    The level of complexity on your front-end will depend on the types of things that will done via the screens. For example, if you’re just displaying information that never changes, then that’s a lot easier than a page showing search results on a map; where you can zoom in and out on the map, select an object and view information about it.

    Back-End

    The “back-end” refers collectively to the programs and data storage for an application.

    Back-end Programs

    Back-end programs do the heavy lifting – they allow you to do things like store and retrieve information, make decisions, and perform actions by applying logic to information provided by the front-end. Think of it as the engine behind what you end up seeing on a screen when you make a request for something.

     Some examples of back-end programs include:

    • Creating an new user account
    • Validating a login request
    • Retrieving a list of items based on search criteria
    • Calculating values for a report
    • Making a decision on a customer appliction

     As you can see, the back-end is just as important as the front-end. Together, they work with some sort of data storage facility to make your app work.

    Data storage (a.k.a. a database)

    Information that is captured by your app needs to be stored somewhere so that it can later be retrieved, displayed or processed at a later date. This prevents a person from having to re-enter information over and over again. The data held in the database can also be generated by the app itself. This might include things like the date the information was entered or an internal status for a person’s account.

    For web apps, data is usually stored in a centralised database where the information for your app and all of your users is held in a single place.

    There are alternatives to a “database” which is why I have termed this “data storage”. For now, the important thing to know is that data for your app will be stored somewhere and programs will be written to access and update it.

    Application Programming Interface (API)

    So how do the front-end and the back-end talk to each other? This is where APIs come in. An “application programming interface” is a program that allows two applications to talk to each other. Those applications may belong to you or to someone else.  APIs take a request from one application and provide it to another application to process. It also provides the response back to the original application. In your case, this conversation will mostly take place over the Internet.    

    Some APIs are standard – for example if you want to embed a Google map into your app or if you want to add email addresses to a MailChimp list. This allows companies to establish consistent methods for applications wanting to communicate with them. Think of them as a published manual with the available ways to contact an application and the functions you can access. This manual will also tell you how to make the request and the format that is required.

    Other APIs, like your application, may require some customised coding to work. However, for most functions, there’s probably already a template that your developers can start with to achieve the required result.

    Host (hardware and software)

    Your app (front-end, back-end and datastore) has to be loaded onto a piece of hardware to work. Otherwise, they are just letters and numbers on a page. That piece of hardware is called a “server”. It’s a physical device that has the capacity to run programs, manage all of the requests being sent to it, and store data. These machines can range in size and the specifications will depend on the needs of the application and the number of people accessing it. These servers also have software that allow you to monitor their performance and manage the content on them (think uploading and downloading files and programs, and managing security).

    As you can imagine, at the beginning, most of us will not be buying and running our own servers, so we’ll use companies that specialise in this. These companies are called “hosts”. They offer services, called “hosting” that provide the hardware (e.g. servers) and the software to run your app.

    Hosting and choosing a hosting service deserves a whole article of its own, so I’ll leave it at that for now. Basically, to make your web app work and to make it available to people, you’ll need a host.

    What does this mean for you?

    So, there you have it – the components of a simplified web application. It turns out there’s a lot there!

    It’s important that you understand all of these different components so that you have a reference point when a developer starts talking about them. It also helps you to know what you’re actually building.  Finally, you now have an idea of the types of expertise that you’re looking for when putting together your development team.    

    If you have any questions or if something about this isn’t clear, please feel to let me know in the comments below.  

    Do you need some help to make your web application a reality? Send us your details and we’ll set you up with 30-minute discovery session to get you on the right track:

    * When you sign up for a discovery session, we’ll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to this session. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you.To view our privacy policy, click here.