Though often used during the development of a new software system to aid in analysis and planning, data flow diagrams give unparalleled insight into every instance where data is potentially vulnerable.

Anatomy of a Data Flow Diagram

Data flow diagrams visually detail data inputs, data outputs, storage points, and the routes between each destination.

Components of a Data Flow Diagram

• Entities – Show the source and destination for the data. They are generally represented by a rectangle.
• Process – The tasks performed on the data is referred to as a process. Circles in a data flow diagram indicate a process.
• Data Storage – Data is generally stored in databases, which are seen in data flow diagrams inside a rectangle with the smaller sides missing.
• Data Flow – Displays the movement of data with the help of lines and arrows.

Also read: Unifying Data Management with Data Fabrics

Logical Vs. Physical Data Flow Diagrams

There are two primary types of data flow diagrams, each with a specific function and designed to inform a different target audience.

Logical data flow diagrams

Logical data flow diagrams illustrate how data flows in a system, with a focus on the business processes and workflows. With a focus on how the business operates at a high level, logical data flow diagrams are a great starting point, providing the outline needed to create more detailed physical data flow diagrams.

Benefits of logical data flow diagrams:

• Provide an overview of business information with a focus on business activities
• Less complex and faster to develop
• Less subject to change because business functions and workflows are normally stable processes
• Easier to understand for end-users and non-technical stakeholders
• Identify redundancies and bottlenecks

Physical data flow diagrams

Physical data flow diagrams provide detailed implementation information. They may reference current systems and how they operate, or may project the desired end-state of a proposed system to be implemented.

Physical data flow diagrams offer a number of benefits:

• Sequences of activities can be identified
• All steps for processing data can be described
• Show controls or validating input data
• Outline all points where data is accessed, updated, retrieved, and backed up
• Identify which processes are manual, and which are automated
• Provide detailed filenames, report names, and database field names
• Lists all software and hardware participating in the flow of data, including any security-related appliances

Also read: Top Data Quality Tools & Software

Strategies For Developing Data Flow Diagrams

Avoid feeling overwhelmed by the creation of a data flow diagram by following a few simple strategies.

• Begin with lists of all business activities, vendors, ancillary systems, and data stores that need to be included.
• Take each list and identify the data elements needed, received, or generated.
• Always include steps that initiate changes to data or require decisions be made, but avoid creating a flowchart (for example, identify that the user needs to accept or reject an incoming order or reservation, but don’t break it down by ‘if yes, then’ and ‘if no, then’).
• For complex systems, it may be helpful to start by adding data stores to the diagram and working outward to each of the processes involved – it is likely that single data inputs are used or accessed repeatedly.
• Ensure that there are no freestanding activities – only include processes that have at least one data flow in or out.
• Review labels to be sure they are concise but meaningful.
• Try to limit each data flow diagram to a maximum of 5-7 processes, creating child diagrams where appropriate or required.
• Consider numbering the processes to make the diagram easier to review and understand.
• A successful data flow diagram can be understood by anyone, without the need for prior knowledge of the included processes.

Using A Data Flow Diagram To Mitigate Security Threats

The best way to protect data from security threats is to be proactive instead of reactive.

Data flow diagrams can support cybersecurity initiatives in many ways:

• Identify when data is at rest and in transit.
• Visualize when data is shared with external vendor systems.
• Know which users and systems have access to which data, at which time.
• Enable the notification of affected users, systems, and vendors in the event of a security breach or threat.
• Understand the schedule of automated processes to know when data is being offloaded or consumed.

To best support the mitigation of security threats, data flow diagrams should include all risk assessments (corporate governance, external vendors and ancillary systems, and key business processes), complete inventory listings (hardware and software systems), and all user roles that have and require access to data at every point.

For targeted threat modeling, it may be helpful to create additional data flow diagrams to support a specific use case. One example would be a diagram that looks at authentication separate and apart from the workflows and processes that access will be granted to.

Comprehensive data flow diagrams ultimately show where the systems make data vulnerable. Threat modeling best practices generally consider data safest when at rest, so look to points in data flow diagrams where data is sent or received to ensure security and integrity are maintained.

A Living Part of System Documentation

Don’t forget that data may move through systems and processes in non-technical ways as well. Paper-based or non-technical business processes where information is gathered or stored should also be included in data flow diagrams.

Data flow diagrams should become a living part of system documentation and be thought of as a source of truth. As systems and processes are updated, it’s important that the consequences to data flow or data integrity are considered and reflected in any existing diagrams.

Read next: Best Data Governance Tools & Software

The post Identify Where Your Information Is Vulnerable Using Data Flow Diagrams appeared first on IT Business Edge.

Here are the essential elements to include in a business requirements document, plus best practices and scope limitations and considerations.

Also read: Best IT Project Management Tools & Software

Key Elements of a Business Requirements Document

Here are 10 elements to include in a business requirements document that will help assure your team’s success.

Versioning

A business requirements document is a living thing. It is created before a project starts, can change frequently, and may still be edited once everything else is finished.

Because the business requirements document will be referenced time and again, it’s important that all changes are noted within reason. If requirements or dates change, record it; if you fixed a typo, let it slide.

Summary statement

Even though the summary statement tends to appear first in a business requirements document, it’s recommended to be written last. It’s a high-level statement that should outline the project requirements and summarize the rest of the document.

Project objectives

Outline the project goals and objectives, detailing what the work will accomplish. If the project supports business processes or workflows, it should be described here.

Objectives should always be SMART—specific, measurable, attainable, realistic, and time-bound.

Needs statement

The needs statement is intended to be persuasive. It’s the reason for the project. Think of the needs statement as a justification meant to sell stakeholders on the idea and to motivate the project team.

Project scope

Detailing the project scope will help set boundaries for the work to be completed. Depending on your project, goals, team, and environment, it can sometimes be easier to identify items or modules that won’t be updated or included in the project scope instead of defining all the things that are.

Stakeholders

Identify all the stakeholders involved, including their positions. It is helpful to list their position within the organizations involved, but also their roles and responsibilities as they pertain to the current project.

Financial statement and cost-benefit analysis

Not to be thought of as a budget, the financial information included in a business requirements document is intended to indicate the impact of the project on a company’s balance sheet.

Funding sources should be identified here, but don’t forget that any person or organization contributing may also qualify as a stakeholder and should be included in both sections.

Schedule, timeline, and milestones

Depending on the project size, information for the schedule, timeline, and milestones may be combined into a single section or separated out into their own. It’s important to clearly identify expectations and deadlines, being sure to include decision points as well as moments when work needs to be completed.

Track any and all activities, including when you need to have sign-off on project deliverables, when outside vendors need to be engaged, and when hardware has to be in place.

For long-term projects, identifying clear milestones allows the ideal opportunity for interim billing, so vendors and contractors can be paid.

Functional requirements

Functional requirements make up the real bulk of a good business requirements document. The more detailed the requirements, the better the outcome.

Be sure to use clear, concise language free of jargon or slang. Avoid acronyms, even if they feel common. And when possible, add visual elements like screenshots, prototypes, and mock-ups. It’s a great idea to compare current state to future state when business processes or workflows are changing.

Where it makes sense, break large sections into smaller, more accessible pieces. And if requirements are optional or subject to other dependencies, break them down by must have, should have, and nice to have.

Non-functional requirements

Document any reporting, analytics, and integration requirements in this section. Be mindful that some activities, such as security scans, may necessitate revisiting other sections of the business requirements document, and time should be budgeted for accordingly.

Also read: How Project Management Software Increases IT Efficiency

Business Requirements Document Best Practices

There are a number of best practices that can ensure your document – and project – will be a success. Here are 8 to consider as you plan your project.

• Get input and perspective. Subject your business requirements document to peer review.
• Set reasonable deadlines. Double and triple check dates and deadlines to be sure they are achievable—it’s better to estimate high and deliver early than have projects fall behind.
• Include time for research. If contractors or vendors need to be engaged, be certain the time and costs of doing so are included. If researching a needed vendor or third-party product is a part of the project, identify it as a risk to mitigate in case an appropriate solution isn’t found, takes longer than expected, or exceeds the budget allowance.
• Be aware of regulatory requirements. Don’t forget to account for any regulations or legislation that may impact the project.
• Detail needed technology. Include details on the tools and technology that will be used and employed.
• Plan for ongoing support. If your project will require ongoing maintenance and support after implementation, specify a support plan, and list the activities and individuals involved.
• Leave time for documentation. Remember that documentation should be a part of any project. Activities should be included with time allotted to complete documentation and training materials.
• Be flexible. Stay open to identifying and evolving functional requirements, but remain aware of how changes may impact other activities, timelines, or deadlines.

Limitations of Business Requirements Documents

Despite being a source of truth and trusted advisor for a project, business requirements documents do have their limitations. Here are some of the limitations of the document’s scope and how to navigate around them.

• You don’t always need to know how something gets done. Functional requirements should answer questions of what and why but not how. Though the distinction may feel subtle, knowing how a developer will accomplish a particular task is outside the scope of these documents.
• Don’t leave questions unanswered. Business requirements documents should always answer questions, not ask them. If there are questions to be asked, or unknowns to research, do so during the creation of the document, and include the results instead.
• Include all background and details. Each business requirement document should stand alone. Assume that everybody reading it has no idea what has happened in past projects. If there are details that need to be included to offer context, include them, but be sure they are relevant and necessary.
• Plan for delays. Though few business requirements documents include a risk mitigation section, it’s wise to find ways to identify areas where timelines or activities could be impacted and in what way. A rule of thumb is to add a 20% time buffer to manage uncertainties, but adjust this as needed and appropriate.

Business Requirements Documents Inspire Teamwork

When done with care and consideration, a business requirements document fosters trust and transparency among project teams and collaborators. Communications are improved, there are fewer errors and mistakes, ambiguities and uncertainties are reduced or eliminated, and outcomes can be all but guaranteed.

Read next: Choosing Between the Two Approaches to Project Management

The post Tips for Writing the Perfect Business Requirements Document appeared first on IT Business Edge.

Therefore, stakeholders need to learn how to motivate their development teams to encourage both personal and professional development without driving them toward burnout. In the age of the Great Resignation, it’s more important than ever to keep key employees content.

Also read: How to Choose a Software Development Methodology: 6 Approaches

4 Tips for Communicating with Your Dev Team

Communication with your developers involves creating a mutual understanding based on empathy and respect. Just as with any new employee, it’s important to learn how each member of your development team best communicates.

Fortunately, there are a few ways to bridge the communication gap between developers and stakeholders (or anyone else for that matter).

1. Share your expertise without condescension

While some developers may have industry-related experience or education, most come to the team armed only with the requisite technical expertise. Let them know the areas of your business most affected by technology. Explain workflows and business processes in plain but logical terms.

2. Ask for translations

When developers start using words, phrases, or concepts that are confusing to you, ask what they mean. Don’t wait until days or weeks later. Many developers tend to focus on the work being done at that moment, and having context can make it much easier to explain what is meant, both for better communication and to avoid wasting precious dev time.

3. Know what you need to know

While there are times that it’s important to know all the details, it’s not always necessary to know exactly how development is done at a granular level. What matters is that the work gets done according to the specifications provided.

If there are specifics that need to be known, be sure to let developers know ahead of time that they should record the given details and be prepared to share that information.

4. Ask instead of making assumptions

When troubleshooting an issue, it’s not uncommon that developers can’t replicate the error. Rather than assume they don’t believe the error is occurring, be sure to ask how they would like to approach the issue. For example, would they rather receive end-user screenshots of the error, or would they rather shadow the user to see the process being followed?

If you want the developer to fix the issue, let them take the lead and tell you what resources they require to best do that.

Also read: Identifying Software Requirements Using 5 Whys and 5 Hows

5 Tips For Retaining Developers

We covered communications, which can be no small challenge when working with a highly technical team, but that’s only part of the challenge. These next two sections will deal with retaining your dev talent – and keeping them from burning out.

1. Set clear and measurable goals in cooperation with developers

Feel free to set deadlines, but always treat these as collaborative tasks. Projects can be affected by unforeseen events, scope creep, and other external factors. Encourage developers to speak up when something happens that could impact a previously set deadline, and be prepared to ask questions to see what may get things back on track.

2. Provide the support developers actually ask for

Nothing is more frustrating than being given help that doesn’t actually help. Empower developers to ask for the support they need, and listen to their requests.

Hiring extra developers when what’s really needed is training won’t make the project move faster. But, if slow hardware is guilty of stalling development efforts, it won’t matter how much training your team has.

3. Give developers power over their own environments

Every employee is different and has different needs. Moreover, the research varies, but it’s commonly understood that refocusing after being distracted can take 20–30 minutes.

Therefore, you should work together with your developers to design an environment that helps to relieve some of the pressures to be innovative, creative, and productive while supporting your business goals.

4. Provide recognition

Everyone loves to feel appreciated, and developers are no different. Consider ways to celebrate or recognize your developers when they work long hours or put in extra effort to reach project milestones. However, be sure to communicate with your developers their recognition preferences—some may be more receptive to private recognition versus public.

5. Don’t micromanage

It can be hard for non-technical team members to understand, but sometimes developers can go days without producing demonstrable results, but that doesn’t mean they haven’t been productive.

It’s okay to ask whether tasks are on track, but avoid making these check-in points spontaneous or too frequent. This can result in reduced productivity since developers will be spending this time defending their progress rather than working toward project milestones.

See also: Using Whiteboards to Streamline Development Team Collaboration

6 Tips for Preventing Developer Burnout

Writing code can be very stressful and demanding work. As such, developers can face overwhelming mental fatigue, putting them at higher risk for burnout.

Support developers and their mental health with these six suggestions for preventing developer burnout:

• Encourage vacations, even when timelines are tight: Being able to clear the mind can be just what is needed for a fresh perspective.
• Provide flexible scheduling: Development work can often rely on inspiration, which doesn’t always happen in an 8-hour, 9–5, workday. Forcing developers to knock off at 5 p.m. and remember what they were doing at 8 a.m. the next morning isn’t always realistic, so be understanding if, for instance, developers are on a roll and choose to work a 10-hour day followed by a shorter day.
• Destigmatize asking for help: Speaking up about signs of burnout should never be met with shaming or suggestions that it is due to personal failure.
• Clearly define team hierarchy, roles, and responsibilities: Don’t make it an exhausting task to get sign-off for completed items. Make it easy to know who will answer specification or requirement questions.
• Allow remote work: Give developers the option to work remotely, even if it isn’t 100% of the time.
• Break large projects into smaller modules: Sometimes being able to celebrate milestones, recognize progress, and move on renews energy and enthusiasm.

Also read: 10 User-Centered Software Design Mistakes to Avoid

Make Your Developers Feel Valued

It doesn’t matter how many clients you gain, how many ideas you brainstorm, or how much analysis you perform if you don’t have the developer talent to bring each project to life. Build teams that understand and accept everyone’s strengths and weaknesses, and take the time to mention and celebrate successes. Agile development and DevOps require the management skills to help your team navigate all obstacles, personal and team-related.

Sometimes a task as simple as taking notes when having discussions with developers or learning their acronyms and phrases can go a long way toward making them feel heard.

Happy employees are more productive and perform at a higher level, and they are more likely to stay with the company as it grows.

Read next: Using Swim Lane Diagrams to Improve Software Development

The post Motivating and Retaining Your Development Team appeared first on IT Business Edge.

Software Development Life Cycle (SDLC) Overview

The SDLC is a methodology with clearly defined processes that support the creation and upgrading of software applications.

The modern SDLC contains seven stages:

1. Planning: This is where the ideas flow and the excitement begins. Teams define problems, brainstorm solutions, and start to think of their development objectives.
2. Requirements Gathering and Analysis: In the second stage, teams define requirements and determine the specific details for the new development. It’s important to consider the needs of end users, integration with existing and ancillary systems, and need-to-have versus nice-to-have features.
3. Design and prototyping: Using tools like process diagrams and prototypes, development teams work to create the kinds of plans that will kick off and fuel the development phase.
4. Development: In this phase, code is written, and the software application takes shape.
5. Testing: This phase involves activities such as looking for bugs, finding defects, and learning about shortfalls.
6. Implementation and integration: Often thought of as the final phase of the SDLC, implementation and integration involves a number of tasks that take place as a new or updated software application moves to a live production environment. In addition, user training plans are executed and hardware is installed.
7. Operations and maintenance: After a software application makes the move to production, ongoing operations and maintenance begins. This involves ensuring end users are well-supported as well as identifying the need for patches and updates, which can be a catalyst that starts the SDLC all over again.

Also read: Steps to Conducting a Software Usability Test

Four Types of Software Maintenance

Corrective

Corrective software maintenance is the process that keeps an application up and running. Corrections are most often identified by end users and relate to the design, logic, or code.

Adaptive

Changes to your environment can have an impact on the software applications that run within it. This may be related to hardware updates, operating system updates, or changes to infrastructure. Environmental changes can also include vendor changes, connections to new or existing ancillary systems, or even policy related to security or industry compliance.

Perfective

Perfective software maintenance changes are typically evolutionary. As end users get to work with a software application, they start to create wish lists with new features. In some cases, removing unnecessary or redundant features is also a function of perfective software maintenance.

Preventative

Preventive software maintenance is similar to a technical bandage. It involves smaller, incremental, changes necessary to adapt software applications, so they can work for a longer period of time.

Also read: Using Swim Lane Diagrams to Improve Software Development

Best Practices: Transferring a Project From Development to Maintenance Teams

Transferring a project from a development team to a maintenance team can be complex and challenging, no matter the size. Fortunately, there are a few best practices that should be followed for all transitions.

Identify team leaders

Leaders from the project team, which may include development leads, business analysts, and other stakeholders, should be identified and kept in touch with maintenance team leaders. Knowing who to look to for decisions and guidance can help mitigate risk and ensure a smooth transition.

Team leaders should discuss whether the new software application will impact or change the existing SLAs (service level agreements).

Budget for the transition

Don’t forget to include transitioning from development to maintenance in your project budget. This process shouldn’t be rushed or an afterthought. Be sure stakeholders understand the importance of a proper support plan.

This budget may also include the need to add additional support staff that will be needed post-implementation.

Start Early

Avoid the drop-and-run approach to transitioning projects from development to maintenance. Allow maintenance teams to shadow development teams long before things are complete, include maintenance teams in meetings and relevant correspondence, and update everyone on important decisions.

By including maintenance team members early on, development teams will also have the opportunity to better understand the current state of existing architecture and current software applications being used by an organization.

Communication

Don’t forget the maintenance team may not understand why decisions were made, priorities were defined, or how needs were identified. By communicating these types of details, maintenance teams can better support the software application as well as have empathy and ownership when they need to respond to future questions from end users.

Documentation

Documentation is a critical part of the support process. Skilled technology professionals learn to intuit the details that should be documented to help guide support tasks later on. Think about end users that may look for justifications for the way features or functionality were implemented, and consider the reasons why decisions were made.

A secondary benefit of thorough documentation will be felt with future development efforts. Don’t assume updates or bug fixes will always be done by the same developers.

Documentation elements to include:

• Overview
• References
• Assumptions
• Contacts
• Agreements and licensing
• Diagrams and prototypes with functional and feature lists and summaries
• Configuration details, such as directory structure and administrative functions
• Operational details like start up, shut down, backup, recovery, and archiving
• Security details

Knowledge transfer

Documentation alone isn’t enough, though it is a part of the knowledge transfer process. The trick is to understand and respect the roles of everybody on each team, knowing each has subject matter expertise that may not be known by the other.

Encourage questions and ongoing conversations. There may be things the others haven’t thought of or third-party systems that may unknowingly impact or be impacted by a proposed implementation.

Both teams are important

Neither team is lesser than. Having respect for the work done by each team will help to see the value in the service each provides.

Overlap

Whenever possible, be sure the transition process includes time in the schedule for a little overlap. As support requests start to filter in, it can be helpful to have a resource the maintenance team can call on to get advice and assistance.

That said, be sure the time period for this service is clearly defined and communicated. Having a clear line drawn assists with feelings of ownership and allows both teams to properly move forward.

Learn From Each Transition

Even though every software development project is different, with varying scope and complexity, the transition process can be standardized and learned from. Maintenance teams should conduct post-implementation and transition meetings to discuss lessons learned and solidify best practices.

Document the questions you wish you had asked and timeframes you wish you had designed differently, and bring this knowledge and experience forward to the next transition.

Read next: How to Choose a Software Development Methodology: 6 Approaches

The post Guide to Transitioning From Software Development to Maintenance appeared first on IT Business Edge.

Whether a team uses whiteboards to brainstorm, demonstrate an answer, diagram a solution, or talk through complexities with requirements, whiteboards can be a valuable collaboration tool.

Understanding Whiteboards

Simply stated, whiteboards are visualization tools. Content added to a whiteboard can be as permanent or temporary as each situation requires.

Online whiteboards bring this process to a digital space, providing the opportunity for collaboration amongst team members that don’t share the same physical space as well as providing shared documentation that can be more easily accessed for future use.

In addition, whiteboards are intended to be organic, inviting users to participate in content creation and the resulting discussion. Other functions of whiteboards include the ability to:

• Brainstorm, explore, and share ideas.
• Solve problems, strategize, and perform analysis tasks.
• Create high-level design diagrams to walk users through functionality or proposed solutions.
• Plan projects and resources.
• Teach and learn new concepts.
• Plan sprints and group tasks.

Whiteboard Coding

In the development process, it can be helpful to temporarily abandon the constraints of an IDE (integrated development environment) and think through the necessary logic required. Taking a step back from strict syntax and formatting can offer fresh inspiration on how to tackle the next stages of development.

In more complex situations, illustrating the situation can make it easier to solicit feedback or advice, particularly from team members who may be familiar with the project but are not also developers.

Whiteboards should supplement and support development efforts, and care should be taken to ensure they don’t negatively impact productivity. Whiteboards aren’t intended to be a primary coding method. 

Also read: The Importance of Usability in Software Design

Common Whiteboard Application Features

Whiteboard applications share a number of features, including:

• Taking the form of a native application (desktop or mobile) or being browser-based.
• Unlike physical whiteboards, space isn’t limited and can scale as needed.
• Depending on the device being used, content can be added using a keyboard, mouse, digital pen, stylus, or fingertip.
• Whiteboards can include shapes, pictures, images, and other interactive media content.
• Participants are able to select, move, resize, edit, and delete content.
• Voting sessions allow participants to decide on the importance and priority of various ideas, features, or functionality.
• Commenting allows contributors to provide feedback, introduce additional questions or considerations, or to encourage additional discussion.

Also read: Using Swim Lane Diagrams to Improve Software Development

Top 5 Whiteboard Applications

There are a large number of whiteboard applications available, but five stand out as the top choices.

Note that the costs included below may not be inclusive of the price for applications needed by mobile or desktop devices when not accessing the whiteboard using a web browser. 

Miro

Pros:

• Miro includes several useful templates to get you started.
• The versatile user interface (UI) allows organizations to customize their whiteboards to best suit their processes, workflows, and objectives.
• Hand-written notes can easily be integrated into your whiteboards.

Cons:

• With the considerable number of features and functionality offered by Miro, the UI can feel cluttered and confusing to new users.
• Administrative functions such as moving boards between teams can be difficult.
• Large boards can be slow to load to the viewer’s screen.

Platform Compatibility: 

• Miro is compatible with Mac, Windows, iOS, and Android.

Cost:

• Basic plans are free.
• Team features are available with plans starting at $16 per user, per month.
• Enterprise plans are available with custom pricing and include enterprise-grade security and compliance, centralized account management, and additional data governance functionality.
• Plans paid annually receive a 20% discount.

Microsoft Whiteboard

Pros:

• The familiar Microsoft layout and interface design reduces the learning curve.
• The ability to easily embed other Office documents and work seamlessly within Teams makes Microsoft Whiteboard ideal for organizations using the whole 365 ecosystem.
• The pen experience within Microsoft Whiteboard is applauded as being the most like an actual pen.
• The artifact is not lost when a whiteboard is shared, making it easy to go back and make revisions or additions.

Cons:

• Microsoft Whiteboard often tries to turn ink into computer text, which isn’t always ideal.
• For organizations with users accessing whiteboards using a variety of endpoints and platforms, Microsoft Whiteboard doesn’t always provide an equivalent experience for everyone.
• There is a lack of useful connectors for products like Visio.

Platform Compatibility:

• Microsoft Whiteboard is compatible with Windows, iOS, and Android.

Cost:

• Microsoft Whiteboard is free with a Microsoft account, and additional functionality is available with a Microsoft 365 subscription.

MURAL

Pros:

• MURAL integrates easily with the software already being used by your organization, including Teams, Asana, Azure AD, Adobe Creative Cloud Library, and more.
• Users can easily work with collaborators in real time or asynchronously.
• Projects can be started using templates.
• Interactive elements allow for things like summoning collaborators back after a break.

Cons:

• The visual interface tends to lag when larger numbers of users are making modifications simultaneously.
• Private boards require premium plan subscriptions.

Platform Compatibility:

• MURAL is compatible with Mac, Windows, iOS, and Android.

Cost:

• The Free plan is best for organizations only needing a maximum of 3 whiteboards.
• Unlimited whiteboard plans with additional privacy controls for teams are available for $9.99 per user, per month.
• Business plans with SSO and advanced integrations (Jira and GitHub) are available for $17.99 per user, per month.
• Enterprise plans with centralized administration and enhanced security are available with custom pricing.

Explain Everything

Pros:

• Explain Everything is celebrated for piecing whiteboard content together into explainer videos, making it ideal to use as an educational tool.
• Whiteboards are designed to be more of a teacher-student classroom-style collaboration tool, with built-in functionality for guiding others through lessons or content.

Cons:

• The drawing features are not as sophisticated as those found in competing whiteboard applications.
• While the user interface makes easy tasks very easy, more complex tasks are almost impossibly difficult.

Platform Compatibility:

• Explain Everything is compatible with Mac, Windows, iOS, and Android.

Cost:

• The basic single-user plan is free, and team plans begin at $11.99 per user, per month.
• Education plans are also available for students, teachers, and other educators.

Zoom

Pros:

• The whiteboards are available to all Zoom users who are already engaged in a familiar, collaborative, online meeting application.
• Finished whiteboards can be saved as images and shared.

Cons:

• Whiteboards can only be initiated by the meeting host, who can then transfer the sharing rights to other participants.
• The function is only intended for brief collaboration sessions during Zoom meetings and not ongoing, long-term whiteboarding.

Platform Compatibility:

• Zoom is compatible with Mac, Windows, iOS, Android, and Linux.

Cost:

• The cost for whiteboard functionality is included with Zoom membership pricing.

Tips for Using Whiteboard Applications

There are as many ways to use a whiteboard as there are items pinned to your tried-and-true bulletin board. That said, there are a few best practice tips and tricks that should be considered. 

• Practice makes perfect. Feeling empowered and free to contribute to a whiteboard is an expertise that takes time to develop.
• Give your content meaning. If you want something to stand out, write it in red. If you want to show the flow of a process or idea, use an indicative arrow. Taking some time to standardize your whiteboarding strategy will pay off with more meaningful and easier to understand whiteboards.
• Make good use of space. Knowing users may be accessing and contributing to your whiteboards using a variety of devices and endpoints, means screen sizes and resolutions can vary tremendously. Make choices regarding font and shape size carefully, and try to minimize the need to scroll for the most important information.
• Brainstorm first, edit later.

Turning Ideas into Tasks

There are reasons why so many offices have physical whiteboards hanging on the walls, usually covered in sketches and jot notes that are tied together with lines and arrows, sometimes circled, often with question marks or additional notes added on later. They may even have a sticky note or two. 

Unfortunately, these physical whiteboards have limitations. Even when you disregard their need for members to be in the same location, content isn’t dynamic. You can’t add screenshots, images, or other multimedia. Everything must be recreated or described. Plus, it can be difficult enough to organize our own thoughts, let alone share them in a clear and meaningful way with others.

By contrast, whiteboard applications are always accessible, living things. We can ask questions and see how they get sketched out. We can send our creations to peers and experts for advice or suggestions. We can make note of things to remember or add reference points for later consideration.

Whiteboards don’t have the permanence of documentation. They don’t need to be beautifully formatted or proofread. They often come with the understanding that they may not even be technically accurate or current. They are collaborative tools, allowing teams to think out loud together in a functional way.

Read next: Identifying Software Requirements Using 5 Whys and 5 Hows

The post Using Whiteboards to Streamline Development Team Collaboration appeared first on IT Business Edge.

These two sets of questions can also assist with eliciting the right software requirements by drilling down to identify needed and necessary functionality.

Also read: How to Choose a Software Development Methodology: 6 Approaches

Understanding How To Use the 5 Whys and 5 Hows

The trick with these techniques is to keep the questions simple and avoid influencing the answers. In almost all cases, the stakeholders or users you are speaking with will learn as much as you do.

Don’t be concerned if you need more than 5 questions to get to the answers you need; you may also be able to get there with fewer questions.

Using 5 Whys: An Example

As you might expect, the concept is simple: repeatedly ask the question, Why? until you get to the real root of the issue. As you get answers, try parroting them back in each iteration.

As an example:

1. Business Analyst: Why have you requested an update to your client invoicing software application?

Stakeholder: Because it is taking too long for clients to receive invoices for work we have completed.

2. Business Analyst: Why is it taking too long for clients to receive invoices for the work you have completed?

Stakeholder: Because timesheets aren’t being approved on time.

3. Business Analyst: Why aren’t timesheets being approved on time?

Stakeholder: Because HR managers aren’t receiving them from employees on time.

4. Business Analyst: Why aren’t HR managers receiving timesheets from employees on time?

Stakeholder: Because all timesheets are currently being entered by a single clerk in our office.

5. Business Analyst: Why are all timesheets currently being entered by a single clerk in your office?

Stakeholder: Because the current method of submitting timesheets is non-standardized and a primarily manual process.

What we learned through these five questions is that we can likely improve or solve the problem being faced by our stakeholder by automating timesheet entry and approval functionality. Don’t forget that this is often a cyclical process and can be repeated as often as is necessary. Extending this example, you may want to dive deeper into how you could standardize the current processes, looking into finer details such as deadlines.

Though not detailed enough on their own, keep phrases in mind like: Why is this important? Why would this help? Why haven’t you already done this? Why is it done this way?

Using 5 Hows: An Example

Sometimes the need for 5 Hows follows 5 Whys, but not always. It can also be helpful to determine how to proceed in a given situation, or how to problem solve and find solutions to IT-related issues.

As an example:

1. Business Analyst: How did the software application become unavailable?

Stakeholder: We were the victims of a malware attack.

2. Business Analyst: How did you become the victim of a malware attack?

Stakeholder: We haven’t implemented any security monitoring processes or solutions.

3. Business Analyst: How is it possible that you have not implemented any security monitoring processes or solutions?

Stakeholder: We haven’t had the budget approved for procuring the necessary technology.

4. Business Analyst: How do you proceed with getting the budget approval for the necessary technology?

Stakeholder: We need to hire for the security manager position.

5. Business Analyst: How do you hire for the security manager position?

Stakeholder: We need to discuss the impact of this recent malware attack with our executive team.

In this case, we were able to determine that the stakeholder is already aware of the issue, but they hadn’t clearly mapped the path to a solution. This may not be the end of your interrogation, but it’s delivered the first necessary answers. Don’t be afraid to start broad and vague with your 5 Hows, using future iterations as a means to determine priorities, set deadlines, define scope, or to see if smaller improvements could make a difference.

Also read: Using Swim Lane Diagrams to Improve Software Development

A Judgment-Free Process

It’s important that any facilitator asking why and how questions doesn’t make participants feel they are being judged. The goal is to dig deeper, learn more, and understand better.

Try to avoid getting frustrated. Stakeholders often don’t know exactly what they need, or what would alleviate their pain points. Show appreciation for all answers given during an interview and consider rephrasing or restating questions that may have been misunderstood.

Your job is to better understand a situation or test out your ideas for solutions. Don’t make assumptions. 

The Three-Legged 5 Whys or 5 Hows

In many situations, any given request or problem may have several contributing factors. If your first interview reveals that there are additional considerations, don’t be afraid to conduct several interviews. As mentioned, these two processes should be considered iterative and therefore could also be ongoing.

Emphasizing Collaboration

Ideally, the result of your interrogation will provide the basis for an action plan. In some instances, the answers to your questions may identify that stakeholder needs can be addressed by better utilizing existing software applications or technologies, making education the only requisite response.

Ultimately, the goals of 5 Whys and 5 Hows is collaboration. Whether you are realizing a new opportunity, helping to justify a software development activity, or just trying to better understand business processes and workflows, having a better understanding will always translate into better requirements.

Read next: 10 User-Centered Software Design Mistakes to Avoid

The post Identifying Software Requirements Using 5 Whys and 5 Hows appeared first on IT Business Edge.

6 Common Software Development Methodologies

Agile

The Agile methodology breaks projects down into smaller, shorter-term, more manageable, development cycles called iterations. Each iteration can include a variety of activities, including requirements gathering, analysis, planning, design, development, testing, or documenting.

Strengths

• Face-to-face communication is encouraged, allowing development teams to request clarification and minimize misunderstandings.
• Testing can be done during each iteration, resulting in a final product with very few bugs or design flaws.
• Team members are regarded as an asset.
• Multiple Agile frameworks are available:
  • Scrum: The most used Agile framework with a focus on team motivation. Scrum is best known for starting each workday with a 15-minute meeting to review completed and outstanding tasks while identifying new and evolving priorities.
  • Extreme Programming: Development activities using this Agile framework are driven by the need to be ‘good enough’. Driven by users and their requests, extreme programming is all about taking feedback and making it a reality—often with little regard to design or the possibility that a change may introduce instability or errors.
  • Kanban: This Agile framework thrives on transparency, requiring constant communication regarding the current state of development activities.

Weaknesses

• Resource planning can be a challenge, because each iteration may require different expertise or skill sets.
• Documentation is encouraged, but often completed “just in time”, pertaining only to the current functionality added during an iteration and may not be relative to the project as a whole.
• Because development efforts can begin in parallel to requirements gathering for future iterations, it’s difficult to track progress or define and enforce a clear project endpoint.

When to Use

• When your development team communicates well and works closely together.
• Your project is easily broken down into smaller, logically chunked, modules.
• Your team includes members with strong project management skills, so development isn’t frequently sidetracked with requests for unexpected, additional, functionality or features.
• Your stakeholders see value and gain satisfaction from frequent updates with visible progress.  

Spiral

For environments that need to prioritize mitigating risk, the Spiral methodology offers a conscientious approach that always begins with research and exploration.

Strengths     

• Supports the development of large and complex projects using prototyping and analysis during every phase.
• Accommodates the constant refinement and revision of project requirements based on informed decision making and consent.

Weaknesses

• Overkill for low-risk projects.
• Requires the extensive use of prototypes, which adds complexity and expense.

When to Use

• Ideal when security is a significant concern.
• When your project could be affected by ancillary systems or regulatory requirements that are outside of your control. 

DevOps

By unifying development teams with IT operations teams, the DevOps methodology values collaboration while delivering new and updated projects on a continual basis.

Strengths

• With continuous communication between teams, the DevOps methodology focuses on fast development, fast quality assurance, and fast deployment.
• Often takes advantage of automated testing.
• Changes to software are promoted out of a centralized code repository, making them easy to deploy or roll back.

Weaknesses

• Requires multiple teams work in parallel with empathy for each other’s challenges and objectives.
• Development activities are less structured and may not be requested with the support of detailed requirements or analysis.

When to Use

• DevOps is best suited for complex environments that require stability and consistent up-time.
• Ideal tool for ongoing maintenance tasks and delivering small, iterative, changes to existing software applications.

Lean

With the mandate to do the least you can, the fastest you can, Lean is a methodology that thrives in an environment looking for quick wins.

Strengths

• By eliminating features and functionality that aren’t considered absolutely necessary, projects developed using the Lean methodology are generally delivered quickly.
• With a focus on repeatable processes, code reuse is encouraged.
• Experts on your team are empowered and trusted to just get the work done.

Weaknesses

• Software built using this methodology generally lacks the scalability required to easily add on features and functionality in the future.
• Lean contains virtually no accommodation for coordinating the activities of multiple development teams, making it less suited for larger projects or those that require collaboration and communication with ancillary systems.

When to Use

• Lean is an ideal methodology for proof-of-concept projects, providing a bare-minimum product with only the most important functionality to users who can then offer feedback and drive later iterations and updates.
• Can be a lifesaving tool when dealing with stakeholders that cannot agree on project requirements—sometimes you just need to start somewhere.

Pair Programming

As the name implies, Pair Programming brings two developers together to work at a single workstation. Using this software development methodology, while one developer is at the keyboard, the other serves simultaneously as an observer, pointer, or navigator.

Strengths

• By applying a stream of consciousness approach to development, each developer can focus on a single aspect of a particular task: cutting code vs. adhering to project requirements.
• Can reduce testing time and expense by identifying possible issues as they are created.

Weaknesses

• Many developers find it intimidating or uncomfortable to be watched while they work.
• Requires both developers to be in the same physical location, ideally in an environment where frequent speaking aloud isn’t an issue.
• Works best when the pairing is expert-expert, so productivity and skillsets are evenly matched—though there are instances where pair programming can be seen as a valuable teaching and knowledge transfer experience.

When to Use

• This approach works best when development teams are small, and well-acquainted.
• Your project is structured such that ongoing brainstorming or strategizing is seen as beneficial.

Waterfall

Projects that are highly defined, with a series of sequential steps, thrive with the Waterfall methodology. Waterfall is a commonly employed software development methodology, operating on the principles of defining requirements and producing results.

Strengths

• Because project requirements are fully identified at the start of a project, phases can be planned with all activities defined (for design, development, implementation, verification, and maintenance).
• Upfront planning work can be completed by less technical team members.
• Deadlines are often fixed, and deliverables clearly identified.

Weaknesses

• Project phases do not overlap, and the only movement is forward, so changes to items completed in earlier phases is considered to be a new project.
• No working software is produced until the end of a life cycle.
• With the Waterfall methodology, the success of each project is determined by the quality of the requirements.

When to Use

• Your budget is defined and not easily adjusted.
• Your scope needs to be strictly controlled, due to stakeholder or regulatory requirements.
• You have strict control over your environment.

Choosing A Methodology

In large part, choosing a methodology is a mixture of education and instinct. Projects inspired by the best ideas in the world, brought to life by the most talented developers, are still vulnerable to risks like delayed delivery and dissatisfied customers.

Before choosing a software development methodology, consider the following criteria.

• Get to know your stakeholders: Don’t be afraid to ask questions before the start of a new software development project. Find out whether your stakeholders like to be more hands-on, reviewing progress at regular intervals, or if they prefer to employ a ‘wait and see how it all turns out’ approach. It can be helpful to learn whether your stakeholders also answer to other stakeholders of their own.
• Flexibility of project requirements: On one hand, when the requirements for a project are always changing, it can be difficult to deliver a product that meets expectations. That said, with some projects, we would never get started if 100% of the requirements needed to be determined ahead of time. In these instances, be sure you employ a methodology that offers checks and balances at regular intervals to be sure that changes to requirements are in the budget.
• Identify your end users: A project designed for large numbers of end users that are located across the globe has different considerations than one that will be deployed internally to a single team within your organization, located in the same physical location. Be sure you can answer questions about their demographics, education, expertise, and needs as they may pertain to your project.
• Understand the financials: It’s a harsh reality, but budget often drives the complexity and requirements for a development project. Be sure to choose a methodology that compliments the sophistication and complexity of what is being requested.
• Consider your timeline: If your project is longer-term, be sure to choose a methodology that accounts for the possibility of staff turnover or changes to infrastructure that may need to be accommodated. You also want to be careful that you don’t choose a methodology that is overkill for shorter-term projects.
• Know your development team: Look at your available resources and understand their abilities and capacity. Some teams employ methodologies that compensate for shortcomings, such as a lack of project management expertise or business analysts. Others look for methodologies that really isolate roles and let each team member perform singular tasks that compliment their expertise. Knowing where your team needs assistance and support will make it easier to choose the best methodology.

Consistency is Recommended

It may be tempting to choose a new methodology for each project your development team takes on, but this isn’t always sensible. Without consistency, your development team will fail to gain the efficiency and comfort derived from working with the same methodology over time.

Just as often, development teams boast using hybrid approaches, taking what they feel are the best characteristics from several methodologies and combining them into something customized and unique. Ultimately, this produces the same results as using no methodology at all—losing the consistency and structure of an established methodology, along with any community support.

Read next: Using Swim Lane Diagrams to Improve Software Development

The post How to Choose a Software Development Methodology: 6 Approaches appeared first on IT Business Edge.

What is a Swim Lane Diagram?

Swim lane diagrams are a visual answer to the question, “…and then?” To begin, consider the process, interaction, or workflow that your team needs to better understand or accommodate.

Begin the creation of your swim lane diagram by identifying your goals and the perspective required. Are you looking to show a high-level view of the interaction between departments in your organization, or a detailed step-by-step progression of the steps needed to complete specific tasks? Don’t discount that your swim lane diagrams may have several versions depending on the intended audience.

Though participants are often particular users, they can also be roles (salesperson, developer, HR director, etc.) or even ancillary systems; in the case of a swim lane that may identify the relationship and communication between external providers or consumers of your organization’s data, or network architecture interactions such as web servers connecting to database and email servers. 

Also read: Using Prototyping to Accelerate Software Development

Anatomy Of A Swim Lane Diagram

Swim lane diagrams take advantage of the same shapes and symbols found in flowcharting.

Simple

• Oval – Represents the start and end of a process or flowchart. Every swim lane diagram should have at least two.
• Rectangle – General considered to be the go-to symbol in a swim lane diagram. Rectangles capture the process steps, tasks, or actions.
• Arrow – Shows directional flow along the swim lane diagram’s path. Consider labeling these connections to avoid any confusion, particularly with complex diagrams where the arrow heads can be very small and difficult to discern.
• Diamond – Indicates when a decision is required to move forward. Diamonds communicate that there is a question, the answer to which will determine the next step down the path.

Detailed

• Document Symbols – Can be singular or multiple, frequently referring to points where documentation must be updated or when the review of external paperwork is recommended or required.
• Data Symbols – Includes images to represent databases and various types of data storage. These can be handy when skimming complex swim lane diagrams for instances when databases are being accessed or data backups are being created.
• Loop and Delay Symbols – Identify repeated process steps easily or define waiting periods that are part of the flow. These are frequently used for software applications that generate invoices or statements. They may also indicate when calculations or updates are performed at-a-later-time (such as overnight).
• Miscellaneous – For complex swim lane diagrams, it can be helpful to utilize the lesser-known symbols for input/output, manual operation (requiring user input to continue), or display (information being shown to a user). Other symbols indicate areas where one swim lane diagram merges or connects to another, detailing flow to other processes.

Swim Lane Diagram Example

Consider the following swim lane diagram example detailing the service desk workflow for an organization.

Notice that there are three lanes, one for each of: User, CSR, and Tech Support. These lanes contain a series of actions, decisions, and activities that are being completed in parallel to each other. It is important to understand that there are several areas where tasks align across all the lanes—these are the areas where progression cannot occur until all the requisite items are addressed.

This swim lane diagram could later evolve to include additional considerations and interactions that may be required if the solution requires the engagement of a development team, needs a customer service representative or salesperson, or to add more granular task details such as regression testing or updating knowledge base documentation. 

Risk Identification and Process Improvement

One of the biggest benefits of a swim lane diagram is to identify missed steps, eliminate duplication of efforts or task redundancy, and to predict bottlenecks or security threats.

Identify missed steps

Did you assume that your service desk staff were always updating your knowledge base when issues get resolved? Are salespeople supposed to begin order entry for customers by first confirming current address and telephone number details? Are you sure that every requisite step is being completed so your database backups take place regularly?

Swim lane diagrams can be a fantastic source of truth, serving as a reference to be sure the things you think are happening actually are.

Eliminate duplication of efforts and task redundancy

How many employees start their day by checking the same voicemails? Are multiple members on the same team performing overlapping activities that could be better handled with categorization and delegation?

Swim lane diagrams help to identify the places where you can streamline mundane or repetitive tasks, freeing up resources to complete more valuable and rewarding work.

Predict domino-style consequences, and understand security threats

It can be difficult to keep track of which teams or how many of your users are accessing or updating sensitive data. Swim lane diagrams provide a comprehensive and visual way to recall all of the roles, responsibilities, and access requirements, for the users of your applications. They let you know, with confidence and authority, whether a salesperson making an update to a customer record will cause unintended consequences for your financial team as they run monthly invoices or statements. 

Swim lane diagrams can also help mitigate risks when upgrading existing software applications or procuring new tools. Understand at a glance which users or systems are current consumers of the data or functionality being offered by the new or existing systems, and ensure that they can be part of the planning and testing activities for those projects.

Swim lane diagrams are like dictionaries, providing descriptions and definitions for organization-specific details.

Taking Swim Lane Diagrams a Step Further

Swim lane diagrams offer clear benefits to organizations, helping to understand, improve, and support business processes. These passive benefits have value, but consider how you might also employ swim lane diagrams to support organizational changes and evolution.

Change management

If the purpose of change management is to mitigate risks associated with updates to software applications and business processes, it is critical that you know exactly which users need to be notified, updated, engaged, or even re-trained. Understanding how ancillary systems integrate with one another can help tremendously when trying to determine the impact of any and all changes. Swim lane diagrams can protect your service level agreements from risks by displaying both obvious and lesser known users of functionality and consumers of data.

Human resources management

Swim lane diagrams have tremendous potential to assist human resources management activities. Understand what will happen when a staff member is reassigned to a different department, and update their security credentials and access requirements accurately. If your payroll supervisor is away on vacation or off on a maternity or sick leave, know the logical team members to cover their responsibilities by identifying who performs similar or parallel tasks. Organizations can also use swim lane diagrams to more easily onboard new employees, identifying where accounts need to be created and access granted, but also to see which systems they may require training for. The same works in reverse, as an employee leaves the organization.

Infrastructure management

As the sophistication of IT infrastructures evolve, so do our dependencies on network resources and third-party services. Swim lane diagrams make it easier to manage these connections by providing the understandings needed to streamline demands for bandwidth, optimize frequent queries against large databases, or even understand how changes to your system may affect data being consumed or provided by outside agencies.

Swim Lane Diagrams as a Development Tool

Want to improve your existing software? Use swim lane diagrams to walk development teams through the workflows and business processes currently in place. Use them to supplement business requirements by walking developers through how the system needs to work—particularly when there are tasks that have specific complexities like the need for review and revision.

Swim lane diagrams can also be a powerful visualization tool that can be used to demonstrate and rationalize the need for and the value of a new software application. Show the current state and compare it to the future, more streamlined and simplified state. Demonstrate where security will be enhanced, or infrastructure better utilized.

For software versions of this type of tool, you can check out LucidChart, Creately, WonderShare, Canva, and Visio.

Read next: Using Journey Maps to Understand Your Software Users

The post Using Swim Lane Diagrams to Improve Software Development appeared first on IT Business Edge.

10 User-Centered Software Design Mistakes

Create a solution that better understands your audience and more completely meet their needs by avoiding the most common user-centered software design mistakes.

1. DON’T start a new development project with the solution in mind

Make certain that your business model focuses on user experience and not self-interest. Instead of creating a product you think will sell or you guess will be popular, start by identifying an audience. Work to understand their behaviors, habits, and practices. By designing software with empathy for real users with real problems, you create a product they can’t live without.

2. DON’T add unnecessary features

It won’t make you look clever or current to always use the latest and greatest or the biggest and boldest design features, especially when these perceived-to-be-cool features aren’t necessary.

If it’s too cutting edge, your software may not work consistently (or at all). It may be better to keep your software simple and functional and leave attracting customers to the sales and marketing teams.

3. DON’T leave your users guessing

Be certain users always understand how their commands and actions are being interpreted. If a field can be edited, make that clear. Provide guidance when it is important that users understand the consequences of an action, such as deleting or revising information.

It can be helpful to use consistent visual cues, such as graying out form fields that don’t allow editing.

4. DON’T make catastrophic actions too easy

While it’s convenient to have all the buttons for actions like Save and Delete in the same area on the screen. In almost all cases, usability best practices even recommend grouping actions together.

Just be careful that a user working quickly, or tabbing through a form with their keyboard, can’t unintentionally decide the fate of any important information. Employ confirmation dialogue boxes to explain the consequences of fatal actions and provide a way to hit the brakes and reverse.

5. DON’T make users perform repetitive, mundane tasks

Instead of making the default value for a form field blank or Select One, consider using intuitive or common presets. Just make sure that these defaults are easy to change and that the consequences aren’t too significant if the user fails to make a change they should have.

That said, few things make a user happier than being able to check a box that confirms their shipping and billing addresses are the same.

6. DON’T create software junk drawers

If a feature has been retired, remove it. And if a module doesn’t fit under any existing menu items, fight the urge to file it under meaningless catch-all menu options such as Misc., Tools, or Other.

7. DON’T forget to consider accessibility

Not all users will have the same abilities, culture, language, age, bandwidth, or available technology. Inclusive software is better software.  

Also read: Inclusive Software Design Best Practices

8. DON’T let one user cause you to lose sight of the bigger picture

Sometimes a single user has insight that can significantly improve your software design. Sometimes a single user cannot be pleased, no matter the effort and empathy you invest. It’s important to listen to and consider the feedback given by all users, but it’s also okay to question it (respectfully and without judgment).

9. DON’T employ hard-to-acquire UI elements

Users are familiar with scrollbars, so resist the urge to use hard-to-see up-and-down arrows in their stead. Don’t underline text that isn’t a link. Don’t use images that look like actionable buttons if they aren’t serving that purpose.

If users are having difficulties determining which features on a page are actionable, then you may want to rethink your UX design.

10. DON’T assume icons mean anything to anyone

Menus function best when they are labeled clearly using text. Provide a link to your homepage with the word Home in the navigation menu instead of an image that may or may not look like a house to somebody. It’s also much easier to click on the word Home, than a tiny icon. 

Also read: User Centered Design: Focusing Software Development on the Users

5 User-Centered Software Design Quick Wins

By its very nature, user-centered software design should be customized and specific to your product built for your users. With that in mind, consider a few quick win suggestions that could find their way into your project.

1. Progress indicators

Be sure that multi-step tasks are clearly labeled, so users understand where they are at and when they are finished. If wait times during back-end processing can’t be avoided, keep users informed about what is happening.

For example, familiar animations such as spinners can be reassuring, but only if the wait will be very brief. If the delay is more than 10 seconds, consider communicating the percent-done when possible.

2. Simple dialogue

Always use plain language and vocabulary that is appropriate and relevant for the target audience. Avoid including irrelevant details or industry-specific terminology, unless omitting it would cause other issues or confusion.

3. Meaningful feedback

Let users know when actions are completed successfully. Provide confirmations when items are saved or deleted. If an error message is encountered, treat it as a teachable moment by briefly explaining why it happened and what remediation steps are necessary. Feedback gives users confidence and lowers anxiety.

4. Be consistent

It’s often said that “differences are difficult.” Don’t say edit when you previously said update. Don’t ask users to logout when you later ask them to log off. If links are underlined in blue in one module, be sure they are in every module.

5. Make constraints clearly understood

If your system is unavailable during specific time periods, clearly state the details, so users can plan their time accordingly. If you require certain credentials to use a feature or function, identify who the user should contact to gain access. If form data is invalid, clearly explain why it isn’t being allowed.

Some Best Practices Should be Used With Caution

Make the most of your good intentions by understanding some ways that development teams can be led astray. The best example of this is with forms requiring an address: users start typing their location, and like magic, the software populates form fields for street address, city, state, zip code.

As convenient as this is, it can be frustrating when the form tells the user that their address doesn’t exist. Worse yet, those same forms often don’t allow users to override and edit the incorrect values.

User-Centered Software Design is a Learning Process

Frequently remind your team that failure shouldn’t be feared. User-centered software design is an iterative, and sometimes frustrating, process that can take time. It’s not always easy to truly understand the needs of your users, but the process will certainly add value to your product.

The best approach to user-centered software design takes advantage of iterative design and development. By testing new features and functionality often, with small numbers of users, your team can quickly revise or abandon anything that isn’t working well.

Read next: Using Journey Maps to Understand Your Software Users

The post 10 User-Centered Software Design Mistakes to Avoid appeared first on IT Business Edge.

Software usability testing makes good software great by valuing the user experience it provides. 

Deciding Between Moderated or Unmoderated Usability Testing

Moderated usability testing is highly structured and provides detailed results with rich, qualitative insights. By utilizing the skills of a professional researcher, participants can be guided through tasks and asked spontaneous follow-up questions based on their actions and reactions.

However, it should be understood that the researcher could unintentionally influence the outcomes of certain tasks if users feel rushed, intimidated, or judged whereas other users may feel comforted by having real-time guidance. In addition, moderated usability testing can be expensive and time-consuming.

Comparatively, unmoderated usability testing is done without any supervision. Participants are able complete tasks in their own environment using their own tools.

Unmoderated usability testing can also be conducted quickly and with a lower budget. 

How to choose

Moderated usability testing is critical when tasks are complex or need to be completed in their entirety for your results to be meaningful.

Unmoderated usability testing is best for large-sample studies or when it’s valuable to know how your software application performs under uncertain conditions using a variety of devices and configurations. 

Conducting Usability Testing Remotely vs. In-Person

Current COVID-19 pandemic aside, remote usability testing offers considerable advantages when being physically present is prohibited by cost or logistics. By utilizing the internet and telephone, you can easily test large numbers of people from across any number of demographics.

Unfortunately, remote testing requires a few sacrifices. Researchers will miss the opportunity to judge body language and facial expressions. Even when using video conferencing, it can be very difficult to pick up on subtle behaviors and feelings.

The best approach is to employ a hybrid model. Consider conducting a smaller, in-person usability test, then supplementing this with remote follow-up or targeted tests.

For instance, if your in-person testing reveals a certain type of user struggles with a particular task, modify your software application and retest remotely with new participants that meet the requisite criteria. 

Choose a Testing Method that Delivers the Information You Need

Usability testing can take many forms and occur at various points in the software development and support lifecycle. Each testing method will generate different types of information. 

Exploratory

Exploratory usability testing provides a method for evaluating early stage design ideas. Participants are given ideas and concepts, then provided with the opportunity to brainstorm, offer opinions, and express emotions. This method of testing can be especially valuable when trying to identify wishlist items and pain points within existing software applications or business practices, ultimately helping to choose where to focus and prioritize new development efforts.

Be careful when using exploratory testing in groups as participants may influence each other or impede the free flow of thoughts.

Assessment

Assessment usability testing provides answers to specific measurable questions about a software application, such as whether users can accomplish given tasks and achieve certain goals, whether they are satisfied by the product, and whether there are any accessibility barriers.

Comparative

Comparative usability testing forces participants to make choices and state preferences. This or that? Us or them? Which is more inviting? Which menu label is easier to understand? Which font is easier to read?

Though many feel evaluating participants in this manner cannot truly be thought of as usability testing, the comparative method is ideal for presenting remediation options for known issues. 

Also read: Inclusive Software Design Best Practices

How Do You Recruit Participants?

Conducting effective user research depends on finding the best suited participants. A few strategies can help to make recruiting these people a little easier.

• Focus on participants that represent your target audience and potential users. If you are designing a software application that will be used by financial analysts, it likely doesn’t matter whether kindergarten teachers find it easy to use.
• Be aware of potential bias. While it may be important to ensure participants have the requisite industry-specific knowledge or background necessary to test your product, be careful that your group includes those with various roles and responsibilities. Don’t forget, many employees may not feel free to criticize a product if they fear repercussions, so do what you can to reassure (and protect) these individuals.
• Be sure rewards offered aren’t seen as conditional. While it is customary to compensate skilled professionals for their time or offer rewards as signs of appreciation, be sure participants understand that these benefits are given regardless of the testing outcomes.
• Don’t forget diversity. Look for participants that can provide insight into how accessible and inclusive your product is.
• Use a series of consistent questions during the screening process. Do you need participants within a certain age range? Do you need to confirm that participants have a particular level or type of education? Does income level matter? Has someone worked for one of your competitors? What are their hobbies? Do they speak multiple languages? While some of the answers to these types of questions may exclude a potential participant, they may also serve as ice breakers or provide logical ways to create groupings of similar participants for more targeted usability testing activities.

Be sure all potential participants feel valued and be prepared to communicate inclusion criteria, so it can be understood why they may not have been chosen. 

Creating Tasks for Usability Testing

Usability testing tasks provide participants with assignments that will require a series of actions and activities to complete.

Create quality usability testing tasks and avoid common mistakes by following these six guidelines:

1. Don’t confuse the purpose of your software with the tasks you are giving participants. You may be developing a comprehensive bookkeeping software application, but the task being assigned for testing may be to ‘Add a new client.’
2. Start with a task scenario. Participants are generally coming into your usability test with little to no information. Do not assume they can intuit backstory or context. That said, avoid giving more information than is reasonably required.
3. Make tasks realistic and actionable. Participants are testing your product, not your concept. Avoid creating tasks that encourage conversation instead of action. (Good action verbs include download, buy, subscribe, find, click, complete, sign up, log in, invite, create, and share.)
4. Avoid telling your participants what to do or where to go. Remember that, in the real world, users of your product won’t have a task in front of them offering clues or describing the steps. Avoid phrases like “click on” or “then, choose.” Although, if your product has a natural workflow or progression, it is okay to arrange a series of tasks in a sequence.
5. Be sensitive and kind to your participants. Review each of your tasks to ensure they will not invoke unnecessary emotion or cause offense. When necessary, use harmless relationships as references, such as “friend” or “colleague,” and eliminate wording that communicates judgment, like “exercising to lose weight.”
6. Verify every task ahead of time. Make sure your tasks can actually be completed using the version and configuration of the software application being provided to participants.

No matter the tasks, it’s critical your participants understand the product is being tested, not the users.                            

Also read: Using Journey Maps to Understand Your Software Users

Conducting Your Software Usability Test And Recording Results

Unfortunately, this isn’t a one-size-fits-all activity. A lot will depend on how you’ve chosen to perform your software usability test, but there are a few tips and tricks that should work for you regardless of those details:

• Identify tasks that record their own data and don’t worry about them during your usability test. You should know if users were able to create accounts on your system if there are the same number of new accounts as test participants. If you will not have a moderator or observer present during the test, ensure all of your tasks leave this kind of information trail to review later.
• Start your usability test with an introduction and communicate your expectations. If you need users to record their actions on a data sheet, be sure to provide it and walk them through how to fill in the details and submit it for review. Ideally, this should be a stream of consciousness type activity, so it is recommended that you discourage participants from erasing anything they write. 
• When possible, take audio and video recordings of your usability test (always obtain consent ahead of time, of course).
• Always make participants feel valuable and appreciated. Tell them when things they do or say are helpful, and always thank them for their time.
• If participants offer narration while completing tasks, ask for clarification when needed, and consider paraphrasing your understanding to be sure it is correct.
• Finish your usability test by giving participants the opportunity to ask follow-up questions and provide any final feedback they may have. 

Evaluating Usability Test Results

After you’ve conducted your usability test, it’s advisable to review the data you collected as soon as possible. As much as you or your participants may try to take comprehensive notes, it’s likely you will see details like “clicked on the wrong link.” It’s much more likely you will remember that “clicked on the wrong link” meant “clicked on x link instead of y,” which provides significantly more insight.

Everybody will collate their results in a different way, but what’s most important is that the method you choose makes it easy to look for patterns. Identify problems that happened once and separate them from those that were more frequent. Highlight problems that sabotaged tasks, causing complete failure.

You may also need to evaluate the same results data in multiple ways or using different groupings.

When prioritizing the issues to be remediated and retested, look for quick wins that check multiple boxes. For example, a fix to the layout of your user interface may also improve accessibility for users with visual impairments.

Software Usability Testing Is An Investment

There isn’t a software application out there that is too efficient, too easy to use, and perfect just as it is. By leveraging software usability testing, you have the opportunity to better understand how actual users feel and think when using your product, while ensuring their needs are being understood and met.

Read next: Using Prototyping to Accelerate Software Development

The post Steps to Conducting a Software Usability Test appeared first on IT Business Edge.