Niel Nickolaisen shares a new approach for developing mobile apps that has been very successful for him as CTO at OC Tanner.

Developing a great mobile app can be pretty daunting – some of us are not that creative when it comes to killer mobile apps. In order to give myself the best chance of pulling this off, I have started using a completely different approach – an approach that I have since extended to all application development.

Two of the harsh lessons I learned years ago are that 1) no one knows what they want until they see it, and 2) once they see it, they will want to change it. These two lessons inform my new approach to mobile (and all other) app development. 

Customers Drawing Pictures

I start by gathering a small group of my internal or external customers and asking them to individually describe – by drawing pictures – what mobile app would solve one of their pressing problems. I have them draw a series of screen shots, process flows, happy faces or whatever else represents what would make their lives better. I then put them together in small groups to present their pictures. In their groups, they discuss their designs and come to an agreement on what would be the best application opportunity. They then draw new pictures that represent their solution. Each group then presents their design to the assembled groups. From this, we either combine designs or prioritize what application we will work on first.

“You never know what ideas the individuals and groups will generate – but it takes massive amounts of guesswork, time and effort out of application development. .”

Clickable Protype in Two Days

The entire time people are drawing pictures, a user experience (UX) or user interface (UI) engineer is taking notes and starting to work on the initial iteration of the new application prototype. We wrap up the session and send the participants on their way but make a commitment that they will have something they can see within two days. The UX / UI engineer then spends no more than two days making a clickable prototype of the new application. We send this prototype out to the participants.

They now have something they can “see” to give us feedback on the application. This is important as no one knows what they want until they can see it and no volume of written requirements is as usable as a visual prototype that people can touch and see.

This is important because, once people have something to see, they will want to change pretty much everything. But, up to this point, we have invested just a few days of effort in building the prototype. Because we have not spent a lot of resources getting to this point, it does not hurt when we change things.

Based on their feedback, we make the changes and resend the prototype. We repeat this cycle one or two times until the changes become minor. We are now ready to build an application that matches a reviewed, customer-vetted design. This approach takes a certain level of bravado – you never know what ideas the individuals and groups will generate – but it takes massive amounts of guesswork, time and effort out of application development.

If you want to hit an “M” homerun, give this approach a try and let me know how it turns out. 

Roles We Recruit


Read our weekly e-newsletter packed with career advice and resources for the strategic technology leader, and information about active searches.

The Heller Report

Add a Comment

How Shawn Harrs, CIO at Red Lobster, Developed a Template for IT Success

Apr 3, 2024

Ask These Revealing Leadership Questions When Recruiting Digital Trailblazers

Mar 27, 2024