Supporting Digital Project Goals for Web & Software Development

We feel we provide a great opportunity to partner with many innovative companies because of the way our philosophy about design and development aligns with situational needs. For starters we believe that a large project undertaking (in terms of time and scope) requires thinking of it as two separate components. 

The Two Components of Digital Projects

The first component is the discovery, research and strategic recommendations that will help you fully realize the scope you need to build. This will help to draw out information from your organization and multiple departments, making an upfront investment in building the foundation of the relationship to truly understand the pain points and business value goals. In this stage we truly challenge you and your team as a business, in order to advocate for making the right decisions. This includes the root of decision directions and how that ties back to measurement of overall KPIs. 

These conversations will help to uncover why specific integrations are being utilized. And while never trying to reinvent the wheel, we aim to confirm whether continued use of them is the best path forward or if identifying another opportunity provides a path of lesser resistance. We not only take into account the benefits of one tool or software over another, but the shimmer effect it has on an organization in terms of legacy usage, opinions, retraining and technical debt. 

Only after fully flushing these ideas and features out into a finite architecture and scope that detail how operational teams within your organization are affected, then should focus be turned to executing. This execution can be more commonly thought of as the primary outputs of a redesign (that you are aiming for). They are the wireframes, the designs and the developed features, functions and pages that your customers will interact with and your team administer through. They are the external integrations from ERPs, CRMs, Google Analytics and a myriad of other scripts for software being leveraged. 

Our goal throughout the project is to unearth answers to questions that are often left dormant. We are not a feature or function factory that blindly builds out requests. We aim to adhere to best standards in design and development. And that most importantly accommodates for best practices in development, creating out CI / CD pipelines, writing automated tests that reduce error backlog and / or downtime and overall training of the system in order to most efficiently utilize the inherent features. 

How does that fall into service buckets we offer?

Below we have detailed out the main components and a description of how what we know of typical digital projects thus far would apply. While we have had a myriad of experience with all types of clients executing on what you may technically need designed and developed, we believe our true differentiator is the focus and expertise we possess in terms of consulting you and your organization and applying the human perspective to these communications.

Strategy

• Workshops & Outputs
• UX Flow
  • Outline the actual desired UX flow as related to the user types / personas on the site. This is created for both your end users (web visitors) and your internal team. This UX flow is then combined with other research and strategy components to overlay on the the site mapping, content mapping and wireframes being created. 
• Clickable Prototype
  • Each UX flow is detailed in a single prototype in order to help start to combine finalization of data modeling and data mapping. These are used to help guide scope and development-centric estimations or features, functions and time blocks. 
• Site Architecture
  • The technology STACK, the communication hierarchy and the system architecture of how all the parts fit together into one cohesive unit. This will be preceded by many discussions about technology, DevOps and SysAdmin expectations and needs within the organization.
• Features & Functions
  • A listing of features and functions related to their business value and perceived priority ranking. This feature and function list is then phased into the sprint planning for development. 
• Operational Usage Plan
  • A plan based on discussions with key team members and divisions that are touching the final product. Who is interacting with the system? How are they interacting with it? Many of the biggest complications that come up with projects are individuals not knowing how to use them (or us as an agency not understanding how your people plan to utilize the final product). Therefore a large part of our output in the strategy phase is to put forward a plan of who is intending to interact with the system, and in what ways (both technical and non-technical). This plan helps to add flavor to any additional features, functions, user permissions or project considerations that should be made in order to build a successful end product. 
• User Permissions
  • Setting up the user roles and profiles that will perpetuate the system being built. This starts with the UX Flow detailing each user type we see in existence and what overall access they have. Understanding how roles / access differs by department and job title as well.

User Experience (UX)

• Research / Data Review
  • Gathering and review of all existing data that can help to inform decisions for the redesign and rebuild of the website. Going through this data to establish real KPI metrics that are meaningful to the organization and to truly define the achievement of success in the project. This will include any web visitor data you have, heat mapping, customer service statistics, surveys and other informational data about the business and the end users.
• Personas
  • involves breaking down the target market into individual personas so we can get inside the minds of the people that will be interacting with the brand to determine their current frustrations, goals, motivations, characteristics, personality, and other brand interactions.
• Site Mapping
  • The creation of a sitemap based on UX needs that helps to identify unique layouts and overall connection points.
• Content Mapping
  • The process whereby initial instructions are given to the client in which to brainstorm with LLT and provide raw content mapping based on the sitemap confirmation. We then work hand-in-hand to provide documentation for recommendations back on sections and aesthetics for each section of the website, split up by page. 
• Wireframes
  • Summarizing, outlining and sketching ideas into a rough-reality with closer visual representation of the content strategy and project as a whole. Factoring in variables and logic to help bring the abstract ideas to fruition within design and development.
• Data
  • Data Layers
    • Understanding the strategy of how data currently perpetuates throughout the system and if that flow is optimal. This includes reviewing how data is being used, what data is being collected and the end uses / integrations for where this data is leveraged. This most commonly includes discussions about whether all sources of data are being combined and linked to UX / UI journeys of individualized users. A plan is then created in order to make sure all data is being tracked, collected and outputted according to higher level business and organizational goals. 

Experience

The main components of “experience” leveraged for digital web projects from our services are the thoughtful creation of high fidelity mockups of the new website and software components (UI / Web Design), the video and photo to pair with the UI (Visual Media) and the messaging that gets carried out on those pages and through your digital brand (Content).

• User Interface / Web Design
  • More commonly thought of as “Web Design” these are the high fidelity mockups and layouts that will visually be showcased to your website visitors. This would be the final visual output of the UX / UI process. UI Design includes aspects of graphic design and illustration that would need to be identified and custom created for the site. UX (User Experience) strategy specifically as it pertains to website flow would feed into the look and feel we would create for the pageviews. 
• Visual Media
  • The video and photography that is utilized and / or created to help bring through the overall message of the brand. Our goal would be to sit down and understand the existing Visual Media Content strategy and from that to recommend a path forward that would better translate to a digital form on the website. We would work to understand your production team / capabilities and where we could step in to help.
• Content
  • The actual content that sits on your web pages, but gets rebuilt from a mix of what you are currently have and where you are wanting to go in terms of brand messaging. This includes content strategy based on sitemap considerations and some in-depth conversations about messaging gaps that exist and how we believe those can be overcome going forward. 

Development

Two distinct service buckets are utilized within development for most web projects: CMS development and Software development. We imagine viewing each as a separate business case to gather requirements and build from (versus assuming from the beginning to “build them as one”). While the communication and connection between the CMS and Software developments will be seamless, the unique needs of each individual on your team it will be servicing lends itself to addressing separately to start. 

In either case we would establish best practices, documentation and CI / CD pipelines. This would be intertwined with our understanding of the DevOps and SysAdmin plans and how (and if) your team will be taking over maintainability of any component of the codebases or any future state development. 

• CMS
  • The ideation and creation of a system that can help centrally manage all of your content that you currently have to distribute and will have in the future. Our first goal is to assess the pain points that exist within the management and publishing of content. From there we will challenge the assumption of “fitting” you into a given CMS, learn how team members expect and require to use the system and any future-state cases that might be known in the pipeline. We imagine multiple solutions exist in any case and will largely be guided by technical debt existing, legacy stickiness and overall business value provided by a CMS solution. With some ideas being the continued usage of the legacy CMS, the introduction of an API-based CMS (such as contentful) or if enough evidence supports the cause a switch to another well-known CMS platform that better fits overall team needs.
• Software
  • The coverage of non-CMS integrations and the building / management of unique features that are best served by software development. With each potentially be built as a separate web application (i.e. microservice structure). We imagine this software bucket would use non-CMS technologies as the feature and functions needed to accomplish the use cases would be limited in many of the known technology environments that CMS-based platforms utilize. Leveraging AWS or Heroku hosting our recommendations would center around much deeper technical discussions with your team to gauge preference and openness to change. The technology that immediately comes into focus and solves many of our client’s first couple phases of issues is Ruby on Rails. However; discussions about database usage and connecting those to possibly using Node or React are also on the table for consideration. Similar to our CMS process, our Software process is based on needs assessment and heavily influenced by workshops we hold to finalize scope and desired business cases.