App Development Overview

Custom app development follows a lifecyle from concept through application deployment. Read on to learn about what to expect and review useful tips. You will be on your way to a successful app development project at Duke! 

 
iStock-832109622.jpg

DESIGN AND PLAN

 

#1

The Design phase includes both user design as well as technology design. This is the time when you explore, discuss, and decide on required features, technology integrations, and the audience for your app. Visual design is iterative, starting with low-fidelity wire frames and eventually becoming robust, beautiful screen design. 

A consultation with the Mobile App Gateway team can help you to refine your concept, engage with DHTS, and start the project approval processes during this phase. You are laying the groundwork for success. 

A few questions to consider:

  • Who are the main users of your app? How will this fit into their daily lives? 
  • What similar products have been developed? What would make yours unique? 
  • What is the ideal platform? Texting, mobile, web apps, and Epic tools, are all options with different costs associated.
  • How much will it cost to build what you dream?
  • What are the most important features? 
  • If your app will be used at Duke Health, who is your clinical champion? 

Planning to use Duke Health branding? Get it right by following these guidelines. 

If you are planning to issue an RFP for digital work, these pieces by Willow Tree Apps and New Media Campaigns provide helpful tips. 

Push notifications are a great way to engage or annoy users. Take a look at how to use them to enhance the user experience with this piece. 

Don't forget about collecting data on your user's app engagement. Take a look at Google Analytics

Do you want to work with an outside software developer? Contact us for vendors and information about contract approval processes at Duke.

Note: Contracts cannot be signed by individual PIs or Duke staff and must be executed by the Procurement office or the Office of Research Contracts.


iStock-846843298.jpg

DEVELOP

#2

Once you have identified a Duke- approved development partner, signed a contract, and determined any technical integrations you may need with Duke's data or software, you are ready to build or develop!  

Projects vary in timelines based upon complexity, but you should plan between 3-12 months, and your software development partner can estimate this for you. When considering timelines for your overall project, add in time for DHTS and IRB reviews before you can start distributing your app.

Building a content focused mobile app? Talk to us about the Duke Health Mobile Content Manager tool. 

If you are creating a website, refer to the Duke IT Security Office Web Hosting Policy. 

Are you creating a patient facing app that pulls data from the EHR to populate the app? Go to open.epic for FHIR API endpoints and access to a development sandbox. Duke Health employees can also find over 400 APIs on the Epic App Orchard. Outside vendors can join the App Orchard for a fee to access APIs, publish apps, and receive technical support from Epic. 

The Information Security Office at Duke has put together Mobile Apps, Devices: Information Security Suggested Language. Check this out as a starting place for consent language for research apps and your IRB application. 

Interested in using Duke's single sign on (SSO) so users don't have to create a new name and password? The documentation is available here. 


marc-mueller-210523.jpg

TEST

 

#3

It's crucial to do multiple rounds of testing of your application prior to release to ensure that the functionality works and the application is secure. 

Plan for a combination of developer testing, user testing, and security testing in your timeline. Developer testing is done by the vendor. DHTS recommends that vendors use Veracode to scan for security vulnerabilities. User testing is a great way to ensure that your application meets your engagement goals and delights your audience. Talk to the MAG team about how to run effective user testing sessions.

We also suggest the following user testing tools: 

  • Usability.gov has some great information on how to conduct user testing. 
  • Check iOS app accessibility using this tool and Android app accessibility with these guidelines
  • TestFlight is an Apple product that allows you to beta test your iOS app prior to submission on the app store. This is a great way to feel your way through your app and identify bugs or design changes based upon how the app will work in real life. 

When you are comfortable with your app performance, request a consult to set up a security review with the Duke Health Information Security Office. 

Finished with testing? You are ready to release! 

 


rawpixel-com-415585.jpg

RELEASE

#4

Congrats! You've made it! Your app has been approved, designed, tested, and built. You are ready to release it to your users. 

Distribution Methods: 

  • If your audience is only Duke community members, it can be published on our internal app store. 
  • To self-publish an iOS app, join the Apple Developer Program for $99. 
  • To self-publish an Android app, on the Google Play store follow these guidelines. 
  • Guidelines for submission to the Duke Health App Store can be found in our Box folder. 

Consider also how you are going to publicize your public app to attract users. Some tools you can use are:

  • Setting up social media accounts, for example, MS Mosiac is a national mobile-based research study and it uses Twitter to engage with the Multiple Sclerosis community (@Mosiac_MS
  • Creating a study webpage. OIT enables free website creation and offers Duke-branded templates. Check it out. 

 


ziwuqmznrvs-bench-accounting.jpg

MAINTAIN

#5

You've come a long way, and everything works perfectly. Unfortunately it won't stay that way forever. Browsers update, Apple and Android release new phones, and code becomes stale. Plan for maintenance fees (around 15-20% of the initial build cost) from the beginning to support your app through it's lifetime.

Discuss a maintenance approach with your contract developer or DHTS when you are negotiating your contract. 

We recommend discussing these topics when negotiating a maintenance agreement:

  • Who will be conducing the maintenance (will it be by the product development team or outsourced to another team?) 
  • How is this billed? Is there a retainer agreement or do you pay by the hour?
  • What happens if you need to add future features to the product? Is that included in maintenance or a separate contract?

To submit iOS app updates to the Apple App Store, use this guide, and for Android app updates to the Google Play Store use this guide.