Category Archives: Entrepreneurs

Building the Kitchen Sink App

 

No… I got the kitchen sink too.

The impulse to build a “kitchen sink” app comes from, I believe, a few places:

  • Fear that users will be disappointed with less features
  • Requirements from other stakeholders or teammates
  • Belief that mobile is a direct corresponding medium to web; what’s on the site should be on the app
  • That users come to mobile with the same expectations as desktop or browser users
  • That time and cost estimates are the same with web as mobile
  • Unclear knowledge on how long it takes to build software (vs. websites)
  • Fundamental belief that stakeholders know better what customers want

I’ve seen, up close, two different projects that began with a large spec. They had various logical and thoughtful reasons why they needed to build out big features. Justification for each case was based – not on customer feedback or metrics – but on business cases, perceived necessity, competitive advantage and financial reasons. Customer satisfaction was important, but it wasn’t a direct “they wanted this”, more of a “we believe they want this,” and more “we want this.”

I’ve also seen, up close, small applications developed with customer feedback. A lot of time is spent on planning and testing, and development is quick, and relatively simple. Customer feedback is always the number one reason features are built. There is a lovely basic, direct knowledge that customers want something, because they basically said so. Iterating quickly, getting feedback, building what they want, it’s a cycle that – when done right- results in great software.

What really gets me is when someone asks for a kitchen sink, and points to one of these small prototypes that evolved over years, as an example of what they want out of the gate.  I start telling them the story of that app- how it had modest beginnings, the missteps, the corrections, and what they see as the the final app was not, at its core, a kitchen sink app. Instead, it was a carefully crafted- by the customers- application of what they want and needed, over time. The best justification for why to do it this way, is of course, financial.

Best Reason: Money

In the two cases I talked about above, where full-featured specs were thrown over the fence “90’s style,” the projects ran way over cost. The cases where projects launched modestly and gained traction with the user base, and product direction was largely determined by necessity on the part of the customers, were very affordable. We got into a loop of launch and test, gather feedback, communicate with engineering team. Build release, launch and test, etc. This was with a live production app, as well. Yes, there were issues, there were rollbacks. There were apologies to user bases. But since their app was getting built as they wanted it, we had a very happy base that felt listened to, and catered to. Engineering was happy- the development was always justified not by some far off goal, but by actual user cases, expressed by the users.

Another good reason: Engineering

One client approached me with an in-progress kitchen sink app. I talked to him for a while and we discussed the engineering team. I could see some flaws in organization- the senior lead didn’t have enough time and energy to devote more full time to the project, and the junior developer had time, but not expertise. The list of features was ambitious, and without a full time senior developer, I could see how decisions were being made, and time spent (billable) in the wrong directions. Spaghetti comes to mind. While he was interested in me working with his lead, it would largely be pointless as he needed to rebuild his product design with his engineering team in mind. Don’t do anything new (the project was daunting enough for a junior dev) stick to common UI objects, keep it simple. Release early and get the lead to build a good iterative testing and analytics framework – that he can do in his short time. See how you can mold the project, a modest, one-feature app, to the team you have? Another great reason to KISS, is accessible resources. Prototypes rarely require that much intense engineering. It’s the business idea that’s the secret sauce, not fancy code and algorithms. Well, unless fancy algorithms is your business idea.

When To Be Beautiful: CEOs and Perfectionism

I’ve worked with many CEOs at this point, and all of them are perfectionists. Literally, all of them. To see, use, or even publish a rough functional prototype, I’m sure is like scraping their nails down a chalkboard. So why do it? And how much should they compromise, if they compromise at all? And of course what everyone is thinking- WWSJD? (what would Steve Jobs do?)

I am not a perfectionist, I’m a finisher. I like to wrap up projects. I once took a train trip with my mother, and about 4 of her in-progress sweaters. By the end, they were all done.

For software development projects, a balance of a finisher and a perfectionist is a magical combination. While there’s tension, it’s largely productive. Here is a staged layout of releases and expectations of design perfection- the whys and wherefores to settling with less than perfection.

1. Prototypes should only communicate concept.

If you’re out to try to prove a point, or communicate an idea or basic function to an app, make sure that the number one feedback you get is about the concept. So it shouldn’t be remarkably pretty, or even super ugly, but it should communicate the concept. All design and details should point to: does it communicate what I’m testing, be it uploading a photo, chatting with coworkers, or a new way of filtering products.

Being a perfectionist may seem to make sense- I’m making sure the concept is easy and understandable. And that’s true, but it’s the nature of the feedback, and the stage your’e at in the process, that you need to watch out for.

There are two reasons not to strive for perfection at this stage: time/money, and the general goal of a prototype. The concept has a high chance of being scrapped, and all energy, time, and resources used to make it perfect will be down the drain. It is very likely things will change so much that entire flows or features will be tossed. Secondly, the team is striving for function not design, so getting design feedback is like watching a movie and saying it’s not funny, when it’s a drama.

This is the time for the CEO to give input regarding the communication of the goal and functionality. Wrong colors, wrong images, bad fonts, that all is valid in the beta/version 1 phase. Not in prototype. Login is unclear, Facebook doesn’t post, that’s all very relevant feedback in prototype phase. “This is just a copy of Instagram,” or “It should immediately launch on the map” that is all very useful functional feedback that myopic programmers may miss because they are focusing on getting it working, not through the eyes of the user, or the market.

In the software release cycle, there is a time to be pretty, and to be perfect. The prototype stage is not the time.

2. Betas should be pretty

For beta versions, you’re releasing to users, albeit power users, supportive, ready to give detailed feedback, and otherwise “invested” users. You’ve gotten feedback from several prototype concepts and decided on one app feature. You have built out, or modified, the prototype to handle real production data and smoothed out the functional kinks.

Now, this is the time to be “pretty.” To comb your hair nice and otherwise be presentable. So make sure the colors and palate in app are consistent, make sure everything lines up nicely, even margins, the flow is solid and understandable. To the CEOs reading this- work with your team and communicate that it should be “undistractedly nice-looking” that is, there should be no reason for the beta users to think about the design. There should be no logging output or awkward flows, crashes, etc. We are beyond functional, but because things will still change a lot, not ready for the time investment of perfection.

3. Version 1 should be perfect (Beautiful!)

Now you’ve integrated feedback from your beta users on flow, design, confusing spots and improved some latency issues or other production-level problems. Now, is the time to invest designer and UI/UX and front-end engineering hours into being perfect. Things are functionally not going to change until another version. For mobile developers, the front-end is not so easily distinguished from the back-end. So get your best UI programmers for mobile involved, and get their pixel-perfect eye and have them iterate quickly with UI/UX designers to determine the best most beautiful way to build this- without changing flow or functionality. Note: integrating them in the uglier versions helps them understand functionality restrictions, and helps integrate their feedback earlier in the process. The hardest part now is resisting functional feature creep and modifications, and to shunt that to Version 2.

3 Pros For Prototyping

apple1976_2008
What is a prototype?

A prototype is an early sample, model or release of a product built to test a concept or process or to act as a thing to be replicated or learned from.

– http://en.wikipedia.org/wiki/Prototype

Wondering what the pros of prototypes are? We think they’re great and here’s 3 reasons why.

  • They get more realistic reactions about a product.
  • They’re quick to build.
  • They’re more affordable then fully featured products.

Prototypes help show instead of tell by turning ideas into tangible products. Products that you can hold, your customers can hold, or your future inventors can hold. Often times, it’s easier to demonstrate something real than to describe it in words or even pictures. The feedback from a prototype will achieve a more natural response to using the product rather than than responding to the idea of a product.

Prototypes are quick to build. They are quick to build because they generally only have the most essential features to convey a concept. Building a light weight prototype is helpful to quickly iterate upon features that worked, features that need optimization, or features that can be removed all together.

Prototypes are more affordable. Since a prototype is often a way to test a market or an assumption, they are not fully featured mature products. In general, things that take less time to build, generally cost less to build.

What are your thoughts on prototypes?

Like to keep informed on other mobile app news and tips?