I want my apps to be accepted, approved and downloaded.
User acceptance is often the hardest thing to get right. Wireframes or prototypes are a great way to get users to test an app before committing to a design and making that design in code. A wireframe can let a team see a problem early, when changes are easy. At the same time, stakeholders can approve the app before it’s released. And if testers are get geeked with the wireframe, the final app will get downloaded because of the likes and tweets. So wireframing is a way to get approval and acceptance before the coding starts.
But most wireframe tools are awkward. They require that everyone has the wireframe software on their computer. But not with Excel. Most people have that already. And Excel has all the GUI (graphic user interface) controls already – checkboxes, pop-up menus, buttons and a way to display the app prototype. It’s all there, an already installed platform ready to test, try and talk about your developing app.
Look at this REAL app example (or watch the video here). What we see is the app wireframe in Excel. This is the iPhone home screen. But we have more than just a pretty picture. Press the app icon (right side, second icon down in the screen shot) and Excel causes the screen to change …
… like this …
Tapping the app icon simulates launching the app. Excel changes the screen just like the real app would. Now the screen shows the app view upon launch. Yes, Excel enables user experience (UX) by way of buttons, menus, checkboxes and other iPhone native controls. In other words, Excel has the functions, features and controls to create the full UI/UX so that the app can be modeled before development.
This goes by many names – Model Driven Architecture (MDA), Model Driven Design (MDD) or Model Based Design (MBD). All of these are based on the idea of letting end users write a model of the software before you write the real application. Let’s see how that works.
Here we have a real app that I created. It is a T-Shirt quoting app for T-Shirt print sales reps. The goal was to let T-Shirt printers be able to quote a T-Shirt print job from their phone.
The left screen shot shows the app calculating the total price of the job and the per shirt cost. All basic math stuff that you’d expect Excel to be good at. But the right screen shots show you Excel’s controls for pop-up menus and check boxes. Features that allow user to feel the interaction and experience of the app. At this early stage the app allows testers, stakeholders and end users the ability to run the app. Then they can comment on the user interface, functionality and the user experience – all with a working Excel app.
The real power of Excel for modeling are the TABs. Our T-Shirt app has the user interface on one tab, the equations and data on separate tabs. Thus, UI developers can focus on the interface tab. Business stake holders and subject matter experts can focus on the data and equations tabs.
Here you see the data that the app uses to calculate the T-Shirt quote. Because the data is on an Excel tab, it is not hidden in C or Java code. All members of the team can see that data and equations. Even non-technical stake holders can see the transparency (no pun intended) in the wireframe.
When all team members can understand what is happening in a business app, the whole them has confidence that the app will reflect the business logic and business benefits. That confidence allows for a standard the app can be bench-marked against. Confidence, and reliable tests help the app get corporate approval faster.
But that’s not all Excel can prototype.
Web, desktop and tablet apps that access the cloud can be prototyped in Excel with live data because of Excel’s ability to get real-time data from the web.
Because Excel can get data from the web, the model can be updated in real time and I don’t need to write any code to test the app. That is, Excel provides methods to get data from a website. As long as the site feeds data to a webpage, I can get and update the HTML stream into my Excel wireframe. No major coding needed.
This speeds prototyping and testing. Once the user interface is accepted, I can then code out the app in iOS or Java for Android. I know what the final design needs to look and work like. Model Based Design / Model Driven Design allows a team to sign off on an application design. THEN the software engineer can code it out. This mean no surprises. The developers (like me) have a clear model to target. Testers have a benchmark to compare the final application to. And all stake holder know when the final application is ready for release.
MDA, MDD and MBD are one of the best ways to develop an application with many stakeholders.
Agile relies on incremental development, but these project can fail when you have too many stakeholders. This is because few can see how each step will lead to desired product. And SDLC (or waterfall) is slow because of all the up-front documentation needed. Models that are quick to develop, allow all stakeholders to agree on a vision and a design. And they can make that decision faster with simple modeling or wireframing tools.
And what could be simpler than Excel. Most stakeholders know how to use it now (no wirerame tool training needed). Excel has the interaction tools that make it better than Photoshop mock-ups. And Excel files can be emailed to remote team members. But best of all, models in Excel give developers a way to target final development that is well defined. If the team approves the model, developers just need to code-out the model in the new target language.
I developed my Excel Modeling Kit when working at Proquest, UnitedHealth and the Ford Motor Company in Dearborn Michigan.
If you’d like a copy of my kit, with training videos – it is available for download with a link at the bottom of this page.
If you want some help creating your next application in Excel, please contact me – firstname.lastname@example.org.
P.S. I’ve even written software to convert Excel models to real webapps that can run on iPhone and Android mobile devices. That means that Excel can be used to actually DEVELOP the app from concept, to model, to final web app. Try that with any other wireframe tool!
Contact me for available training dates for live or onsite training.
Links to all the videos:
iPhone Development with Excel – using Model Driven Development or Model Driven Architecture
Android Development with Excel – using Model Driven Development or Model Driven Architecture
Model Driven Design with Excel aka Model Based Design or Model Driven Architecture
Use Excel to create an iPhone and Android app — Excel as a UI/UX WireFrame Prototype tool
Use Excel to create Websites, Web apps — Excel as a UI/UX WireFrame Prototype tool
Use Excel to create Cloud Applications — Excel as a UI/UX WireFrame Prototype tool
Use Excel to create Desktop, Laptop, Tablet and iPad apps — Excel UI/UX WireFrame Prototype tool
Why use Excel for Model Driven Design for your UI/UX wire-framing tool?
I was working at a health care giant, when I was presented an interesting problem. One sheet would NOT add up. The guy that wrote the sheet, could not understand why. See, Excel SHOULD add up stuff, and get it right, that’s what we expect.
The problem was that his equations (over 5,000) built in small rounding errors and IF-THEN errors that compounded until the final total was off. You know what a rounding error is. An IF-THEN error could be caused if a cell is less than $1, so we just enter zero. That rounding-off can cause a huge error as the result (zero) is later multiplied to arrive at a subtotal.
So how do we combat the cascade of small errors. One way is with test-driven-development. We include a hidden sheet that has known inputs and an expected results. The data on this hidden sheet is run through the main worksheet every time the sheet is opened. This “tests” our equations to insure we don’t have issues.
In the example above, I used VBA code to simulate the same Excel equations and printed OK in RED to show that the test inout matched the expected results.
Normally we think of charts as static. That is, each chart is made from data in a set of cells. Here we have dynamic charts that are generated at run time – when the worksheet is opened. When the sheet is opened, three Oracle databases are opened, and data is extracted via SQL statements. Then, the chart is created on the fly. The imported data is placed, and VBA code is executed. The VBA code imports the data, adjusts the chart range, and makes adjustments to the chart data (often sorting the data). With the data set-up, the chart is auto-generated. But that’s not the end of the story. Charts can look horrid if they are auto-generated from data that is just dumped into cells. But VBA code can adjust both the data and the chart components so that the user never needs to adjust the chart. That is, VBA macros can insure that data is imported and useful charts will be created without user interaction.
Yes this is Excel.
It is possible to make graphic or GUI software applications that look nothing like the boxy, Excel grid that we’re use to.
This was a real Excel app I developed for Proquest.