(See my earlier posts for introduction to the series.)
After that, it starts to be clearer what the main components of the concept are. In a mobile device those could include a home screen, a menu and application management, controlling settings, managing content and files, etc. Now you can assign a sub-team to work on each of these.
Every component has a purpose. There are a group of requirements that the component simply must fulfill. It must provide the functionality assigned to it. For example, you could set the expectation that a main menu of a mobile device can accommodate also shortcuts and web bookmarks. If at some point the designers of the main menu would conclude that including web bookmarks isn’t possible after all, you need to find some other component in the UI framework that will take on the responsibilities that this component is not fulfilling. Sometimes such knock-on effects will cause a long chain reaction of changing roles in different components, until you find a solution where all the requirements are satisfactorily met.
Understanding the big picture of a full UI concept is not easy. In particular it is almost impossible for other people outside the design team to understand the knock-on effects that changes will have. This will lead many frustrating but unavoidable discussions where reviewers, quite often in managerial roles, will request you to include X in your design just like a competitor Y just launched. You can’t start changing one part of the UI without changing many other parts too. It’s a puzzle, and all the pieces must fit.
Photo credit: http://www.flickr.com/photos/dps (c) Creative Commons
0 Comments