We Create Interactive Experiences

FOR BUSINESSES, MEDIA AGENCIES, AND HEALTHCARE ORGANIZATIONS

Transcending Digital can help you create custom solutions that improve processes. Our strategy involves a mix of custom programming, workforce assistance, and business analysis.
We are experts in the latest technologies, including:

  • HTML/CSS/Javascript
  • ReactJS/NodeJS
  • REST API Creation/Integration
  • C#/Java
  • Electronic Payment Integration
  • Drupal Content Management Systems
  • Databases
  • Unity3d
  • Media Server Programming

Custom Interactive Programming

INCLUDING KIOSKS & PUBLIC DISPLAYS

We work with media agencies, businesses, and designers to create solid systems and rich interfaces.
Recent collaborations include:

  • Adobe
  • Medtronic
  • Hershey's
  • Nintendo
  • Hasbro

Healthcare Services

CERTIFIED BILLING STAFF

Transcending Digital maintains certified professional medical billing and coding staff. We assist local healthcare organizations with revenue management and work flow processes. We work together with clients to create solutions that improve the organization. On-site consulting is available.

About

TRANSCENDING DIGITAL LLC

We were founded in 2011 to service creative agencies and businesses in need of custom kiosks and public displays. Since our inception we have also expanded into the enterprise with collaborations focusing on healthcare and trade shows. We work with a small group of returning clients that value flexibility, solid work product, and high quality craftsmanship.
Our values include:

  • Never stop learning
  • Honesty and transparency
  • Deadlines are paramount
  • Extensive testing strengthens solutions
  • Family is important

Learn

Ideal Stages of a Software Development Project

For almost a decade, Transcending Digital has been working with creative teams to deploy premium software experiences across North America and Europe. Throughout this tenure an ideal step by step process has emerged for creating solutions that not only satisfy the business requirements, but most often go above and beyond. This strategy will work for kiosk and experiential applications as well as enterprise level applications. If desired this process can be utilized in an agile environment. The list of ideal steps that we like to use in a software project are as follows:

  1. Proposing or Brainstorming and Deployment Information Gathering
  2. Rough Sketches
  3. Wireframes
  4. Stakeholder Feedback Based on Sketches and Wireframes
  5. Formal Design
  6. Design Feedback
  7. Software Development Starts
  8. 1st Software Delivery (Alpha Delivery)
  9. Feedback Period and Design Adjustment if Needed
  10. 2nd Software Delivery (Beta Delivery)
  11. Feedback Period and Minimal Design Adjustment if Needed
  12. Final QA
  13. Final Software Delivery / Install
  14. Post Delivery Training
  15. Support

This list may seem daunting, but it ensures all stakeholders walk away with positive results. Depending on the type of project, some of these steps can be substituted or removed. We will now take a look at each step in detail.

1. Proposing or Brainstorming and Deployment Information Gathering

We mention Proposing or Brainstorming as the particular situation will be dependent on your business situation. The process in this step is the same for all situations. This is where you will come up with ideas about the desired software to create. Put your most wild ideas on the table and make an exhaustive list of all of the functionality you would like from the application or experience. After you have created your exhaustive functionality list, it is a good idea to start gathering information about how and on what hardware the software will be deployed. It is a good idea at this stage to also start thinking about application intent and goals. This will help eliminate non applicable functionality from the initial brainstorming process and refine the concept. Once you are confident the conceptualized software can be deployed to your target environment it is finally time to move on to step 2!

2. Rough Sketches

Rough sketches are a wonderful way to further refine ideas generated in step 1. Depending on the organization this step could be combined with step 1 or eliminated entirely. More experienced teams may wish to move straight into wireframing. At Transcending Digital we usually sketch using paper and pencil or on white boards. Charles, our Principal Software Architect keeps a notebook with sketches. A notebook with sketches will allow future reference to original conceptual intent during the programming and design phases.

3. Wireframes

Wireframes are similar to process flow charts used for business planning. They typically illustrate the entire visible layout that a user interface will be comprised of. You may be able to use step #2 sketches in place of wireframes if you sketch out the entire user interface. It is important that you do not skip the process of sketching or wireframing the user interface. This sketch will be given to designers and software developers. Often in Enterprise environments, user interfaces are created that contain way too many confusing buttons or forms. Confusing user interfaces can usually be attributed to skipping the sketch or wireframing process. Here is an example of wireframes for a simple full screen user interface that preforms the following:

overview image


A. Has an attract loop video that users can touch to continue.

attract wireframe 1


attract wireframe 2

B. Allows the user to take a photo.

take photo wireframe

C. Confirms or denies the photo.

take photo confirm or deny wireframe

D. Option to Email the photo.

email the photo wireframe

E. Conclusion.

conclusion wireframe

4. Stakeholder Feedback Based on Sketches or Wireframes

At this point it is a great idea to solicit stakeholder feedback if possible. Once formal design starts in #5 the ideas and concepts become much more costly to change. The wireframes or sketches will give stakeholders something concrete and not conceptual to visualize. Wireframes can be quickly changed or added to depending on solicited feedback. It can also be helpful to request software development feedback to ensure the capabilities described are possible.

5. Formal Design

Formal design is the process of obtaining an actual graphic designer or design team to create beautiful original graphics. Depending on the budget, developer skill set, and software requirements, formal design may be skipped. If the application relies on a visual user interface it is advisable to have some sort of formal graphics created for use in stakeholder feedback solicitation. At this stage, other media assets may also need to start production such as original videos or narration.

6. Design Feedback

This is another critical feedback step. Before actual software development begins in #7 it is important to get approval for the created designs. It is important to not skip this step because the design is fresh in the designers mind. Providing feedback at this stage will make it more cost effective for a designer to correct any issues before their role in the project is completed at the conclusion of this step. In rare cases, the designer may need to create more graphical elements at a later time but that tends to be an uncommon occurrence unless application scope changes late in the process.

7. Software Development Starts

We have finally made it to the start of software development. Designs, wireframes, and any supplemental sketches should be provided to the developer(s) so that they can create the software. The development team should coordinate with project managers to outline a timeline and scope of features for the first software delivery in step 8. The initial software delivery may not be a complete subset of all desired functionality. It is important to try and ensure that the most critical functionality makes it into the alpha delivery if possible. An agile development process can be implemented here with project managers. However, over use of "stand-ups" should be avoided unless the development team is inexperienced and requires lots of feedback and support. Stand-ups are short meetings that in general if not implemented correctly waste time. A good time for stand-ups are in the two weeks prior to a major software delivery.

8. 1st Software Delivery (Alpha Delivery)

The development team should provide a working software build for review on a determined date. If special hardware is being used it may be a little more difficult to review the actual software. If utilizing special hardware, at minimum videos should be provided for review. Cases requiring videos could include software that incorporates environmental sensing technology like the Kinect, special projections, monitor arrays, access to simulated networks, or assets to name a few.

9. Feedback Period and Design Adjustment If Necessary

All stakeholders should be involved in the alpha delivery feedback. This is the most flexible time in the software development lifecycle to implement changes. It is important to collect consolidated feedback from all stakeholders and deliver it in one round. If feedback trickles in piece by piece it does not allow an effective and efficient response to changes. Feedback that is not organized and consolidated can also include hidden contradictions wasting time and money of all involved. If the feedback raises the need to refine graphics, the graphics production team may need to become involved again at this stage if the development team cannot handle the changes on their own. A work schedule and deliverables should be agreed upon by all parties for the next software delivery.

10. 2nd Software Delivery (Beta Delivery)

The beta software delivery should include mostly complete functionality. The only exception to a beta delivery with non complete functionality should be late Alpha feedback or an overly aggressive schedule. This delivery should provide stakeholders with an opportunity to see an almost completed project. This version could still contain bugs that must be fixed. You should aim to break software during this review to ensure that all errors are found.

11. Feedback Period and Minimal Design Adjustment if Needed

After the Beta software delivery it is again important to obtain feedback from as many stakeholders as possible. If approvals were delegated for the software project; now would be a good time to pull in the big boss to look at an almost completed project. In an ideal scenario any feedback at this point will be minimal. If the project has significant changes at this point, it may be a good idea to include a 2nd Beta software delivery before the final delivery if possible. Adding or modifying significant functionality at this late stage will increase the risk for bugs dramatically. Typically when a software development project starts, a developer will plan out a structure for the application that attempts to organize and simplify the code. Programming will follow this structure as much as possible. When changes are introduced late into a project the likelihood of it breaking the structure can increase significantly. Certain programming organizational techniques can help mitigate late breaking changes but not eliminate them. It is especially risky to introduce late changes with a junior team as they may not be as familiar with reducing risk related to late changes.

12. Final QA

QA in this context stands for “Quality Assurance”. This step involves thorough testing of all software to ensure that it is as bug free as possible. With a junior team it may be wise to introduce an additional round of QA earlier in the process to help isolate bugs sooner. However, if working with an experienced development team this is the ideal time to commence quality assurance. If no formal QA staff is available this is a good time to enlist any testers that can be found. The objective is to break the software. Make sure to thoroughly document the steps taken to cause an error if any are found. Video or photos of the process to create the error will be helpful so that the development team can re-create and correct any errors.

13. Final Software Delivery/Install

At this juncture it is time to preform the final software delivery. Depending on the job this could entail many things. It may involve traveling to a customer location to physically preform an installation. It could simply involve deployment of the software through a distribution platform such as an app store. Or, it may entail a production deployment with multiple levels of staff on standby. In any case, this is the big moment for the project. The culmination of all of the hard work. It is possible that unforeseen problems could show up during the production deployment. Usually it is best to plan for problems, then celebrate if there are none. It is critically important to schedule a buffer around this final install to provide a shakedown period of at least a week. In the context of an Enterprise this would mean having hands on deck for any problems that could show up in production and a rollback contingency. In an interactive context this means that any opening events should be scheduled at least a week away. In no circumstances should a final install be scheduled near a holiday.

14. Post Delivery Training

While the project is still fresh, post delivery training should take place immediately. Everyone will be exhausted but this is the perfect time for training. This is also the perfect time to complete any required documentation regarding the software project. Make sure to allocate time within any schedules for this critical step. Proper training will reduce support and help to resolve any hiccups for operations staff.

15. Support

The project is finally finished! Now it is time to be prepared to offer timely support. The most experienced software developers can certainly reduce the amount of support; but very few projects can escape the need entirely. Ask yourself the question. Have you ever needed support for your Apple device or Windows OS? These are billion dollar companies and even their products require minimal support. Support resources should be allocated to each project. Support is one of the most critical aspects of a successful deployment and should not be taken lightly.

Contact Us

LETS TALK!

Transcending Digital is a United States, Michigan based company.
We can typically turn around estimates within a few days.

Transcending Digital LLC
503 Mall Court #156
Lansing, MI 48912