We’ve all been there. We’ve all tried to design software that feels fresh and unique, yet familiar and intuitive. We’ve all spent days AB testing our designs, reviewing the screens on multiple devices. We get excited about the look and feel, and we hope the customer will appreciate our modern, colorful designs. Sometimes we may forget to consider (or ask the developers) how hard they think it would be to integrate our designs into code. This is a big mistake. The reality is teams often lack a good process for transitioning from design to development. This means assets, specs, style guides, color codes, fonts and even UX micro-interaction libraries. Just because we assume our designs are perfect, and can envision them animating smoothly, doesn’t guarantee that developers will correctly interpret things. Try not to hold this against them. They’re doing their best with what they’re given.
And as development starts implementing your gorgeous UX/UI design, you might notice some minor aesthetic defects. That animation you designed to reveal the menu or shrink the title bar on scroll-up isn’t there. You get worried, or maybe just disappointed.
But you shouldn’t. Because in early development stages, development and testing teams focus on the technical aspects of the project. Even the Project Managers will consider the defects you raise as low priority since they don’t represent a blocker. And they’re right. Technical architecture/implementation is always the core of a project. Issues around these will always cause a project to fail, no matter how great it looks.
Our advice is to keep things simple in the early project stages. Simple ≠ ugly. In fact, the simpler the UI is, the easier it will be to rework it in the next iteration. This will make your developers’ lives easier since it will reduce considerably the time required to integrate the UI. So while these may not be your best designs, always remember you’re just creating a pilot, not the final project. You’ll be able to add in all the detail, irregular shapes, shadows and custom micro-interactions once technical implementation is mature and up-and-running. Be patient.
Think of this approach as akin to building the first model of a styled chair. In order to ensure the chair supports ample weight, is comfortable and ergonomic you’ll probably need to create a series of basic core models first. This process avoids wasting time applying style to something that’s not functional yet.
UI Skeletons apply a UI design in a similar fashion. The first thing to focus on as designers is to be sure the UI is user friendly and includes the requested functionality, without worrying about the details.
The characteristics of UI skeletons include:
- No drop shadows, even when developing native material design on Android
- Same goes for iOS: no blurred backgrounds
- Use regular shapes, avoid rounded corners
- Use 4 colors, max, and 2-3 shades of gray to differentiate backgrounds and cards
- Stick with a single typography family
- Create a UX/UI that doesn’t involve micro-interactions
- Use only native components on Web, iOS or Android. This is not the time to create custom controls (e.g. tab groups, menus, top bars, footers, pickers, text fields)
- If available, use a pre-built UI library to reduce integration time
Once this approach is implemented and the technical stuff works just fine, start testing out the UX to see how it interacts with the backend and how intuitive it is for users. Evaluating the project state at this point will indicate if you’re ready to develop the final style, or if the team needs to keep making adjustments to the UI.
You may think this approach will cause the project take longer to reach the point where the product looks as is should. But always remember this simple rule: “Adding is easier than removing.”
Lastly, if your organization is developing an app and needs some design help, or needs help updating or extending an existing application’s UI/UX, please check out our Mobile UI/UX Design Kickstart or simply reach out to us—we’d love to help you get started.