Being a developer, an analytics geek and someone who has managed app teams for several years I have seen the different sides of what goes into app delivery and its from this unique perspective that I would like to share some insights I have picked up to help improve how apps are made in your projects.

Conflict in Projects?

In many cases I am amazed by the amount of conflict that is caused through not taking a “one team” approach to building apps and websites. I have been part of projects where conflict and problems have been virtually encouraged through enforced separation of the design and the development function. ( going against my advice) There really is a better way — and I hope this post helps others to avoid the same pitfall.

Why is UI design and UX important ?

One of the most important aspects that distinguishes iPhone and iPad apps are their dedication to being beautiful, dynamic and usable.

The Apple Human Guidelines is an excellent resource which helps those building apps to understand the nuances of design and user experience. The introduction for the animation section says this best:

Beautiful, subtle animation throughout iOS builds a visual sense of connection between people and content onscreen. When used appropriately, animation can convey status, provide feedback, enhance the sense of direct manipulation, and help users visualize the results of their actions.

In IOS development, building UIs are the closest that you come to talking to your end users. A great UI is like a great conversation that flows and brings those that participate in it a lot of happiness and joy.

By contrast, an inconsistent, misaligned conversation is one that makes users feel uncomfortable and they will seek out to find other great conversations in the room and leave your app lonely in the corner.

Ok enough labouring this point…I hear you say… UI needs to be great. Lets crack on.

The design process gets off to a good start

1. Designers spend ages agonising over ideas and discussing with customers over the smallest details of the app or site they are creating.
2. They have often iterated through multiple versions, and done multiple rounds of feedback to get it just right.
3. It gets signed off and validated right up the business chain.
   Without involving those that are actually building the product, there is a big risk. This is the point that things start going off the rails 🚨😱
4. At this point, its presented to the developer team( usually with a filename such as Design Final final .pdf)

Starting developers with a locked design ( Don’t do this!)

This “wonderful, perfect design” has becomes set in stone, and any changes that the developers suggest afterwards are tantamount to destroying this wonderful UI and all the work thats got in before.

Even worse, the poor designers, who have birthed this design are almost forced to become guardians of what works for the audience. They feel obligated to defend it, justify it, and protect it from the evil marauding developers.

🔥🔥War ensues🔥🔥

A better way: Involve the development team earlier

The real key to success would have been involving the developers a lot earlier in the process.( ideally step 1 above).

The developers’ role during the design phases should be to:

1. suggest ideas to streamline the development. In one case I suggested that creating a radio button in the top right hand corner would allow users to more easily access a feature. The designer didn’t know it was possible- and we removed 2 screens from the entire app flow — and end users loved using it. £1000’s of pounds in development costs saved in 5 seconds.
2. validate the design as being feasible. I once had a project where we had to do colour detection to unlock levels of a game. The problem is that colours can look significantly different depending on what the light is. This was flagged early so the designers and product owners came up with another approach based on developer teams suggestions.

3. suggest new features. Based off the latest IOS apis there are a goldmine of new exciting features to be tried.

4. technically validate that its deliverable within budget and scope. We helped a customer to scale back their overly complex requirement, and applied learn startup principles to test what customers wanted. Then we just built those features. We cut the cost of development in half!

5. spot edge cases which the designer may not have though about. Animations, permission dialogs and alerts typically fall into this category and are usually missed — or not thought about until the end of the project.

At the end of this process, the design would be a lot stronger, more deliverable and a lot less risky. Its the perfect time and seek the various approvals that go up the food chain in a typical business.

Other tasks for developers to reduce risk in the early stages

Besides working with designers, there is a lot of preparation work for the project that can be started whilst the teams are working on getting the designs validated. Mainly the focus is on :

• avoiding the “Developer-Designer guessing game”( More on that in my next post)
• establishing a team work flow for designers, developers and customers

so that any changes that come through during the project lifetime are a lot easier to process and manage without derailing the project.

Communicate and collaborate

As you can see, any place where silos exist between various parts of a process are always prone to risk. It requires a lot of management and meetings to smooth over the cracks and build interfaces. It’s best to avoid them from the start.