Is there an easier way to understand how app and web development works?
Wonderment Apps offers two core lines of service – Managed Projects and Staff Augmentation. In either case, developers, product manager, project managers, designers, and QA engineers are collaborating to create a project that rise into the digital air like a skyscraper. This blog post will look at some of the foundational ways in which the Wonderment team is trained to execute on the processes that allow us to most efficiently construct solid structures that stand the test of time and millions of users.
Wonderment is a software development company, but we relate to our physical world counterparts as a combination of construction and architecture firm. Much like companies constructing physical buildings, we know that the highest efficiency in web and app project delivery comes when we complete the architecture (Product Development & Design) first and then follow with the construction (coding and web development). Having great digital blueprints makes it most efficient to execute on the app and web development work itself. Much like our counterparts, our product managers (the “architects”) make blueprints and help plan out the way of building needs to be constructed. They think about the materials that need to go into it. Once that is complete, the product and project management teams work together to create an organized breakdown of how all of that’s going to work. For this process, they engage the blueprints themselves, which actually draw out the way that the rooms need to be formatted – where the doors need to be, where the windows need to be. Much like architects need to think about materials and measurements, our Product and UX Design teams must to hear all the requirements of the digital building to construct from the right structure.
(NOTE: Information and Systems Architects are an actual role in the software development industry. For the purposes of the comparison made in this article, we will be relating physical construction “architects” to product developers and product managers.)
User Flows: Illuminating the Path
People flow through a variety of environments. For instance, in the case of houses they would move through the environment in a really smart and thoughtful way. Our digital layout is no different. Instead of flowing through a house, a person (“User” in the case of technology) flows through some kind of a digital product flow. They land on a Web site or an app to get to the conversion point at will ultimately allow them to reach a tool, transaction or experience they are wanting to get to. So, they need to be effectively guided through all of these different pathways get to what they are looking for.
Our Product Developers lay out all the kind of core parts that need to happen. These paths, they help us see where people want to maneuver through the environment to help accomplish the experiential goal they’re trying to reach. The paths also inform our QA team how they need to test usage and what potential issues they will run into. So, those pathways are really important.
Once we have the pathways, we think about all the kind of different rooms or landscapes that actually have to be put into place. We think about things like screen inventories – these are the tools needed to have a good idea of what the actual environment spaces that will need to be constructed.
User Experience (UX) + Wireframes: Creating the Blueprints
Once we have those, then we can execute on the blueprints. We look at the book blueprints in a way where we show everything from how the layouts fit together down to kind of the size and design details that will be included. Our product developers are very much like building architects, thinking about the way it all connects together.
The product developer’s blueprints by creating wire frames. They create really nice detailed wire frames that show how something is generally going to look and be laid out and engaged with. They also show the interactions through a toolset called app and web development annotations. Adding annotations in the wire frames communicate how a User should engage with the interactions. And then, at the end of it, the product developers have a very detailed wireframe that lays everything out. It acts as foundational blueprints – visual references – for people who have to construct this.
User Interface (UI) Design: Visualizing the Beauty
The blueprints are then usually put into some type of an interactive prototype that demonstrates the flow and some basic perspectives on interactivity. When the product developers are done with this demonstration, we have the interior designers come in and start to think about the look and feel. At this point, they knock through their concepts for visual design. And those concepts usually come in the form of mockups.
Mockups are examples of what it’s going to look like. They include the color palette choices, the shape of the buttons, and ocular experience of the interactive tools – how things will be felt when they are accessed. And the designers actually think about the concepts of those elements and lay them out into partnership with the skeleton of the blueprints. So, by the time a developer gets it, they can see what the vision is very clearly.
Information Architecture and Project Management
At this point, we bring in the construction firm. That team gathers all of the wireframes and flows together and hand off to the tech / construction leads that are involved so they can think about the high-level engineering challenges. These tech leads take the blueprints and concepts and they sit down to review the data architecture and then structures all of the data elements that are going to go into build to deeply assess the requirements for the foundation of the structure that’s going to be there. Much like the cement slab that supports a house, the core data layer supports the tech infrastructure.
Server-Side Web Development: Adding Structure
With all the core data elements in place, the tech team can start thinking about the way everything needs to fit together and become one unified piece. At this point, we bring in the server-side web development to assess what they are going to start building and define the actual kind of core components sitting on top of the architecture. These are the physical code that allow the application to talk to the data architecture. The server-side coding components plug into the data layer to collect the information being fed from the User and make calls to the database. In construction terms they are kind of like the wood beams that stand on top of the foundation layer blending together with the plumbing pipelines. They are anything behind the walls that help create structure or core functionality of the house.
Front-End Development: Constructing the Environment
The front-end developers are the team that focuses on the actual user experience. They are creating a foundation for the communication between the human experience and the foundational data layer. The front-end developers often work simultaneous to the server-side developers. In construction terms, you can think of the front-end developers as the team that addresses the spots our eyes view – things like laying the drywall on or putting into place the windows or doors. They drop the core design components into the application and make it usable for the Users that will engage with the application environment. The front-end developers look around a room and decide which window choice will be made, what door would be appropriate, how we want to execute on the type of floors to walk on. They decide on how to implement the visual components that have to be generated, and they lay all of those in the place as the structure of the building is executed on.
Binding & Services: The Bells and Whistles
Once both the server-side and front-end pieces are in place, we work to bind the two elements together. It’s very much like nailing everything in or putting the glue on. We put these things together and lock them into place. During this process, we also assess important additional third party to plug in or we examine a way to properly open up the house so other developers can build important pieces. At the heart of this process, we make sure our services, or our APIs, are well documented and accessible. A good way to think about it is that we expose the outlets in the walls, which are like where you plug in the electricity. Those wall sockets allow us to expose access to the foundation layer so that other things can plug into it – things that didn’t come with the house. A good example of this is the need to plug marketing tools into the website or perhaps you might need to plug in different types of kind of computational apps that will help with machine learning or other dynamic elements.
Quality Assurance: Inspecting The Work
Our quality assurance team is kind of like the Inspection team that comes in and reviews the construction work and the flows. The product team and the information architects envisioned how people should be able to move through an app like the architect and lead construction designer does for a house. In both cases they envision people being able to have this experience in this room and this experience in this room that’s actually like test that out and see what it looks like before we have someone move in.
After it is fully constructed, the QA (Quality Assurance) engineers go through and engage in tests of those approaches. They think about the nuances of the journey and inspect many of the required elements. If they find problems, they jot down notes and pass them back to the construction team to make the required revisions. These changes are usually small things get things a little bit cleaned up once in a while; however, there are times where they have to rip off a wall and fix some of the stuff that’s happening outside of view.
Beta Testing & Launch: Welcoming The First Visitors
Once the QA Team is finished with their inspection notes on the app and web development, the full tech and product groups comes to agreement that the build is done, and we open the house up. After the doors are open, we invite people in. We might invite our first group of friends to get a marker on the initial experience for the first time. And then we listen to their feedback is – “I like the way you put that plant over there.” “Wow, what an awesome choice in a fireplace.” We like to think of is like a Beta Testing group. The beta testing group is comprised of people that the Client either knows or they are prominent names in the industry. This group has a vested interested in testing the working environment. Additionally they feel that experience out and give some feedback that allows developers to make some minor further tweaks.
Once the Beta testing feedback is complete, we invite in that last group – your main audience. And inviting the main audience in is kind of like your big Welcome Home party. After the site is officially launched, everyone can come in and be really impressed by the work and craftsmanship. It’s the opportunity to stand back on the side walk and smile at the building you just constructed. Congratulations!