Anti-pattern: graphical design driven development

Everyone wants to have a beautiful graphical design for their product. The problem comes when graphical design becomes more important than usability and affects the efficiency of the development process.

There is an anti-pattern we call "graphical design driven development." The way it goes is that the client starts by creating a graphical design for their product in Photoshop. The designer focuses on making something beautiful. Because Photoshop can do anything, they make everything custom, e.g. custom fonts, custom buttons, drop shadows, custom controls. They tweak the margins below the headings, add hairlines, make it really shine. They add special user avatars, images and content, so each page in the mockup looks great.

They make a page flow diagram, and give it to the developers to estimate. Developers don't really see the graphical details, they just count buttons and think of the logic, database and communications protocols. They create an estimate, the client approves and they get started. They implement all the custom things on the page exactly as the designer drew it, going through a couple of iterations to get it pixel perfect. It looks great on iOS, but is really hard to get the design perfect on Android because of the different screen sizes / resolutions and dynamic layouts.

It ends up taking more time than everyone expected, but finally it's ready, and we give it to beta users to start using the app with real content.

We find that the content is too big to fit on the page, or too small and looks lonesome. Normal users don't bother with avatars, so we have a line of "tombstones" with the default user avatar. We find that some features are hard to use. It takes too many clicks to do common things. Some pages need to be split up, others combined. That custom control we implemented doesn't get used, or needs to be modified.

We need a new design for the new pages. So the graphical designer comes in again, and they spend a week or so making new beautiful designs, while the developers wait. The developers implement all the custom details again, and we have a round or two of tweaks. Or perhaps the graphical designer has been working on new designs while the developers were doing the initial development. Everyone is excited about the new things in the pipeline, and the investors are asking when it will be done. We keep telling them that it will be there soon, but we are losing credibility with every delay. How hard could it be to just implement a few pages of buttons?

We spent all our budget getting the app done, but at least now it's finally released and beautiful. We can see some things that are not optimal, but changing is so painful, we don't want to do it.

There is a better way.

Fundamentally, the most important thing for your product is whether it helps your users achieve their goals. Feeling is important, and graphical design is a big part of that, but we need a process that delivers usability first. It may sound like I am hating on the designers, but the good ones understand this. Having "concept" graphical designs can help us with fund raising presentations and overall UI approach, but they can't drive the design.

We start with a user-focused process that defines user personas and goals, then user stories. Once we have a good base, we start prototyping the application.

One of the best ways is to start with Keynotopia. They provide a set of reasonably-priced templates which you can use inside of Keynote or PowerPoint to create your user interface. Their library of standard mobile buttons and controls let you make realistic user flows which switch pages by clicking on buttons or links. Entrepreneurs and product managers can create the initial prototype without a designer, and we can go back and forth quickly to iterate on the design. We don't have to wait on graphical design or use specialized software like Photoshop or Illustrator.

When we are happy with the prototype, we start implementing it as a real mobile app. We first create a skeleton app which has the pages but minimal real logic. We use Interface Builder to create the UI by dragging standard controls onto the pages and connecting them. We use mocked up static data and do as little custom UI work as we can, focusing on how the app works dynamically to handle user tasks, not what it looks like. If we find we need to make changes to the pages, we can do it with minimal rework. We can show the investors the prototype and they can try it out themselves. It's clear that it's a work in progress, but it's functional and doesn't crash. They see progress in the initial UI prototype and in the first version of the app. We know we have gotten it right when they say things like "I could use this today, I don't care what it looks like."

Next step, the graphical designer comes in and creates a beautiful design based on the actual app. While they are doing that, the developers implement the application logic and communication with the back end.

This way we do the prototyping and iteration work at the beginning when change is cheaper, using presentation software instead of code. We create a development road map which is well defined and predictable, allowing us to hit our delivery dates. During development we create small feature tickets which can be completed incrementally instead of a monolithic and ill defined "graphical spec" which is always "almost done." We avoid thrashing the dev team with changes, they can sit down and execute the bulk of the app all at once. The process is more efficient, faster and saves money. And it ends up being a better app, beautiful and usable.