Focusing the Effort

This is Part 1 of a case study which examines the positive outcomes of prioritizing and investing time in design before the development phase. The case study itself is built upon actual development of a small (S) sized feature in an existing Android native mobile application. It shows how design first workflow results in better user experience, streamlines and simplifies the development phase and creates additional positive byproducts along the way. Part 1 of the case study is an exploration into how we usually work and how our workflow can be improved by adopting a structured process. Part 2 (to be released) is hands on implementation of the suggested workflow on an actual feature development.

Disclaimer: No AI was used for writing this article.

Our Work Is Complex

Digital product development is fluid, creative and complex

As many of us have experienced, digital product development is fluid, creative and complex. Most digital products are intended for human users and therefore user experience is of high impact on product adoption. As we know, it takes effort to design intuitive user flows and it also takes effort to write clean and maintainable code. This is especially true when dealing with mobile applications where single codebase tends to contain code dealing with UI, presentation, business, data access and persistence logic. Despite this complexity, once we have a new idea or feature request, many of us tend to rush into implementation, without giving proper thought to design.

The problem with this is that by using this approach the quality of the end product degrades. The more design and development phases are overlapping (or missing), the less we are able to properly think about either of the phases. We are unable to create intuitive user flows, properly apply business logic and write high quality maintainable code all at the same time. This is true for individuals working on small tasks and for teams working on bigger projects.

Another problem we all have experienced when working in a team is unclear requirements for development. The gap between design and development is a grey area where most miscommunications occur. Without properly conducted and documented design, abstract requirements can be misinterpreted during development. Design and business logic decisions are done ad hoc by developers and in many cases development effort is swayed in a wrong direction.

So how can we achieve good user experience, intuitive user flows and high quality code? One of the answers to this question is increased awareness of process. Many see process as the connection between people and technology that drives successful implementation and utilization of resources. In relation to software development, proper software development life cycle is the link which connects development teams and digital product excellence. Let's examine how higher awareness of structured process can take existing individual or team skills to the next level.

That's Just The Way It Is

In my personal opinion, feature size does not affect the natural phases we go through when developing new functionalities. Even when working on a small or extra small feature in an existing codebase, we naturally do the same things over and over. Sometimes we are not even aware of the phases we go through and do not recognize when one phase ends and another starts. Depending on how much time has passed since you last wrote code, the following sequence of events might seem familiar. While describing the sequence, we'll attach distinct labels to each of the naturally occurring phases:

There is a feature request coming from users or an idea for new feature pops into mind. It seems like a useful feature to implement and users could actually benefit from it (Initiation). After thinking about it for a while, we decide that this would be a good candidate to work on next. We think about how challenging this feature is, when we can start working on it and how much time this feature would take to complete and release (Planning). We briefly think and ideate about the different ways this feature can be implemented, where it can be incorporated in the existing codebase, what other functionality it might affect and how the end state might look (Design). We start feature development, browsing through existing codebase and thinking about which classes need to change. Various questions arise such as what frameworks to use, how to display information to users, which business rules apply, how to persist data, etc...(Design/Development). Without proper testing infrastructure or workflow, testing is a matter of engaging the new functionality during development, usually trying out the sunny day scenario (Testing). The final artifact is built and delivered to the end users by using the appropriate delivery platform (Delivery). Users engage the new feature and in the best case scenario provide feedback (Maintenance/Operations).

It is helpful to realize that order and essence of the steps do not change, whether it is an individual working on a small app, or a team working on a bigger scale project. The difference is that instead of everything being in the mind of one person, the responsibilities for the various phases and steps are dispersed among additional team members which undertake one or more roles depending on team size. Although each of the above phases is important, I would like to focus on design and consecutive development phases and the link between them.

Focus, Byproducts And More

Though we can instinctively understand that applying a method to any set of repeatable activities can increase efficiency and order, there are additional benefits which we can experience. To grasp the advantages of applying a structured process to a repeatable set of tasks, let's take a look at some of the obvious among them. By clearly defining, documenting, communicating and following the same sequence of steps, below benefits can be obtained:

• Consistency and predictability
• Well defined inputs and outputs
• Elimination of chaos and confusion
• Enhanced team synchronization and communication
• Focus of effort on a single task at a time
• Optimization of efficiency and productivity

When applied to software development, in addition to the above general advantages, we get specific benefits and byproducts which have positive effect on overall feature implementation. Those specifically derive from a properly conducted design phase which is an integral part of the software development lifecycle:

• Documentation is created along the way
• Enhanced user flow and experience
• Development phase time is shortened
• Fewer changes during development phase
• Implementation is more aligned with end user needs

So how can we experience the above benefits in our workflow? The answer to this question is first to raise our awareness to the natural phases that we follow during the development lifecycle. Once we are aware of the phase we are currently in, we must focus our effort only on the tasks which are relevant to the current phase. By applying known best practices while engaging in the various steps we are able to experience the positive value they produce.

Try next time

• Try being more aware of the overall development lifecycle
• Notice the distinct phases
• Make a note of the current phase and its goals
• Understand phase inputs and outputs
• Focus only on steps related to current phase

From Story to Solution

From story to solution: sketching the design

Numerous articles and books have been written about the design phase. It is an iterative and creative process which consists of multiple steps. In essence, we can start with User Stories which make us shift the perspective and start thinking about what end users really need. By understanding user goals we are able to understand the desired functionality of the system and create intuitive flows which users can follow to perform their actions. Next we can create "Use Cases" to formally document user interaction with the system, integrating the various business rules along the way. Then we can design "User Flows" to further ideate and clarify the paths users take when using the product. Reviewing the solution with stakeholders allows feedback to be applied before actual development starts. Finally we should create technical specification which describes how to actually implement the desired functionality. It is important to separate the functional from the technical specification because they deal with totally different aspects of the design phase.

By sequentially following the different steps of the design phase we gradually translate abstract user requirements into a technical specification which can be efficiently used by development teams. This journey makes us think over system functionality as experienced by the end users, experiment, make changes, adjustments and improvements without writing a single line of code. It is important to take the time and create formal documentation along the way. (There are many templates and guides available online which can assist us in making this a little bit more organized).

Try next time

• Write down requirements as User Stories
• Document the desired functionality as a Use Case
• Describe business rules which apply to current flow
• Create visual documents such as diagrams and charts
• Ideate, create and visually document user flows
• Validate solution with stakeholders
• Follow up with a technical specification

Faster Development

The road to faster development

By now we should have a pretty good understanding which artifacts are created during the design phase and available for us during development. By following the various diagrams, explanations and documentation the development of the feature is now straight forward. Equipped with high quality functional and technical specifications, we as developers can concentrate our effort on what really matters at that phase: writing high quality modular and maintainable code instead of figuring out abstract customer requirements. Not only the development process is much faster, but the code is also of much higher quality. It is needless to say that the described process is repeated in an incremental and iterative manner for every new feature in accordance with Manifesto for Agile software development.

Try next time

• Do not start development if no formal written solution exists
• If it does not exist, create one and validate it with stakeholders

Part 2 of this case study (not yet released) examines how the structured process can be applied to development of a small feature. It also explores the benefits of creating and documenting a clear solution before actual implementation.