Ok, I know this sounds crazy – who would build a web/mobile app before graphically designing it?

Most teams follow the following model – define feature requirements, wireframe/UX, design, and then build. Let’s explore a slightly different flow where we write code, before we fire up Photoshop.

Below are a few reasons why we like this method:

1) Design rounds are subjective, this leads to a drawn out design phase derailing project delivery dates.

2) Functionality changes, it takes much longer when designs are in place vs. using stock UI assets to make these changes.

3) Start every product by building what’s most important, get designs out of the way.

4) Designing a completed, functioning application allows for designers to bring pixel perfect solutions to approved/tested functionality.

Let’s explore…

1) Design rounds are subjective, this leads to a drawn out design phase derailing project delivery dates.

Our design team is great, and this is a good thing – however it can be counterproductive when clients start so see their months of documentation, ideation, and requirements finally getting a sexy skin. All of a sudden the kitchen sink looks a lot more attractive. New buttons, drop-downs, hide aways triggered by custom gestures, all enter the picture… these are things that should come into play but not necessarily this early on in the product development lifecycle. They’re not core to the functionality, therefore don’t deserve the attention of the product team at this juncture.

2) Functionality changes, it takes much longer when designs are in place vs. using stock UI assets.

So we finally get approval on designs and we start the build. We get the first deployment to the project stakeholders and in comes the feedback – “Hmm feels more intuitive to have the button down here” “would be easier to have swipe to delete vs. edit button”, etc etc etc. All of this feedback is valuable, as it’s impossible to predict all real use cases without a functioning prototype – but these types of changes can really muck up a beautiful interface when being jammed onto the design team for quick ad-hoc updates. Then to re-implement the updated design adds to the development time and cost. If that iteration was released with stock assets, users could provide feedback and we could update the view functionality rather painlessly.

3) Start every product by building what’s most important, get designs out of the way.

If you’re building an app that allows you to give your friend a virtual high five, then giving the high five is much more important than the settings screen, or inviting friends to the app, or sharing your high five to Facebook. If you approach all features and screens as if they’re equally important, by designing them all to the 9′s right out of the gate the CORE features are missing out on all the attention the log-in screen is getting.

If you’ve designed the entire app, then start building the entire app to realize that due to a technical constraint, you need to re-imagine the flow of the high five module (the most important module) – this can really throw a speed bump in your project plan. However, if no effort had yet been spent on designs and you started building the high-five module, then adjusting the implementation of the core-feature wouldn’t be nearly as painful and would still lead to a smooth design phase.

4) Designing to a completed, functioning product allows for designers to bring pixel perfect solutions to approved/tested functionality.

Giving a designer an approved, tested, working prototype on their device or browser with great UX ready to be skinned – they can really spend the time to properly apply pixel perfect design solutions. This also then allows the stakeholders to chose which features should get the most design love, and which features can just be cleaned up for prime-time.

This paradigm has been successful for us in the past, and tends to be where we’re headed. It isn’t the best fit for all projects, but in general we like keeping focus on the core features first, getting feedback on functioning a prototype, and not getting ourselves in a situation where we have to make unthoughtful design decisions due to feedback on build 1.

Because of this passion, there is often the uncontrollable need to say “what if it did this”, or “then we could do this”. Although these ideas might be brilliant, if not controlled they can drastically lower your odds of success. These new ideas should be embraced and not disregarded, but action on those ideas needs to be controlled.

Control

Chances are, the problem that you’re solving is something you’ve been thinking about for a long time. If this is the case, don’t let something you’ve thought about for one day or week get in the way of solving that problem. Put the idea in it’s proper place (a product backlog, or icebox) and continue on your mission to solve a problem.

Poise and Planning

Once you’ve released your most streamlined attempt at solving this problem, revisit the product backlog and see if any of your peripheral ideas could enhance the product based on your learnings and user feedback. The fastest and cheapest way to solve a problem (which is what people pay for) is to embrace change, but don’t always build it.

I program because I love preparation. When I was a woodworker I spent all of my time making jigs. 20 hours of building a jig to hold a board in a perfect, repeatable position. Once you strap in a board, it only takes 10 seconds on the table saw to give you a perfect cut.

This is why I love programming. I spend weeks crafting the views, code, and database so that when a user pulls out the app for 10 seconds, they can get exactly the information they need.

Who are your users? How can we prepare a platform for them today, that will give them exactly what they need?

Well, if you weren’t, here’s a recap.  It was held in a big warehouse-like building called the Zhou B Art Center.   The art hanging from the walls and scattered around the floor  added a touch of beauty and chicness to what otherwise could have been a drab, utilitarian environment.  So we wandered around appreciating some (but not all) of the art and enjoying the chance to mingle with other like-minded techies.  We checked out tables set up by exciting new Chicago Startups, we got some cool swag, and eventually we listened to the pitches of some great new companies while they vied for prizes in an impromptu pitch competition.

We met developers, designers, and entrepreneurs.  We met recruiters.  We even met some TechCrunch people.  And so it was, that Ora got the chance to be in one of our all-time favorite web publications.  That’s right, Dan and Jeffrey had the chance to talk a bit of shop on camera with TechCrunch – check out the video at http://techcrunch.com/2012/11/12/chicago-meetup-startup-sails-are-full-in-the-windy-city/

All up, it was great night filled with fun times and interesting opportunities.

Thus, a balance must be struck.  For approximately the last year, our recommendation for an app that wanted to appeal to a broad audience was to target iOS 4.2.  Well, the time has come to move forward, and I am now here to declare that iOS 5.0 is the new iOS 4.2.

This change is due to several factors.  iOS 5 has now been in public release for approximately a year and a month at the time of this writing.  This has allowed time for mass adoption among the iOS user base.  At Ora, we follow a series of metrics to measure iOS version usage and adoption.  One clean site that is useful to follow is that of independent iOS developer David Smith, which can be found here.  Here, you’ll see that iOS 5+ accounts for more than 94% of all iOS users.  In addition, the standard version of Xcode for developing and submitting apps to the App Store has also recently received an upgrade.  With this new version of Xcode, the oldest version of iOS that you can support is version 4.3.  Thus, if applied to David Smith’s metrics, this cuts out another approximately 2% of users.

Combine all of this with one final piece of the puzzle.  Most apps that we develop here at Ora are innovative, and forward thinking.  These are the types of apps that grow dynamically through an adoption process.  They start with the early adopters – those on the bleeding edge, those who have the newest thing before others even know of its existence.  These users, the ones that will be the first to download and use your new app, will generally have more advanced operating systems installed on their phone.  Thus, even though choosing iOS 5.0 may leave behind 4% of potential users, these users are the least likely to download your app in the first place.  Then when your app takes off and becomes a mainstream success, months will have elapsed, the iOS 4.0.1 user will have upgraded their cellular contract and will unlock their new iPhone 5 to see your app waiting for them on the featured section of the Apple App store – ready for download.

UX Design

UX is short for user experience. In the mobile and web space this acronym represents the effort of mapping what we call “User Stories“, which are all the required actions, functions, and results an app needs to deliver from the users perspective. Quality UX is delivered by carefully architecting those stories through streamlined navigation, button and tab placements, thoughtful animations and transitions, considering defensive design and proper error handling. Here at Ora, UX is an effort that involves minimal aesthetic and usually results in filled white boards and note pads. For most clients, we formally document an apps UX via a wireframe or storyboard document.

Here at Ora, UX is the driving force behind our product development lifecycle. It typically influences the technical design and the interface design as UX is the most important element in building products that people love to use. Because there are numerous ways to “skin a cat” when it comes to UX design we give every story the attention it deserves to ensure our interfaces are intuitive and easy to use. To stay current with all platform guidelines we live in both Apple’s HIG (Human Interface Guidelines), and the new Android User Interface Guidelines.

UI Design

Once we’ve crafted the UX and identified all of the elements required on every screen we dive into the graphical design of  the interface. The UI design phase is when our award winning creative team crafts the graphical elements of the interface down to the pixel.

Prior to the UI and UX design phases we work with our clients to establish user personas, we use these personas during this phase to ensure that we’re directing our design to the proper audience. For example, if we know the users will be an older demographic we most likely use predictable and recognizable interface elements with larger buttons and fonts. However, we would customize UI elements and include more animations and gestures for a product targeting a more advanced user.

We usually start with drafting 2-3 creative concepts on one particular screen. This exercise gives the client a few different interpretations of the same screen. After a few iterations on the concepts we’ve established a solid creative foundation defining colors, typefaces, look and feel, and iconography. From here we apply this foundation to each individual screen making sure to give each element the attention in deserves.

It’s important that each product gets real attention at both the UX and UI layer. What’s a great graphical design if the experience is poor, unintuitive, or cluttered with too many screens and buttons? On the flip-side, a clean experience can be hindered with distracting graphical design or poor aesthetic. It’s key to deliver a clean, intuitive experience with a complimentary aesthetic and that’s where our expertise lies.

@DanByDay

According to researchers at the University of Bonn regarding a recent study (see http://www.ncbi.nlm.nih.gov/pubmed?term=internet%20addiction%20chrna4), 132 out of 843 people interviewed exhibited “problematic behavior” regarding their use of the internet.  That may not come as much of a surprise, but here’s the kicker:  The people who exhibited such behavior were more likely to carry a genetic variation (also associated with nicotine addiction) of the CHRNA4 gene.

Long story short, gene mutation is involved in internet addiction.  To be honest with you, I’ve always thought the term “internet addict” was nothing more than a cutesy way to say that a person likes surfing the web.  I stand corrected.  Apparently, internet addiction may even be added to the American Psychiatric Association’s “Diagnostic and Statistical Manual of Mental Disorders.”  A mental disorder?!  Sounds a bit hyperbolic to me, but I doubt I have the necessary clout to question the APA.

I guess it makes sense that it’s a true addiction.  I mean, what is an addiction?  It’s a dependence.  It’s also habit forming, etcetera, etcetera.  Sounds about right to me – most people I know depend on the internet in one way or another; I’d like to think that I’m not included in this group, but I clearly am.  And we all have internet- and tech-related habits.

So we’re all addicts.  Great.  What else do we need to know, now that we’re all aware of our addictions?  Well there are now detox programs in place for internet addicts.  I don’t know if that’s funny or just downright frightening so I’ll just move on.  Next – and I’m sorry if this is a bit of a tangent but it caught me by surprise and it bears mentioning – I came across a survey which showed that a large and growing number of people would rather live without sex than without internet.  I think that, in and of itself, is proof of addiction – I don’t think any further research need be done on the subject if that survey was accurate.

So… To sum up, due to the advent of the internet and the mutation of our genes, we are now dealing with yet another addiction.  But let’s be honest – as far as addictions go, it isn’t so bad.  At least I won’t be getting the shakes between blog posts.

Check out:

http://news.cnet.com/8301-11386_3-57502901-76/internet-addiction-fueled-by-gene-mutation-scientists-say/

http://news.cnet.com/8301-17938_105-57377534-1/internet-addiction-could-be-dubbed-official-affliction-in-dsm-v/

http://news.cnet.com/8301-10797_3-10123138-235.html

Where to begin?  Well, I started looking for work by scouring job sites, company sites, etc., but to no avail.  Sure, there were plenty of jobs around the place if you looked, but nothing spoke to me.  I love technology but couldn’t find a tech company with the right approach or culture.  Eventually, though, I found Ora – I researched it, and I loved it.  They are, above all, client-focused and design-driven and that is exactly what I was looking for.  The culture sounded like a great fit, their reputation was inscrutable, they were incredibly successful and growing quickly, and as luck would have it, they had a job opening that was right up my alley.

So I applied, got a call a few weeks later, and went in for an interview.  Now, a guy’s got to look his best when interviewing for any position, let alone a position with Chicago’s top digital agency, so I threw on my Sunday best, showered, shaved – the whole nine yards – and found myself in a conference room downtown Chicago.  I met Mike and Dan (both clad in casual street clothes while I sat sweating in my suit jacket) and I interviewed for the position.  ‘Interviewed’ might give the wrong impression.  We chatted about this and that, talked shop, discussed the position, joked around, and then I went on my merry way.  Anyway, long story short, they offered me the job shortly thereafter and I accepted right away.

Phew.  I know, the suspense was killing you.  Well, now we know that I got the job so you can relax.  Deep breaths and all that.

I had the first day jitters, I won’t lie to you.  It’s tough going to work your first day – you have no idea what to expect but you’ve got to be on your A game.  All that went out the window once I met the team.  If you’ve worked with Ora in any capacity before, you’ll know what I’m talking about.  The guys are great.  I could instantly see why this company is as successful as it is – it’s the people.  They… we… love what we do and it shows in our work.  There’s a sense of camaraderie here that made me relax on my first day and has made feel at home every day since.  As if that’s not enough, the expertise in this office is unbelievable, it’s palpable.  My mind is blown daily by the things these guys can create.  Top favorite thing I’ve done so far in this job:  Brainstorming sessions with some of the best brains in the industry.  How cool is that?

I know a lot about this industry, I know a lot about my line of work, and I like to think I’m a pretty smart guy with a certain amount of expertise.  These guys school me everyday.  I love it.  I’m constantly learning, whether it’s about Ora, the team, the projects, the technology, the industry… needless to say, I’ve yet to be bored by my work.  It’s challenging, it’s fun, it’s developmental – what else could you want?

So those are my thoughts.  In short, I like my job.

1. Cutting Edge Digital Experiences, Come from Folks that Build Cutting Edge Digital Products

I’m not saying that big companies can’t have really strong and creative in-house development teams, however with my experience, there isn’t the time, focus, or leadership expertise in house to build, maintain, and fuel these types of digital teams. Unless you’re a technology company, the majority of you’re resources are spent building your core products and providing your suite of services. I know what it’s taken to build Ora to the machine that it is today, and that’s having laser focus on doing a few things really well. With this said, if you’re looking to develop a mobile or web product that will stand out in the crowd – I’d recommend engaging a team that’s done exactly that.

2. It’s not about “what” the features are, but “how” the features are… I’ll explain

How many apps allow you to share photos, tell people where you are, check you’re bank account, create a to-do list, find new restaurants, etc. Why do some checklist apps have millions of downloads, and others have… well, not a million. Why did Instagram sell for $1 Billion and Hipstamatic did not. They all have roughly the same features, but some had teams that were good enough at their craft, and understood their users the best – these teams did something magical with “how” these features were interpreted. Large businesses may know their consumers better than anyone, and therefore understand “what” features would best suit their audience. However, they must invest in “how” these features are executed – and this includes UX, Design, Engineering, Branding, and the like. Imagine the day P&G releases the app that truly changes the way people interact with their consumer products… they have hundreds of millions of potential users out there. With the right “how”, their features could truly drive change to their brand in the modern world, increasing awareness and marketshare.

3. It’s all about Style (development style that is)

If you want your product to portray the style that turns heads and gets people talking, then it needs to be built in a fashion that embraces creativity and innovation. What I mean by this is, in order for product experts, designers, and engineers to do what they do best, they need to have the flexibility to learn, experiment, change direction, and pivot as needed – similar to most digital startups.  Commercially there’s different ways to meet the needs of a big company, like making sure deadlines and budgets are managed – but the way with which these requirements are met is where it’s all about the style. Startups are successful when they are loyal to the product and their users. With the right team, big brands can capture this same energy to produce results that are remarkably original and yield high returns.

@DanByDay

I’ll preface this quick blurb of opinion by stating – although we fully believe in “Agile” development practices for mobile and web application development, as a services business the best methodology is the one that best meets the needs of our clients. Now that I’m done kissing up to our clients, let’s dive into the review.

What’s fundamental to my respect for 37 Signals is the way that they DO say what they mean, and DON’T make a big stink about the fact that they’re saying it. For example, there tends to be a wave of trendy “movements” that are popping up in the tech startup space (the most popular is The Lean Startup) – although I’m a huge fan of Eric and his mission – 37 Signals gives advice and recommendations by walking the walk and revealing the raw successes (and lessons learned) of building kick-ass software. There’s no methodology, framework, movement, etc. that your business needs to adopt – but there are talks of “Build Less”, “Be Yourself”, “It’s a Problem When It’s a Problem”, “Scale Later”, “Hold The Mayo” and much much more. These are the terms that Entrepreneurs like myself, and product designers and developers like our killer team here at Ora can really respect and relate to.

The book is a quick read, especially if you’re into this type of thing. I don’t want go into too much detail but I would like to highlight my two favorite sections (not because I agree with them 100%, but because I feel they have a strong and meaningful point-of-view).

Half, Not Half Assed

Having serviced and been involved in startups with strong products, I find myself preaching this message more often than not. This section briefly describes how important it is to remember “less is more”. If you’re building a meaningful product to solve a problem, or make someone’s life easier or better, it makes more sense to test this by getting a strong, simple product to market and prove your hypothesis. You can always add and enhance features, but it can become very costly to pivot or properly iterate on an application that’s too broad in scope.

Hollywood Launch

A product launch is very important to the success of any startup… however, a product’s pre-launch strategy can also be fundamental in how successful your launch actually is. Think of it this way, new technology is coming at consumers all the time, and from every direction. People are learning to rely on proven services. There’s two easy ways to gain credibility and traction pre-launch. 1) Get your target market engaged in the early phases of the product and 2) Find the sources that your target markets rely on to learn about new “proven” applications and services. Get these sources involved, and you’d be surprised what a little organic press can do for your product launch.

Again, you can get yourself a free copy of the book Getting Real. Also, feel free to get in touch with us to chat about getting your product in good shape to launch, and some good ways to put together a pre-launch strategy.

@DanByDay