Category Archives: Design

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.