Designing bespoke software solutions isn’t just about colour palettes and branding. A good software design process includes detailed consideration of user journeys, information architecture and page structures.
Bespoke software and design
At Alberon, we take our customers through several key phases during a project to determine the goals of the software, stakeholder requirements, brand values and much more. All these key elements feed into the design of the software system and getting this right before we start building is vital.
Each step requires deliberation, testing and feedback to ensure the application’s design matches the core requirements.
Getting the design of your solution right before you start building will save you a lot of time and money down the line. It is worth asking your developer what steps they have in place to help support this.
The Discovery Phase is a vital period during a project when we identify the key requirements the system might need – from understanding core brand values and colours to establishing key objectives and system requirements.
We work closely with clients during this time to make sure we have a clear understanding of their vision and establish a project plan to achieve their objectives.
1. Discovery Workshop
The Discovery Workshop is designed to outline clear project objectives and to collaborate with clients on various ideas.
You will likely have particular goals you are trying to achieve with the software, whether it’s improving efficiency, saving time or money. Having a clear understanding of these goals allows the project team to prioritise requirements and inform designs.
You may have outlined key points such as core objectives, budget, time considerations and other key information in a brief. This is the point at which we will take your brief a step further and drill down into what you require the software to do. This is not just what fields are required in a database, but security requirements, contact forms, automated instruction emails and more. All of these key details will be used to inform the planning and design of your system.
2. User interviews
To better inform the system’s design, the project team may need to know more about the users and other key stakeholders. Conducting research, such as interviewing users, managers and other members of staff about how they use the current system and their requirements will be useful. Information such as how they want to access the system, what limitations the existing system has and visions of how the system could function will help inform the design and give stakeholders a sense of ownership.
3. Competitor analysis
It is handy to know what you already do and don’t like about other systems. Have you already tried something that didn’t quite work? Why? Perhaps it was juggling too many spreadsheets – in which case integrating systems or planning a system that manages your business from end-to-end may be necessary. Have you seen functionality that you liked in another system that didn’t go quite far enough to match your organisation’s requirements? Getting examples and discussing these options with your developer all help to build a picture of the solution that you want.
Once all the requirements for the project have been established and a plan is in place, it is time to start drafting and executing the plans.
If you require new branding work a design team should take your ideas and help you develop them. This could be done by creating colour palettes with your branding and using mood boards which can include styles of images, icons and infographics.
A design team will also create different types of typography for headers, subheaders, page titles, general text and more. All of this can be presented to you for feedback.
Sitemaps outline and present the architecture of a system. They display menus and drop-down lists and where pages lead to. Having this clear view of the site and all its pages allows a team to discuss the best options for user journeys.
Users need to be able to complete tasks and find the right information on a page within as few clicks as possible. A sitemap allows this to be planned before development is started. Establishing these user journeys will be what makes your application as efficient as possible.
When we present sitemaps back to our clients, we use tools that enable them to comment directly onto the sitemaps to aid discussions and resolutions. This feedback, along with the information presented in the discovery phase, is essential to getting the user experience right.
A wireframe is a basic prototype that a design team can use to map out key pages and link them together. It could even be done for every page if enough time is available. A wireframe could be the first time you see some branding on a page, a general page layout, menu’s, footers and some content.
A wireframe provides a basic visual overview of your system’s pages and how they will work – which you can interact with. You can click on menus and navigate through key pages, seeing how your final system could work. Having a visual picture of your system which you can interact with offers a clearer representation of how it could work. You should offer as much feedback as possible to ensure the design agency and your team have aligned visions and targets of the software.
At Alberon we use wireframes that can be circulated to other stakeholders in your company who can then provide feedback directly onto the wireframe, highlighting questions, or suggestions on what can be improved, changed, added or removed.
You can also see whether the styles, such as typography and menus and layouts suit your requirements and data fields follow the specific order you require etc.
Another option available to see how a system will work before it is built is by having a prototype built. A system prototype provides a full, detailed version of what the system could look like. This can be done for key pages, such as the home admin page, analysis and database.
This option is more costly than a wireframe as it is far more in-depth, but it will provide a very accurate model of how your software system will work. You could even use it to test an idea or system with potential users before fully committing to having it built.
Once all designs, the sitemap and everything else has been signed off with both the project team and client team, it moves into the development phase. The next stage will be creating the application – this does not mean it can’t change after this point, however, it means the bulk of the project can be planned, budgeted accurately and everyone knows what is expected. It is much easier and less costly to make any changes to the design before you get to the sign off stage.
Development & Deploy
Once created, the system will need testing to ensure the designs and usability is accurate. This should be completed by the design team as the project is being completed, as well as the project manager and/or senior development team. This will include everything from ensuring text can be read – passing standard industry tests, as well as structure, menus and linking being accurate for end-users.
Once this is complete, it will be handed over to you for testing and full content upload. This will be the first opportunity for you to see and use the final system as a whole. At this point you should:
- Make sure you fully understand and use the system as an end-user will use it
- Record your progress and ask questions of the team – they might be able to create user guides to aid your team, or even offer training sessions to ensure users can confidently use the system.
Once live, you or other users may have future requirements or unforeseen problems. These should be addressed as soon as possible, so it is important to offer feedback or create a list of future changes or additions.