You are ready for an exciting journey of putting together the beautifully designed and thoughtfully planned web or mobile application project that is destined to load you with money and fame. The development team rolls up their sleeves and plunges into the depth of code, the QA guys sharpening their tools, and the PM ready to navigate the flagship to the epic battle for user appreciation.
However, by the end of the first week (or whatever reported period/development methodology you adopt), it just doesn’t click. Perhaps the project needs some time to sit in? Tweaking a couple undocumented things here and there, not a big deal. It’ll get better next week. It doesn’t though. Tweaks stack up, user stories get coated with comments, priorities get reprioritized, and more and more you get the feeling of being dragged into a shitstorm of distorted terms, features, duties, and intertwined dependencies.
All of a sudden everyone involved with the project gets caught up in a stalemate loop, expecting issues to solve themselves somehow.
If you ever felt like this in a project, congratulations – your app is on its own being. Did this happen because the idea sucked but you didn’t know? Or maybe the client is out of their mind? Or perhaps the team is unprofessional? Actually, none of those are likely to detect this late in a project. In reality, it’s the client’s inability to comprehend the depth of their project and the team’s desire to please that, makes a mess of a project regardless of its brilliance.
The Actual Experience
We have a vivid example of getting lost in an application rabbit hole. Our exciting journey down that hole was almost as exciting as the ongoing attempt to get out of it.
What started as a simple visual timekiller of an app with a 2-option interaction, quickly spun out of control, permanently eradicated a couple team members, and got lost in the woods. The parallel processes completely messed up the schedule and any trace of methodology. So what happened and most importantly, why did it happen?
Feature Creep
The initial idea is as outright as it gets. Usually, a client has the result envisioned and drawn on the whiteboard with a crown symbol next to it. However, the 2D process put on paper is only a small bit of the project, not even a blueprint. So once you start mapping features, you point out the main one as the core of your digital product. All you need to do is travel from point A to point B.
A little branch off here and there won’t do no harm. Until those branches become the project itself.
Suddenly a spin-off becomes an A-list feature that requires another feature and leads to the creation of a separate branch to the point where the original idea is nowhere to be found. Here’s an exaggerated illustration of a feature creep exemplified by the science fiction development flowchart.
Image credit: Brain Pickings
What most of startup owners and entrepreneurs are missing about their startup is the depth of the impact they produce by even the smallest alterations. A development team we can guide a client through the technologies and production details, but it cannot define the functionality of the app and its business logic. It’s the implementation of the client’s vision backed by analytics that we concentrate on.
Misunderstood Methodology
The widely accepted Agile development methodology suggests that iterative product development should allow the application to evolve in response to changes in business environment or market requirements. Building apps outside of the MVP contraption is a time-consuming process.
In the world of today where trends come and go within seasons, it’s extremely important to stay relevant and not deliver an outdated application.
Agile development addresses this by concentrating on the working pieces of a product more than designing and documenting features. In a way, this does help the client see the progress as the working features are delivered all the time. However, this process has its flaws of not having a reference to work towards.
Shifty and iterative development is easy to get lost in. Considering feature creep, iterating their implementation without documenting and cleaning them out properly is a risky road to take and it has taken a toll on us as well.
Agile is an umbrella for multiple development sub-methodologies and practices that are out there for a reason. Strong management, risk assessment, and big picture planning are the keys to a successful complexity implementation.
Solutions
I wouldn’t want to oversimplify things by saying that complex web/mobile applications are doomed to face adversity. Complexity is not an issue and in most cases, it is dictated by the application’s philosophy. Nevertheless, it’s the approach that allows features to creep in and methodology to collapse.
Often times a feature is considered to be the end result and we build the solution around these small results. The problem is when these results require changes they push changes like the domino effect. The specifics of development makes it extremely expensive this way, on top of prolonging the development circle. So how do we solve the iterative development problem?
Prototype
Many consider prototyping to be just a design process, following up on building an architecture/wireframing. As you will subsequently find out, it’s not. The development cycle usually follows a pattern of having features shipped as user stories. Some might have the design part ready, others don’t but what is a task has to be done, right?
So an app is assembled then improved, and then shipped, and then improved again. As the result you get multiple versions of the same app tweaked and changed at best. And at worst – bloated code that only the developers who wrote it can make sense of. So instead of implementing a finished concept, there is a danger of getting stuck in a loop:
This happens because the digital product won’t reveal itself even to its creator until it gains their respect. If you can tame the idea, stay focused and keep control of the project before you even have to code anything, you will enjoy the fruits of this labor. So where do the iterations happen? Is there a way to test features before putting them into life?
Prototype is a playground you need for all the shenanigans.
Basically, we allow design flow parallel with the business functionality in a prototype. We can zoom into any feature, map it out, locate the spots, prioritize them, and put them on schedule. Or zoom out to see whether the business logic of the main application feature remains true to principles.
This is the way a working prototype can help stay in the game of iterations without stretching your development resources too thin. People are used to viewing prototype is a powerful visualization tool but in the context of modern application development, what it really is, is a general app arrangement tool providing business logic design options as well.
How To Make It Work
The architecture of an app is a complex entity that can often impede your vision and not allow you think like a consumer of the product.
As a user-oriented approach means keeping in mind the idea of actually helping people accomplish something.
Get your flying start:
- Have a strong and universal product statement. If you can’t formulate what exactly your product does and how it helps – neither will be able the user.
- Create personas and scheme out the flow. You will be able to acquire a lot of knowledge concerning your audience once you try to systemize them.
- Put all you know in a wireframe. If you don’t know how to do that – get a professional to help you with that. The more complexity you uncover at this stage – the better.
Now let’s put some meat on the bones. User interaction is the strategic direction for any digital product startup. Anything beyond that secondary, so pay special attention to the options your users get in terms of their input, data processing, and the output they receive.
A great influence on the project success is the way it accomplishes its business goals and satisfies the stakeholders/owners. Their expectations have to be fulfilled and their business has to be developing due to the product. In that case, we can expect long-term partnership and project advances. All these interactions between users, the app, the owner, and the employees have to be defined, once again, prior to the first line of code. But what if the interaction happens on multiple levels?
An analogy that comes to my mind here is the tattooing process. Whenever a tattoo artist does a major piece, they never dig into details on one tiny spot. Instead, they assemble the tattoo from multiple sides. This way the pain gets stretched and doesn’t go deep while the artist can also zoom out and look at the big picture.
Bottom Line
The reason why applications get out of control is the fundamental illusions of how the project development cycle works. A client’s desire to see a working piece of their product is sometimes so strong, it messes up the entire process. The issues and the new features that pop up here and there are inevitable, however, you can weather the storm and control them.
The best way to keep tabs on a project without overextending yourself is letting the prototype be a feature induction stage. It is always better to have a map than go by feel. Master professional prototyping and kill the game.
