Designing desktop applications is a fundamental skill for ICT technicians, especially as desktop software remains crucial in many Kenyan workplaces such as banks, hospitals, and county government offices. Effective design ensures that applications meet user needs, are reliable, and maintainable. This chapter explores the requirements and methods for designing desktop applications, equipping ICT technicians with the knowledge to create functional and user-friendly software solutions.

2.1 Desktop Application Design Requirements

Designing a desktop application requires a clear understanding of both technical and user-centred requirements. In Kenya, ICT services support diverse sectors including education and healthcare, so desktop applications must be tailored to local operating environments and user capabilities. This section discusses what constitutes desktop application design and the tools ICT technicians use to create effective designs.

2.1.1 Introduction to desktop application design

Desktop application design involves planning and structuring software that runs on personal computers or workstations, providing specific functionalities to users. Unlike web or mobile apps, desktop applications interact directly with the operating system and hardware, offering rich features and offline capabilities. Example: a county government office may need a desktop application to manage payroll that keeps working when internet connectivity is intermittent, so the design stores data locally and synchronises it later.

Characteristics of desktop application design

• User interface focus: The design must prioritise usability, ensuring that users from various backgrounds, such as clerks in a county office, can navigate the software easily.
• Performance requirements: Applications should be optimised for the hardware specifications found in the target institution, avoiding excessive use of memory and processor time.
• Security considerations: Sensitive data such as patient records at a clinic must be protected through design features such as user authentication and data encryption.
• Compatibility: The software should support the Windows versions installed on the client's computers, for example Windows 10 and Windows 11.
• Maintainability: The design should make updates and bug fixes easy so that the application can adapt to changing user needs or regulatory requirements.

Design goals in the Kenyan context

• Reliability in low-bandwidth environments: Many rural offices experience unstable internet, so desktop applications should function offline wherever possible.
• Localisation: Local languages and formats, such as dates and currency in Ksh, are incorporated to make the application accessible to its users.
• Cost-effectiveness: Efficient design reduces hardware demands, lowering operating costs for institutions such as SACCOs.
• Integration capability: The application should be able to interface with existing databases or systems used by banks or schools.
• User training minimisation: An intuitive design reduces the need for extensive user training, saving time and resources.

Functional and non-functional requirements

Requirements are written before any tool is chosen, because they decide which tool is suitable. They fall into two groups.

• Functional requirements: These describe what the application must do, for example "record a fee payment, print a receipt and update the student's balance".
• Non-functional requirements: These describe how well the application must work, such as speed, security, reliability and ease of use. Example: "the receipt must print within five seconds on the office's existing computer".
• Constraints: These are limits set by the environment, such as the operating system, available hardware, budget and the skills of the support staff.
• User requirements: These capture the needs and abilities of the people who will use the software, such as their language, computer experience and working routine.
• Data requirements: These state what data is stored, how long it is kept, and how it is backed up and protected.

2.1.2 Identifying desktop application design tools

Selecting appropriate design tools is critical for ICT technicians to translate application requirements into workable software. Tool choice depends on the requirements gathered earlier, and also on cost, availability, the skills of the team and compatibility with local infrastructure. Example: a team building a stock-control application for a hotel store must choose a tool that can design the screens, connect to a database and run on the hotel's Windows computers.

2.1.2.1 Types of desktop application design tools

Design tools for desktop applications fall into three broad groups: development environments (IDEs) that let a designer build the interface and code together, prototyping and wireframing tools that sketch the interface before coding starts, and diagramming tools that model the structure and flow of the application. Technicians often use more than one tool in a single project, for example a wireframing tool during discussions with the client and an IDE during implementation.

Usage and maintenance of the design tools:

• Microsoft Visual Studio: Offers a drag-and-drop form designer, strong debugging and integration with Microsoft SQL Server. Regular updates provide security fixes and new features.
• Delphi: Suits rapid development of database applications and the support of older Windows applications. It requires licence renewal and periodic version upgrades.
• Qt Creator: Useful for institutions requiring cross-platform solutions, such as organisations whose computers run different operating systems. It requires familiarity with C++ and regular maintenance of the libraries used.
• Balsamiq: Facilitates early-stage design communication with clients and stakeholders by producing simple sketch-style screens. No complex maintenance is needed.
• Figma: Enables remote collaboration, which is valuable for teams working in different offices. It works best with a stable internet connection.
• draw.io: Used to draw the diagrams that document the design. Diagram files should be saved with the project so that they stay current when the design changes.

2.1.2.2 Criteria for selecting tools

Choosing a tool by habit or fashion often leads to delays and extra cost. A technician compares the available tools against measurable criteria drawn from the project requirements, then selects the one that satisfies the most important criteria. Example: a college wanting a timetable application for Windows laboratories will give high importance to Windows support and ease of learning for its lecturers.

• Project requirements and target platform: The tool must produce applications for the operating systems the client uses. A tool that only builds Windows programs is unsuitable if some users run Linux.
• Cost and licensing: The purchase price, subscription fees and licence renewals must fit the project budget. Free or community editions may be enough for small projects.
• Skills of the team: A tool that uses a language the team already knows reduces training time and errors. Choosing C++ tools for a team that only knows C# slows the project.
• Learning curve and documentation: Good tutorials, manuals and an active user community make problems easier to solve, especially where trainers are few.
• Database and system integration: The tool should connect easily to the database or existing systems the application must use.
• Interface design features: A visual designer, ready-made controls and support for prototyping speed up screen layout and make client approval easier.
• Performance of the finished application: The applications produced must run acceptably on the client's hardware.
• Collaboration and version control: Teams working in different places need tools that share files and track changes.
• Hardware needs of the tool itself: Some IDEs need a lot of memory and disk space, which may not be available on ordinary office computers.
• Support and long-term maintenance: Regular updates, vendor support and a stable future for the tool protect the application after delivery.

A weighted scoring matrix makes the comparison fair. Each criterion is given a weight showing its importance, each tool is rated from 1 (poor) to 5 (excellent), and the weighted score is calculated for each tool.

Example: a school fee-management application for Windows computers is assessed with four criteria. The weights add up to 10, and the ratings below are the team's own judgements.

Weighted score = sum of (weight × rating)

Tool A = (3 × 3) + (3 × 5) + (2 × 5) + (2 × 2)

Tool A = 9 + 15 + 10 + 4 = 38

Tool B = (3 × 4) + (3 × 2) + (2 × 3) + (2 × 5)

Tool B = 12 + 6 + 6 + 10 = 34

Tool A scores 38 against 34 for Tool B, so Tool A is chosen because the team's skills and database support matter more to this project than cross-platform support.

2.1.2.3 Case studies of tool selection in real-world desktop application

The following illustrative scenarios show how the criteria lead to different tool choices in different workplaces. They are typical situations used for learning and do not describe particular organisations.

• Fee management for a secondary school: The school uses Windows computers only, and its ICT technician already programs in C#. Visual Studio is selected because it matches the team's skills, builds the forms quickly and connects easily to a SQL Server database holding student records.
• Stock and sales application for a pharmacy chain: The business already has an older database and a developer experienced in Pascal. Delphi is selected because it connects strongly to databases and lets the developer extend the existing system without learning a new language.
• Field-office reporting tool for an NGO: Some offices use Windows laptops and others use Linux. Qt Creator is selected because one C++ code base can be compiled for both systems, avoiding two separate projects.
• Booking application for a restaurant and guest house: The owner is not technical and keeps changing the screen requirements. The developer first draws wireframes in Balsamiq and reviews them with the owner, and only then builds the final screens in an IDE. This avoids costly rework after coding.
• Application designed by a team in different offices: The designers and the client's staff work from separate locations. Figma is selected for sharing and commenting on interface designs, with a note that a reliable internet connection is needed during design sessions.

Lessons from these scenarios: the best tool is the one that fits the platform, the budget, the team's skills and the way the client works, not the one with the most features. A technician records the reasons for the choice in the project documentation so that future maintainers understand it.

Chapter Summary

This chapter explored the essential requirements for designing effective desktop applications, beginning with an overview of desktop application design and the identification of appropriate design tools. Various types of design tools were examined alongside criteria for selecting the most suitable ones, supported by case studies demonstrating real-world tool selection. The discussion then shifted to key design methods, highlighting user-centred design, visual design, interaction design, as well as wireframing and prototyping techniques that enhance usability and functionality. A significant focus was placed on the visual hierarchy within desktop applications, emphasizing its importance in guiding user attention and improving the overall experience. The principles underpinning visual hierarchy were detailed, including the role of graphical user interfaces, the arrangement and prioritization of elements, typography choices, colour usage, and the strategic use of spacing and layout. Together, these components form a comprehensive framework for creating desktop applications that are both visually appealing and user-friendly.