Coming up for air after a few years of early-stage application development projects, I’ve gathered here some accrued thoughts on the most unexpected, difficult, and otherwise interesting problems that have arisen despite the best intentions of experienced and talented teams. While this may also be relevant to more mature software projects, the emphasis is on early-stage web/mobile application development at startups.

1. The Multiple Designs Problem

Problem: What’s referred to as design in web/mobile application development only gives you half of the development plan your team needs to be successful.

Solution: Product owner, UI/UX Designer, and Front-end Engineer should work together intimately from the beginning to “do design” for the project. Include modularity, data-flow, and systemic events as first class design considerations alongside traditional UI/UX design issues.

UI/UX design and Software design of UI software are two different things.

• UI/UX design - typically done by a professional designer, this involves working with the product’s business owner to get the product vision out of his/her head and into a visual representation (wireframes, mocks, etc) of the user experience (UX) and associated user interface (UI).

• Software design of UI software - typically done by a professional (front-end) software engineer, this involves creating a plan for program(s) that the team will be building, with modularity and managing the flow of data as the key considerations. For more on this, see Leslie Lamport’s recent work on the importance of blueprints in software engineering.

Most teams focus on the former and neglect that latter. Mocks stand in as software design. In the worst case, the team jumps into coding up the mocks without thinking about software design. In a better but still wrong scenario, the engineering team derives a software design from the mocks - something like “if I draw a bunch of nested rectangles on these mocks I see we’re going to need the following 24 UI components and because the mocks refer to 7 entityish things, we’ll need these 7 classes in our model layer …”

The right way to do this is to have someone (the UI engineer) engaged in software design from the very beginning, working in parallel with a designer who’s focused on UX, and the product owner who has the vision. A lot more collaboration is required up front, but doing this right means you will have created an application design that encompasses both UI/UX and software design. Critical considerations like modularity, thinking holistically about all of the meaningful events that can occur in a system, and how data will flow across the entire system play a first class role alongside equally important considerations like aesthetic, look-and-feel, usability, and good UI design patterns.

A good way to compensate for the the extra collaborative cost incurred is to constrain the scope of both design disciplines. Defer unimportant decisions whenever possible. Don’t worry about pixel-perfection. Typography, colors, and other style guide issues can probably wait. In terms of software design, keep it very low level, thinking about the core data model that this thing will run on, and the fundamental user actions and other events that are meaningful to the product. Let these two design disciplines evolve in parallel toward less fundamental issues like componentizing the UI, layout/nav decisions, and determining the right UI patterns to use.

2. The Multiple Environments Problem

Problem: The end user UI environment is increasingly fragmented and unpredictable. There’s pressure on startups to provide a great product across many device/platform/screen-size configurations, and this is a near-impossible challenge for teams with limited resources.

Solution: Focus relentlessly on core, platform-agnostic issues. Defer supporting multiple environments if possible. Shift programming work away from the front-end, and use technologies that make it easier to do this.

It’s no surprise that building for multiple device platforms, device types, and screen-sizes is a huge UI engineering challenge. What’s impressed me over the years as a long-time web developer is the extent to which it’s a deep problem with critical system design implications everywhere in the product and huge strategic implications for the business. There’s a good humorous take on the multi-environments problem and other challenges we face in this post/talk by Brad Frost. Instead let’s focus on the solution.

Make Parallel Development Projects Less Redundant

The last thing an entrepreneurial team needs is to be caught up in redundant parallel development tracks building for myriad UI environments (web, iOS, Android, email, smartphone, tablet, etc.), trying to hit multiple moving targets at the same time while ensuring UX consistency, observing DRY, and reconciling worthwhile domain learning across multiple development teams/projects.

It’s important for early-stage projects to be relentless about focusing on core engineering challenges. Depending on the situation, this may mean starting iOS-only or web-only. It might mean using a hybrid approach - e.g. one of several based on Apache Cordova - where native apps are generated from the same HTML/JS/CSS code used in the web app. The consensus seems to be that hybrid development isn’t an attractive long-term approach, but for some types of apps it can be a good early-stage choice in lieu of the eventual switch to a UI built from native components. We need better technology to solve this problem, and I’m optimistic we’ll see it in the near future.

Push Programming to Lower Stack Levels

The innovative approach taken by React Native - sharing (Javascript) front-end data management code across platforms and writing simple, native, platform-specific code at the view layer - offers a pointer into what the future may hold. The key insight here is that in a multi-platform system, we should relentlessly push computing into lower levels of the stack below the “platform-agnostic threshold” and favor technologies like React Native that move that threshold out toward the UI.

As a general rule, when deciding what to do or not to do in an early-stage project, favor initiatives that focus on core, domain-specific engineering. Does it help move you closer toward understanding the fundamental and unique data model and user interactions that will eventually power your successful product regardless of what device the user’s holding? If not, try to avoid it!

3. The Multiple Options Problem

Problem: Throughout the project and across design/dev issues big and small, too much effort is invested in developing, evaluating, and deciding among multiple options when a reasonable, generic, arbitrarily-chosen solution would be as good or better.

Solution:

1. Be aggressive about distinguishing important problems from unimportant problems.
2. Put in provisional implementations instead of going for perfection right away.
3. Decide up front on existing libraries, frameworks, style guides, etc. that will provide a standard set of solutions to these problems.
4. Enforce that the team use these standard solutions.

Many teams pursue the MVP concept: remove superfluous features until the product is minimally viable. Within the context of each feature, however, teams often do not apply this kind of focus.

Non-differentiative (but Required) Components

Consider User Settings, a major UI component that’s required in your MVP but doesn’t really differentiate the product. Teams may invest heavily in custom design and engineering when there’s little chance of meaningful UX improvement and high likelihood of a non-standard approach to some form input causing user frustration. Much like investors are often better served by an index fund than a professional money manager, your team may be better off with a generic solution that averages a bunch of known-good approaches to User Settings UI.

Non-differentiative details of Differentiative Components

Even when dealing with critical major components that truly differentiate the product, non-critical design and implementation decisions get fretted over, debated, implemented and re-implemented before anyone ever really uses it.

Your chat app is going to be the next big thing because of its advanced message search capabilities. A good search UX is critical. But does this UX need to be innovative? Does it require creative rethinking of existing search UI patterns? Maybe your special sauce is the deep learning AI your PhD’s are developing, functionality that’s completely decoupled from the front-end. Can you get by with your framework’s stock autocomplete input for now instead of rolling your own?

Variations for Page Layout and Navigation

How to arrange components onto pages and how to navigate between them is a major area for counter-productive debate and fretting over decisions. The problem is compounded by the multi-platform problem discussed above as you’re often trying to hit multiple moving UI design targets (e.g. smartphone and desktop) simultaneously. Usually here are only handful of reasonable layout/navigation arrangements worth considering - e.g. “Throw everything on one page (great for desktop!)” or “Every component on its own page with a navbar at bottom (great for smartphone)”. Usually it’s not possible to know what the best choices are. You might implement it one way, user test it, and then realize there’s a better way to organize.