Creating the Right App Posture

Now you want to build an app…

The right application serves a purpose, it is intuitive and easy to use. An application exists to solve a problem for someone. But before you begin your research on why you should use a native mobile app versus a hybrid app, Firebase versus AWS or MEAN versus LAMP stack, the app posture is a unique concept you should familiarise yourself with.

Whether you are a developer, or simply an entrepreneur looking to cash in on potential opportunities available through apps, the posture for your intended app is one you do not want to be misinformed on.

The idea behind app posture was introduced by Alan Cooper in his book, About Face 3. Posture is used to identify “a behavioral stance that helps to define the context of user interaction with a product, both as a whole or through individual features.” An application posture describes the interactions between an application and its users. Application postures highlight necessary elements that should be factored into the design of an app’s workflow to create optimised experiences for the end users.

In considering what posture to use for your app, there are three main categories from which you can select:

• Sovereign

• Daemonic

• Transient

Your choice of posture will greatly influence how users interact with the application (if at all!), so you want to have a solid understanding of these three postures before setting off on your development journey.

Sovereign Posture

Sovereign posture is often associated with the monopolisation of attention. Applications which keep the reader glued over a stretch of time, like Instagram, Facebook or Tik Tok, are built on sovereign posture. Sovereign is your go-to for creating apps that provide a wide span of services and functions that are frequently used by customers.

Sovereign applications tend to be generous with screen space. Users find that these apps are constantly bringing them back, the visual design is minimal to strengthen easy navigation, and remain sovereign during use. This suggests that even when these apps are being run simultaneously with other “non-sovereign” apps, the sovereign app keeps a sovereign stance.

A good portion of readers will have experience interacting with the Microsoft Suite– Word, Excel, PowerPoint. Take PowerPoint for instance. While creating slides for a presentation, the application is left on full-screen for the duration of the design process, irrespective of other programs or resources you might need in the creation of your slides. This is one reason why you cannot engage two “Office” apps simultaneously.

As you design your app using the sovereign posture, keep in mind that your app will mostly operate in full-screen mode. Sovereign apps thrive on their easy-to-navigate features for the intermediate users. However, it should be a moderately simple experience for beginners or infrequent users to understand and use the application. Since the sovereign app user would be engaged with the app for a stretch of time, be careful to tone down the color brightness. You want to aim for something conservative. Do not hesitate to take up space. Sovereign apps are their rich visual feedback. Given that your toolbars and panels are smaller than usual, you can easily incorporate feedback and inputs into your app. At first, the beginner user might not notice the drop-down information as he hovers over a command, but as time breeds familiarity, they become an intermediate user and find reasons to explore them.

Transient Posture

Apps built in the transient posture are used to define a single task. Users of such apps leave the moment the defined goal is achieved. Think Uber:

1.  I need a ride

2.  Uber provide rides

3.  Open app

4.  Enter destination – App open

5.  Request a ride – App open

6.  Car arrives and takes you to the destination

Given their transient nature, the rate of users’ engagement with such apps is quite reduced when compared to sovereign apps (which users return to once they exit transient apps). Thus, in designing a transient app, the following questions should be tabled:

• How often would the user engage the app?

• What tasks are accomplished on the app?

• What habit am I trying to get my user to develop?

• How can you incorporate the elements of a transient posture into your design workflow?

Because most transient apps are only occasionally summoned, there is heavy reliance on the use of graphics and visuals. The workspace design is compelling with the use of colours and shades. While this might be a burden to the sovereign app user, transient apps need bold graphics to facilitate the user’s easy navigation. Since they are on borrowed time, the user must be quick in making selections. Bigger menu dropdown options are encouraged, with icons and well laid out menus serving as a guide, as the user is likely to forget the meaning of such icons when next they need to run the app.

An easy way to determine if your app would take a transient posture is to ask what services you render with it. If you would consider it transactional like food-ordering, ride-sharing or even banking, chances are the app is built in a transient posture.

Daemonic Posture

Daemonic apps have restricted interactions with users. They are oriented towards background processes and can be found running in the background. An app built on a daemonic posture would often run quietly and invisibly. When designing such programs, decide to be subtle in your use of visuals and icons. Daemonic apps, unlike sovereign or transient, must not be an affront to the user when finally summoned. Consider programs such as network connections, printer networks, and even clock widgets on your computer. These programs, though rarely summoned, are always waiting.

For your design, you would want to include buttons that support quick launches. Centralising the features of your daemonic app also aid in the ease of usage. Stay visible, but do not interrupt unless alerting the user.

Determining the right posture can go a long way to building an application that gains traction or costs you a lot of money. Your app’s posture allows you to focus on the behavioural changes you are trying to get your users to make.

The Hook Model

Lastly, in creating your app, you might consider using the Hook Model. The Hook Model is a system that revolves on the Trigger-Action-Reward-Investment technique, making a product addictive and habit-oriented. Triggers highlight the question, “What compels users to engage your app?” Triggers are the nudges, the sparkle, the pull that causes a phone user to tap on the app icon. When your app is built in a way that a user can identify a need which your app meets, the need-identifying element is the internal trigger of your app, the reason for developing the app. An external trigger relates to visual elements – for instance, the beep of a notification or a custom message from the app.

The action depends solely on the user’s willingness and ability to engage. A user could sign into an app like Instagram, desiring to create content or interact with available content, only to experience poor network connection, thus serving said user a blank page. As you develop your app, you should consider creating pages with minimal reliance on internet connectivity. Make sure there is an activity your user can engage with within seconds of accessing the app. Like on Google Chrome how it has the simple dinosaur running game, it keeps people engaged until the internet comes back online.

Anyone who uses your app wants to experience a subtle thrill of being rewarded. You find this in popular apps like Facebook (which awards Top Fan badges to users engaging with a Facebook page) and Instagram (which recently created the “pinned comment” option). You must identify the right type of reward for your app and ensure a user feels as though they earned it. When an individual experiences a minimal form of pay upon using your app, you create a desire to engage with it even more, a form of investment from their end.

In using the Hook Model, you may consider tabling answers to the following questions:

• What does the user want from your app?

• What need is your app meeting? Is it sufficient to compel engagement?

• Can the rewards nudge your app user towards frequent usage?

• Will the user be willing to return to the app?


The process of creating a successful, widely-used app relies on your ability to accurately position the application for a specific end-user. Sometimes the best way is to work backwards. As Matthew McConaughey said in his commencement to the University of Houston in 2016,

“the first step that leads to our identity in life is usually not, I know who I am. I know who I am. That’s not the first step. The first step is usually, I know who I am not. Process of elimination. Defining ourselves by what we are not is the first step that leads us to really knowing who we are.”

– what will make my app unused and uninstalled for the people who I want using my app. Once you can provide answers to the most important questions, you can commence the building of your app.