This chapter is from the book
This chapter is from the book
This chapter is from the book
Reiterating Before It’s Too Late
One of the primary goals of interaction design is to be constantly iterating on an implementation in an effort to improve upon the original work. Although you’ve already done this for a wireframe, you now have actual art assets in PNG or another format along with full Photoshop design files that will aid in a more complete analysis.
Now is the perfect time to sit down and review your design work with every stakeholder in the project, from the client who’s funding it to the programmer that’s implementing the design. The following five questions are often simple and easy to answer when working only with concept art designs, but they’ll grow more difficult and expensive to resolve once the application becomes actual lines of code, so it’s best to address them now:
Does the app look like it will fit in with the platform?
It’s a designer’s prerogative whether he or she wants the work to blend in on the platform or not, so this question can often be answered either positively or negatively and still be OK, depending on the person’s intentions. What’s most important, though, is creating a coherent design that looks and acts like mobile software.
Will users be able to use the application with no guidance?
Long gone are the days in which each piece of software came with a hefty instruction manual. Mobile apps must be capable of remaining useful while standing alone, because the production team won’t be there to guide the user along the way. This question can often be answered by showing the Photoshop work to another tech-minded person who can offer an outside perspective while also understanding what the designs in the program are intended to represent.
Can the programmer implement the design with art assets and design documentation only?
Most likely, a designer will be working hand-in-hand with the programmers on a project, who will hopefully be able to ask questions about why something was designed the way it was and how it should be implemented. This isn’t always the case, though, and designers should be prepared for that possibility. Once design documentation is handed off to a manager or programmer, they should be able to deduce the designer’s intentions and planned interaction design without being required to check in with concerns every five minutes. If a programmer can’t create a design with only the documentation provided, more work is likely.
Will the design age gracefully?
Age can wear heavily on things, and mobile apps are no different. There’s an adage frequently quoted when creating logos for corporations or businesses that says that the goal should be to design something that would have looked outstanding 100 years ago, would look outstanding today, and will look outstanding 100 years in the future. Strive for a general style and brand that will remain tasteful and visually appealing as an operating system or platform changes over time. This can vary in difficulty based on platform, but it’s wise to avoid trendy “flavor-of-the-week” design practices that will fall out of fashion quickly. Instead opt for classic, traditional, platform-friendly looks.
Does the design meet future project goals?
A lot of new designers get tripped up in their development by creating a great first version of an app but failing to allow space for future feature improvements that will be necessary in subsequent releases. Designs shouldn’t be handcuffed by hypothetical “maybes,” but it is important to consider how an application’s design might evolve after another six or twelve months of work. Take a journaling application, for example, in which a designer uses a swipe interaction to open various menus but fails to recognize that the app’s 2.0 release will include a photo-adding function in which users will swipe to move through pictures. This will cause an interaction conflict, leading to a complete design overhaul a few months after launch, complete user confusion, a completely unreliable design, or some other terrible cocktail of those poor-design consequences.
As you get more and more involved with the world of software, you may run into an increasingly common programming approach called agile software design that runs in direct contradiction to the strategy just outlined. Agile software design involves design and programming team members working out basic features and plans to constantly add more to the product based on user response, testing, and developer experience. It’s a great strategy, but only for those who are quite familiar with software development and are comfortable with how to handle a product constantly in motion. If you’re new to design and programming, hesitate before adopting this strategy; you may be better off thoroughly thinking through a design prior to the start of programming.