The document provides information about understanding an app that was built by someone else. It discusses the benefits of assessing the app objectively without attachment. It outlines a process for understanding the original design intent, architecture, and how people are using the app. This includes reviewing documentation, interviewing users and the original builder, and examining the table relationships and field usage. It also discusses assessing whether the app meets the current needs and deciding whether to modify the existing app or build a new one. The document stresses the importance of documenting findings and implementing change management to track future modifications.

2. Understanding an App You
Didn’t Build
Marykate Gass
Sales Engineer, Intuit QuickBase

3. #EMPOWER2015
Marykate Gass
• Sales Engineer at Intuit QuickBase.
• Marykate previously worked as a Mechanical Engineer designing hardware for Helicopter Jet
Engines. She soon noticed she was a bit more outgoing than the other engineers and
decided she wanted a more customer facing role. She has been working at Intuit QuickBase
for the past year.
• Marykate lives in small town in Northern MA with her husband. They are expecting their first
child this September!
Bio

4. #EMPOWER2015
① Why Adopting an App is a Good Thing
② Understanding the Existing App
③ Assessing the Existing App
④ Documentation/ Going Forward
Agenda

5. #EMPOWER2015
① A Process for Understanding Apps You Didn’t Build
② A Process for Assessing an App’s Usefulness
③ Empowered to Control Change Management Going
Forward
What are the Benefits?

6. 1 Why Adopting an App is a
Good Thing

7. #EMPOWER2015
Only 1 Reason… You!
• App builders tend to be too close to their app
 Difficult to be objective
• You have no attachment to the app so…
 You can assess it objectively
 You might be more open to new ideas

8. 2 Understanding the Existing
App

9. #EMPOWER2015
① What is the Original Design Intent?
② What is the Architecture?
③ How are People Using the App?
Where Do I Start?

10. #EMPOWER2015
What is the Original Design Intent?

11. #EMPOWER2015
What Do I Want To Know About Design Intent?
• Design Intent: The definition of how the owner expects the system to perform
• Every App addresses a particular problem
• The Problem Statement
 The original problem statement
 Understand if the problem has evolved

12. #EMPOWER2015
• Knowing the design intent will allow you to accurately assess the App
Why Is Design Intent Important?
Projects TasksCompanies
Projects Tasks Companies
Projects
Tasks
Companies

13. #EMPOWER2015
• Talk, talk, talk!
 The Original App Builder
 Stakeholders
 Users
How To Determine Design Intent?

14. #EMPOWER2015
What is the App Architecture?

15. #EMPOWER2015
Start With the RelDiagram!
• What is RelDiagram?
 Formerly a QB employee ‘super power’
 Will be available after June release
 BUT… You can get access now!
 Aren’t you glad you came to this presentation!
• A Quick way to visualize the tables and
relationships
 Provides broad understanding of app architecture
 Quickly determine potentially key tables
 Quickly see quirks in the architecture
This information is intended to outline our general
product direction, but represents no obligation and
should not be relied on in making a purchasing
decision.

16. #EMPOWER2015
How do I use RelDiagram?
?a=reldiagram
• Prior to June release
 When on Home page of app, type ?a=reldiagram at the end of the URL
• June release will provide further details on the in-product functionality

17. #EMPOWER2015
3 Things to Pay Close Attention To
• 1. Multiple relationships between two tables in the same direction!
• Ask…
 Are these all REAL relationships?
 What information is being passed
over?
 Is this correct or should changes
be made?

18. #EMPOWER2015
Are These All ‘Real’ Relationships?
• How do I check if all relationships are being used?
 Run a report to see if all relationships are being populated
• In this case, only one relationship is being used
 Delete the other 2 relationships for clarity

19. #EMPOWER2015
What Information Is Being Passed Over?
• Valid use cases do exist
 Projects could have a contact person, a consultant, a financial contact etc.
 All information could be originating from customer’s table
 Want to see if information is going into different fields

20. #EMPOWER2015
3 Things to Pay Close Attention To
• 2. Multiple relationships between two tables in opposite directions
• Ask…
 Are these all REAL relationships?
 What information is being passed
over? Passed back?
 Is this correct or should changes
be made?

21. #EMPOWER2015
Are These All ‘Real’ Relationships?
• How do I check if all relationships are being used?
 Run a report to see if all relationships are being populated
• In this case, only one relationship (Projects  Tasks) is being used
 Delete the other relationship for clarity

22. #EMPOWER2015
What Information Is Being Passed Over?
• Valid use cases do exist
 Perhaps trying to pass up information on current task

23. #EMPOWER2015
3 Things to Pay Close Attention To
• 3. Circular relationships
• Ask…
 Are these all REAL relationships?
 What information is being passed
around?
 Is this correct or should changes
be made?

24. #EMPOWER2015
Are These All ‘Real’ Relationships?
• In this case, Customer  Customer
relationship is not being used
 Delete for clarity
• In this case, Customer  Task relationship
is not being used
 Delete for clarity
• How do I check if all relationships are being used?
 Run a report to see if all relationships are being populated

25. #EMPOWER2015
What Information Is Being Passed Over?
 Perhaps customers refer other
customers, and you want to track this
 Perhaps trying to use conditional drop down (pick
a customer and see all projects for that customer)

26. #EMPOWER2015
Going Beyond the RelDiagram
• Why isn’t the RelDiagram enough?
 Cannot determine what information is on what tables
 Cannot determine what information is being moved
between tables
• RelDiagram is the starting point but a full
diagram will be your road map

27. #EMPOWER2015
How to Diagram (AKA Creating your Roadmap!)
• Write it down
 Paper
 Whiteboard
 Online Whiteboard
 Napkins (if you must!)
• Write out each Table
 Note the information being captured (specific or generally)
 Note the relationships between tables
 Note specifically what fields are being passed between tables
Customers
• Customer Name
• Main contact (title,
contact info)
Projects
• Project Name
• Project Info (dates, status, PM)
• Financial Performance
• From Customer Table
• Customer Name

28. #EMPOWER2015
An Example Diagram (For Complete Project Manager)
Customers
• Customer Name
• Main contact (title, contact info)
Projects
• Project Name
• Project Info (dates, status, PM)
• Financial Performance
• From Customer Table
• Customer Name
Tasks
• Task Name
• Task Details (assigned to, project phase, priority)
• Time Plan (start date, duration, projected finish)
• Financial Performance
• Status
• From Projects Table
• Project Name
• PC
• Project Manager
• Project Status
Documents
• Document Name
• File
• Document Description
• From Projects Table
• Project Name
Expenses
• Expense Summary
• Expense Date
• Purchased by
• Amount
• From Projects Table
• Project Name
Team Members
• Team Member
• Title
• Contact Info (email, phone)
• Hourly Rate
Time Cards
• Time Card Date
• # of hours
• Time Card Cost
• Notes
• Document Description
• From Tasks Table
• Project Name
• Task Name
• From Team Members Table
• Team Member (user)
• Team Member- Hourly Rate

29. #EMPOWER2015
How To See If A Field Is Being Used
• Check the field usage tab
• Consider adding help text to guide your users

30. #EMPOWER2015
How Are People Using The App?

31. #EMPOWER2015
What Roles Are In Your App?
• Look at the types of roles in your app
 Do the Role Names match your company’s vocabulary?
 Note any restrictions on permissions
• Look at Users table
 Are each of the defined roles being used?
 Note who would be good interview candidates

32. #EMPOWER2015
What Dashboards Are Assigned to the Roles?
• From the Roles page, note the dashboards
 Do some roles share common dashboards?
 Then why are they different roles
• Look at each dashboard to understand
the elements
 Are dashboards New style or Old Style?
 What reports are being displayed?
 Does it look like the dashboard is meant to be a
working space or just a landing page?

33. #EMPOWER2015
Interview the Users
• Talk to at least 1 person from each role
 Have them show you how they use the app
• Potential Interview questions
 How often do you use this app?
 What do you like about this app?
 What do you NOT like about this app?
 What do you wish this app would do?

34. 3 Assessing the Existing App

35. #EMPOWER2015
Assessing the Existing App- Design Intent
• Determine the current problem statement
• Compare to the original problem statement
 Has the problem evolved?
 Did the app miss the mark the first time?
 Was there scope creep?
• Check in with stakeholders and specifically
define the problem statement

36. #EMPOWER2015
Assessing the Existing App- Architecture
• What would be the ideal app structure to meet the CURRENT problem statement
 Diagram out the ideal structure
 Compare to existing structure
 Did the app miss the mark the first time?
 Was there scope creep?

37. #EMPOWER2015
Assessing the Existing App- Decision Point
• Decision step: Does it make more sense to move forward with current app OR start fresh?
• Pros of Keeping Current App
 Users are familiar with it
 Data already in app
• Pros of Creating New App
 Focus app on your problem
 Make the app more user friendly
• Advise you to make this decision with input from stake holders and users

38. 4 Documentation/
Going Forward

39. #EMPOWER2015
Think of Future App Owners!
• You have put a lot of effort into understanding this app
• Be kind to those behind you and document what you know!
 Add a clearly stated design intent in the App description
 Leverage Rich Text or Code pages to document what you know
 Problem definition
 App architecture
 Roles and how they should be using apps

40. #EMPOWER2015
Change Management Within Your App
• Change Management: the controlled identification and implementation of required
changes within a computer system
• Consider a Change Management Table to track app changes
• Involve the whole village
 Allow users to submit App Improvement Ideas
 App Admins can then assess and possibly implement ideas
 Keep track of when and by whom the changes were made

41. Thank You!