InRhythm

Your partners in accelerated digital transformation

learning and growth

Human Interface Guidelines

A desktop on a table with paper next to the screen.
Photo by UX Store on Unsplash

Human Interface Guidelines suggest how interface components should look and how users will interact with them. There are as many ideas about interface design as there are proponents of any particular library or API. 

All interface designs share a similar goal, which is to create a unified user experience across the environment. To accomplish that, the guidelines help make their design’s interface intuitive, consistent, and learnable, both for the OS for its applications and tools. All interface elements and their guidelines should be included in an interface design document with usage examples, when practical. For example, buttons, checkboxes, dialog boxes, application views, buttons, bars, etc.

Apple Human Interface Guidelines

Apple was one the first companies to use “look and feel” in their literature when referencing the MacOS interface in the 1980s. As technology advanced, ideas on interface design also advanced. Today, Apple has “Human Interface Guidelines” that establish how your application should look and feel to users on all of it’s platforms.

Apple’s HIG is an extensive document covering all aspects of application look and feel across the entire Apple ecosystem. There is a platform-specific HIG for each Apple OS environment: 

  • macOS for MacBooks
  • iOS for iPhone/iPad
  • watchOS for Apple Watches
  • tvOS for Apple TV

Apple’s HIG is organized by platform and technologies. Each platform is subdivided into sections. For iOS, for example, the sections cover architecture, user interaction, system capabilities, icons and images, bars, views, controls, and extensions.

From the iOS section topics, it’s evident that Apple is invested in ensuring that applications on their platform have that certain Apple “look” and that those applications function in a consistent manner. 

Consistency is an important factor in user uptake of new applications. When UI elements function similarly, it’s easier for your users to transfer their operational knowledge between applications. 

Using the HIG helps maintain the quality of your application by guiding your UI decisions to support the application’s operation. Following the HIG will improve your engineering and design decisions by helping you to anticipate what most users will expect from your application’s interface.

It’s important to remember that the HIG does not dictate how your application operates, it describes the user/application interaction through visual cues, controls, and application feedback.

Customer Impact

Photo by Faizur Rehman on Unsplash

When followed, the Human Interface Guidelines ensure that the components of your application’s UI are understandable to the average Apple user through familiarity with the OS and with other applications.

Maintaining a consistent interface helps you create an application interface that is more rapidly accepted and gives your users an increased feeling of being in control, which creates a positive user experience. A side benefit is that your application will complete the App Store in a more timely manner because the UI and its controls appear and operate in the manner expected by the reviewers.

Resources

InRhythm University Lightning Talk: Lightning Talk / Human Interface Guidelines / February 24th 2022 / Hamid Mahmood

Apple’s Human Interface Guidelines: https://developer.apple.com/design/human-interface-guidelines/

Change? What Change? Everything Always Goes to Plan

As software engineers, we are conditioned to brace for change. The very nature of our work requires that we be ready for it. Yet, at our cores, we don’t want there to be any changes. We don’t surrender to the inevitable changes that are going to be required after we submit content for a code review. Instead, we steel ourselves against it, and gear up for battle with a mindset of resistance. We don’t want our QA teams to find any bugs because we’ll then have to make changes to the code we’ve already written. 

The experience, however, is like the Grinch who does everything that he can to stop Christmas from coming. Of course, the holiday arrives anyway. Similarly, despite our best efforts to plan and design an agile effort which builds change in, we’re still not entirely prepared to embrace those changes when they do come. And they will. They always do.

Agile Value #4: responding to change over following a plan” speaks to this behavioral response. It’s all about our attitude. Are we prepared for change and willing to accept that there will be change (as there is for every software engineering project)? Or are we preparing for a fight that we are inevitably going to lose? 

Agile craftsmanship requires that we be nimble in our designs and in our approach. The code we write must stand up to meet the quality demands of the project and not interfere with other parts of the project, but it has to be nimble, too. Anyone at any time in the future may need to rework that code or replace it altogether. If it’s rigid and inflexible, the effort to update it (or replace it) will be that much more intense. Working sprint after sprint is already intense enough – we don’t need to add more stress to our day. In contrast, we need to take measured steps to reduce it.

One of the best ways to manage this stress and to reduce our anxiety is to prepare for change. Embracing a mindset of flexibility prepares us for the change that is coming. If our response is calm and collected, the changes requested will be received just like any new project instead of what may feel like a personal attack on our abilities.

Approaching any project with the expectation that it will likely end differently than it began requires proactively building a roadmap that is designed to be nimble and responsive by anticipating potential changes. Getting ahead of industry trends and predicted needs requires that we are constantly in the mode of collecting feedback from clients, tracking the market and soliciting input from other agile experts. Scenario planning is another way to help with preparedness. This is the only way that we can evolve as a trusted colleague and partner to the clients we collaborate with.

Christopher Okhravi, an authority on agile software development, offers an insightful perspective on the application of Agile Value #4. He reminds us that, “We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.” Another factor that we need to remember is that rigid planning and process are the antithesis of the freedom derived from an agile approach. As each project unfolds, we learn more about the needs of that project and gain new insights on how to best deliver the code needed to execute the project. However, as we do so, we tend to drift further from the original plan which no longer reflects our reality and this creates tension for everyone involved. 

So, what is the best way forward? Embrace Agile Value #4. We must plan for the worst but hope for the best because change is inevitable. We must be nimble – and stay that way. Change is a necessary element of what we do. We can design our product roadmaps to be responsive and proactive or we can choose to be reactive and struggle to keep up. Getting ahead of industry needs and trends helps us prepare for the changes that will come. Being open to continuous feedback from our clients, our managers, our peers and our colleagues helps us evolve into a trusted co-worker and business partner. 

“Change always comes bearing gifts.”  ~Price Pritchett

Robert Morrell

Practice Lead, Java Cloud

What We’re Reading Around the Web

Agile Manifesto 4/4 – Responding To Change Over Following A Plan by Christopher Okhravi
YouTube
“We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.”

Manage Stress
Healthfinder
“To be agile, you need to be able to ask, ‘Is this agile?’”

Applying Agile Management Value 4: Responding to Change Over Following a Plan
Dummies
“Unfortunately, traditional project management approaches attempt to wrestle the change monster to the ground and pin it down so it goes out for the count.”

Getting Started With Agile: Responding to Change Over Following a Plan
Pivotal Tracker
“As project execution unfolds, the team learns more about what needs that resulting product will fill as well as how that product can best be built. As this new reality emerges, the team struggles to keep their project aligned to the original plan, which likely no longer reflects the team’s new reality.”


Change Is The Only Constant

A true Agile Craftsman Mindset understand that change is the only Constant

As product developers, we take pride in the “big picture” of the function of the software that we are designing and implementing. Delivering a solution for our clients, and their customers, takes diligence, long hours and impeccable planning. However, even the best-made plans can go awry. How we deal with those plans differentiates the inflexible resistors from the agile craftsmen.

“Agile Value #4: responding to change over following a plan” speaks to this behavioral response. Optimists hope for the best but plan for the worst. Pessimists expect the worst but plan for the best. And flexible realists exhibit behaviors that are the best of both understanding that being nimble and prepared for change is the right mindset. Framing everything that you do with the strong possibility that things will likely change and be different that you planned for cues up your brain to be prepared for change. Hence, you enable yourself to successfully adapt to whatever the new situation is.


Beyond one’s mindset, a critical aspect of practicing Agile Value #4 relates to planning and design. Approaching any project with the expectation that it will likely end differently than it began requires proactively building a roadmap that is designed to be nimble and responsive by anticipating potential changes. Getting ahead of industry trends and predicted needs requires that we are constantly in the mode of collecting feedback from clients, tracking the market and soliciting input from other agile experts. Scenario planning is another way to help with preparedness. This is the only way that we can evolve as a trusted partner. As agile craftsmen, our clients expect us to be inherently nimble, ready for change, willing to adapt and to plan for adjustments so that we can still track to a set schedule and deliver the quality product we are contracted to produce.


Understanding that change is a natural aspect of a project is one thing. Being prepared for it with a thoughtful plan and design that anticipates where and when those changes are most likely to happen is quite another thing altogether. Here, experience can make all the difference. The client relationship is another factor, one that we’ve discussed in a previous newsletter, ”Customers are Much, Much More Than Signed Contracts”. When a client and vendor embark on a path towards partnership, versus a client-vendor relationship, both sides enter the agreement and project understanding that it’s best to expect the unexpected and be prepared to flex. Sometimes, the client may need to be flexible. Other times, the contracted agile partner may need to adjust as the situation changes for the client.
If change is the only constant, and Agile Value #4 requires that we plan for and accept change versus resist it, we need to each ask ourselves if we are agile and flexible. Or, are we rigid and linear?

Thanks and Keep Growing,

Gunjan Doshi

CEO, InRhythm

What We’re Reading Around the Web

Agile Manifesto 4/4 – Responding To Change Over Following A Plan by Christopher Okhravi
YouTube
“We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.”

Manage Stress
Healthfinder
“To be agile, you need to be able to ask, ‘Is this agile?’”

Applying Agile Management Value 4: Responding to Change Over Following a Plan
Dummies
“Unfortunately, traditional project management approaches attempt to wrestle the change monster to the ground and pin it down so it goes out for the count.”

Getting Started With Agile: Responding to Change Over Following a Plan
Pivotal Tracker
“As project execution unfolds, the team learns more about what needs that resulting product will fill as well as how that product can best be built. As this new reality emerges, the team struggles to keep their project aligned to the original plan, which likely no longer reflects the team’s new reality.”


3 Themes of Thanksgiving to Apply Everyday

The Simple, Rapid Test That Every Agile Team Should be Doing

A couple of weeks ago, I shared some thoughts around the concept of leading a team of agile craftsmen and how all of us were practitioners in a living lab. Agile product development, by definition, requires that we fail fast, learn from our mistakes and develop processes that maximize efficiency. Agile values also require that we put the emphasis on people ahead of the process.


That sounds incongruous. How do you do both in parallel? It seems like it would be impossible to put people first yet adhere to the rigor required by following a process. However, there is a way. It’s called the Agile Litmus Test. Although there is no standardized template for it, the basic concept is that each team member thinks about why s/he/they is doing what they’re doing towards the goal of assessing whether or not the individual, team or corporate effort meets the values and principles as defined by the Agile Manifesto.

Many of you may recall the litmus test from your chemistry classes. The Litmus Test is a simple, low-tech, low-cost way of determining the pH (acidity) of a given solution. It’s been around for centuries and it’s still in use today both as a physical test as well as a metaphor for describing a quick method for testing out a concept. The fact that it’s been around so long illustrates how effective it is which, in turn, underscores the value of the Agile Litmus Test. One thing that surprised me is how search results returned for this test seem to drop off after 2015 – have agile developers lost sight of its importance?

Within the context of agile product development, the Agile Litmus Test is a rapid means of straddling the duality of putting people ahead of the process  (Agile Value #1) yet still adhering to it. There are several versions of what it should be, but there are only a few basic rules regarding the application of the Agile Litmus Test. In short, keep asking yourself if you’re doing the right thing. Given that we’re all agile craftsmen, we should be encouraged to use a little latitude to make the “rules” work for each of us given our own scenarios. At InRhythm, we apply it to meet our needs.

Quite simply, the Agile Litmus Test is the act of asking practical, meaningful questions to assess our priorities. Which questions you ask and which order you ask them in are not critical. What is critical is that you ask some flavor of these questions regarding everything that you do. It’s less about the rigor of the questions asked and more about accepting the personal responsibility of asking them. Whatever you’re doing, which includes posting on social media, writing content, coding, documenting, how you conduct yourself at a meeting and what you say there, etc. should all be subjected to the Agile Litmus Test. 

Consider questions along the following lines:

  • Why am I doing X this way?
  • How is doing X going to help me meet my goal(s)?
  • Should I be doing X right now?
  • Is there something else that I should be doing instead of X?
  • How will my team or project be impacted if I do X?

The idea is to self-assign a mental speedbump, not a big hurdle. You want that little bump to be big enough to get noticed but small enough to accelerate through. Take the time to pause and think about what you’re doing and why you’re doing it. Each of our actions as agile software engineers who are part of high velocity teams has consequences for us as individuals, as a team, as a client and as a vendor. We need to consider the bigger picture for all that we do and not gloss over our own accountability for using our time in a way that advances our personal and professional goals. 

In my years of experience onsite at clients and working with 10x teams, I’ve seen people get caught up in their own agendas. Somehow, they lose track of the bigger picture or their leaders have not communicated it effectively to them. Regardless of how or why it happened, they are not invested in how their efforts tie into the collective efforts of the project. So, you’re thinking, well, if one individual has lost sight of the vision and the shared end-goal, that’s probably not going to have an effect on the overall outcome. Or, if you’re that individual, you may be thinking the same thing. 

Not so, because there is rarely just one individual on an agile project that loses sight of the priorities. Typically, it’s more than one which can have dire consequences on hitting the milestones and timeline that only some people are tracking to. If you were to apply the Agile Litmus Test right now, what is the question that you ask yourself?

Thanks and Keep Growing,

Gunjan Doshi

CEO, InRhythm

What We’re Reading Around the Web

16 Quick Poll – a Litmus Test for Agile Product Development
Scrum Breakfast
“I want a litmus test, i.e. a short list of questions for challenging developers and their managers on their engineering practices.”

How to Test for Agility with the Agile Litmus Test
Dummies
“To be agile, you need to be able to ask, ‘Is this agile?’”

Taking the Agile Litmus Test
O’Reilly Safari
“When you understand these values and principles, you’ll be able to ask, “Is this agile?” and be confident in your answer.”

The Principles of Agile Manifesto
Educba
“Collectively, these principles are used to like a litmus test to identify if a project is being run on agile or not.”


Simple Test for Every Agile Team

November 19th: The Simple, Rapid Test That Every Agile Team Should be Doing

A couple of weeks ago, I shared some thoughts around the concept of leading a team of agile craftsmen and how all of us were practitioners in a living lab. Agile product development, by definition, requires that we fail fast, learn from our mistakes and develop processes that maximize efficiency. Agile values also require that we put the emphasis on people ahead of process.


That sounds incongruous. How do you do both in parallel? It seems like it would be impossible to put people first yet adhere to the rigor required by following a process. However, there is a way. It’s called the Agile Litmus Test. Although there is no standardized template for it, the basic concept is that each team member thinks about why s/he/they is doing what they’re doing towards the goal of assessing whether or not the individual, team or corporate effort meets the values and principles as defined by the Agile Manifesto.

Many of you may recall the litmus test from your chemistry classes. The Litmus Test is a simple, low-tech, low-cost way of determining the pH (acidity) of a given solution. It’s been around for centuries and it’s still in use today both as a physical test as well as a metaphor for describing a quick method for testing out a concept. The fact that it’s been around so long illustrates how effective it is which, in turn, underscores the value of the Agile Litmus Test. One thing that surprised me is how search results returned for this test seem to drop off after 2015 – have agile developers lost sight of its importance?

Within the context of agile product development, the Agile Litmus Test is a rapid means of straddling the duality of putting people ahead of process  (Agile Value #1) yet still adhering to it. There are several versions of what it should be, but there are only a few basic rules regarding the application of the Agile Litmus Test. In short, keep asking yourself if you’re doing the right thing. Given that we’re all agile craftsmen, we should be encouraged to use a little latitude to make the “rules” work for each of us given our own scenarios. At InRhythm, we apply it to meet our needs.

Quite simply, the Agile Litmus Test is the act of asking practical, meaningful questions to assess our priorities. Which questions you ask and which order you ask them in are not critical. What is critical is that you ask some flavor of these questions regarding everything that you do. It’s less about the rigor of the questions asked and more about accepting the personal responsibility of asking them. Whatever you’re doing, which includes posting on social media, writing content, coding, documenting, how you conduct yourself at a meeting and what you say there, etc. should all be subjected to the Agile Litmus Test. 

Consider questions along the following lines:

  • Why am I doing X this way?
  • How is doing X going to help me meet my goal(s)?
  • Should I be doing X right now?
  • Is there something else that I should be doing instead of X?
  • How will my team or project be impacted if I do X?

The idea is to self-assign a mental speedbump, not a big hurdle. You want that little bump to be big enough to get noticed but small enough to accelerate through. Take the time to pause and think about what you’re doing and why you’re doing it. Each of our actions as agile software engineers who are part of high velocity teams has consequences for us as individuals, as a team, as a client and as a vendor. We need to consider the bigger picture for all that we do and not gloss over our own accountability for using our time in a way that advances our personal and professional goals. 

In my years of experience onsite at clients and working with 10x teams, I’ve seen people get caught up in their own agendas. Somehow, they lose track of the bigger picture or their leaders have not communicated it effectively to them. Regardless of how or why it happened, they are not invested in how their efforts tie into the collective efforts of the project. So, you’re thinking, well, if one individual has lost sight of the vision and the shared end-goal, that’s probably not going to have an effect on the overall outcome. Or, if you’re that individual, you may be thinking the same thing. 

Not so, because there is rarely just one individual on an agile project that loses sight of the priorities. Typically, it’s more than one which can have dire consequences on hitting the milestones and timeline that only some people are tracking to. If you were to apply the Agile Litmus Test right now, what is the question that you ask yourself?

Thanks and Keep Growing,

Gunjan Doshi

CEO, InRhythm

What We’re Reading Around the Web

16 Quick Poll – a Litmus Test for Agile Product Development
Scrum Breakfast
“I want a litmus test, i.e. a short list of questions for challenging developers and their managers on their engineering practices.”

How to Test for Agility with the Agile Litmus Test
Dummies
“To be agile, you need to be able to ask, ‘Is this agile?’”

Taking the Agile Litmus Test
O’Reilly Safari
“When you understand these values and principles, you’ll be able to ask, “Is this agile?” and be confident in your answer.”

The Principles of Agile Manifesto
Educba
“Collectively, these principles are used to like a litmus test to identify if a project is being run on agile or not.”