design solutions and the UI designer
What is design?
Hmmm. We could go off the cliff here, if we aren't careful. Design means many things in different contexts, so we should qualify the question by defining design in the context of its application. Since I am currently helping produce web-based software applications, let me talk about design in the context of software development.
I could be more specific and limit the discussion to designing for the web environment alone, but that would limit us, especially since a great deal of the application design for the web is dependent on the operating system and browser that is being utilized. Some day in the future, our computers will be reduced to network appliances that will be not have any resident software at all.
So then… in the context of software development, design is generally the second stage in the development life-cycle, after requirements analysis. The design stage of the development life-cycle determines how the required functionality can be achieved.
In contrast to the requirements/analysis stage which concentrates on what functionality is required, the design stage provides an opportunity to the design team to explore how the functionality can be achieved. In the design phase, a team may come up with a number of design solutions that could potentially meet the stated requirements. Each of these potential solutions represents a structure that needs to be analyzed in terms of implementation details.
What does this mean? It means that the design team now has to analyze each potential solution that has been proposed for its feasibility and justifiability to the client (customer) and users in terms of its cost in time, resources and money; efficiency, usability, flexibility, code/component reuse; supportability over the estimated life-cycle and adaptability to changes driven by market forces and technology evolution. Thus, the team needs an analytical process to evaluation each potential solution to arrive at a final (preferred) design solution to be able to provide recommendations to the customer/users.
It would be well for us as design team members to remember that in spite of careful reasoning and anaysis, and even though the solution we propose may be optimal, an organization may decide to adopt a sub-optimal or modified solution based on other, non-quantifiable variables that may have changed the business environment during the design/analysis processs.
Often, the less-than-optimal choice may be the result of caprice or lack of understanding on the part of a client representative (human, after all) or due to prior commitment made as part of another project that cannot be changed or revoked. Most of the time, sub-optimal choices are made because of incorrect assumptions, a poorly defined requirement or because of information that was not provided during the planning or requirements analysis stages.
As part of the design team, the UI designer is tasked with providing the best possible interface to the application to the users that meet their task requirements and satisfy the business goals. Since there may be several possible design solutions, the UI designer has to work with the team to develop interfaces that will work with each solution - it would be great, of course, if the analysis proceeded rapidly and the team was able to discard some of the solutions prior to UI design, and reduced the possibilities to just one or two.
Ideally, the team should be able to discuss the pros and cons of each solution to the client and arrive at the best possible solution in the early stages of design, prior to the UI being prototyped. I've noticed that in many cases, the documentation and discussions related to the anaysis and recommendations are too abstract for the client representatives and user representatives, and graphical representations (mock-ups) of UI screens do not always get the subtler advantages and disadvantages of each potential solution across.
In such cases, the UI designer would benefit from being "in tune" with the rest of the design team and getting a feel for the "preferred" solution that will be most likely chosen for implementation given the circumstances. Designing an UI in isolation, when there are multiple potential solutions will lead to frustration on the part of the UI designer, and confuse the client further - for example, an UI designer may develop an interface for a solution that he or she feels will be most "user-friendly" and still meet business requirements, while the rest of the team may be considering a solution that meets business requirements and rigid security requirements, but may be sub-optimal in terms of "user-friendliness".
Instead of becoming a battle of wills between the UI designer and the project team, with the "user" being the bargaining chip, it would speak well for our profession as a whole if we were able to take a solution that is sub-optimal in terms of user-friendliness and make it more usable through our creative efforts.
Remember, anyone can design an "user-friendly" interface for optimal conditions - all you need is a set of guidelines and common sense - it is when we come up with a good solution under sub-optimal conditions that the mettle of the UI designer is tested.
Besides.. Your willingness to co-operate and work as a team member will gain you support from all involved parties, and make it easier to provide input and modifications to the solution based on your analysis and expertise.
After all, that IS the ultimate goal… being effective and a valued team member. Not the outsider.
_____________________________________________________
copyright 2004 ajoy muralidhar. all names or brands referenced are the copyright of their respective owners.
Hmmm. We could go off the cliff here, if we aren't careful. Design means many things in different contexts, so we should qualify the question by defining design in the context of its application. Since I am currently helping produce web-based software applications, let me talk about design in the context of software development.
I could be more specific and limit the discussion to designing for the web environment alone, but that would limit us, especially since a great deal of the application design for the web is dependent on the operating system and browser that is being utilized. Some day in the future, our computers will be reduced to network appliances that will be not have any resident software at all.
So then… in the context of software development, design is generally the second stage in the development life-cycle, after requirements analysis. The design stage of the development life-cycle determines how the required functionality can be achieved.
In contrast to the requirements/analysis stage which concentrates on what functionality is required, the design stage provides an opportunity to the design team to explore how the functionality can be achieved. In the design phase, a team may come up with a number of design solutions that could potentially meet the stated requirements. Each of these potential solutions represents a structure that needs to be analyzed in terms of implementation details.
What does this mean? It means that the design team now has to analyze each potential solution that has been proposed for its feasibility and justifiability to the client (customer) and users in terms of its cost in time, resources and money; efficiency, usability, flexibility, code/component reuse; supportability over the estimated life-cycle and adaptability to changes driven by market forces and technology evolution. Thus, the team needs an analytical process to evaluation each potential solution to arrive at a final (preferred) design solution to be able to provide recommendations to the customer/users.
It would be well for us as design team members to remember that in spite of careful reasoning and anaysis, and even though the solution we propose may be optimal, an organization may decide to adopt a sub-optimal or modified solution based on other, non-quantifiable variables that may have changed the business environment during the design/analysis processs.
Often, the less-than-optimal choice may be the result of caprice or lack of understanding on the part of a client representative (human, after all) or due to prior commitment made as part of another project that cannot be changed or revoked. Most of the time, sub-optimal choices are made because of incorrect assumptions, a poorly defined requirement or because of information that was not provided during the planning or requirements analysis stages.
As part of the design team, the UI designer is tasked with providing the best possible interface to the application to the users that meet their task requirements and satisfy the business goals. Since there may be several possible design solutions, the UI designer has to work with the team to develop interfaces that will work with each solution - it would be great, of course, if the analysis proceeded rapidly and the team was able to discard some of the solutions prior to UI design, and reduced the possibilities to just one or two.
Ideally, the team should be able to discuss the pros and cons of each solution to the client and arrive at the best possible solution in the early stages of design, prior to the UI being prototyped. I've noticed that in many cases, the documentation and discussions related to the anaysis and recommendations are too abstract for the client representatives and user representatives, and graphical representations (mock-ups) of UI screens do not always get the subtler advantages and disadvantages of each potential solution across.
In such cases, the UI designer would benefit from being "in tune" with the rest of the design team and getting a feel for the "preferred" solution that will be most likely chosen for implementation given the circumstances. Designing an UI in isolation, when there are multiple potential solutions will lead to frustration on the part of the UI designer, and confuse the client further - for example, an UI designer may develop an interface for a solution that he or she feels will be most "user-friendly" and still meet business requirements, while the rest of the team may be considering a solution that meets business requirements and rigid security requirements, but may be sub-optimal in terms of "user-friendliness".
Instead of becoming a battle of wills between the UI designer and the project team, with the "user" being the bargaining chip, it would speak well for our profession as a whole if we were able to take a solution that is sub-optimal in terms of user-friendliness and make it more usable through our creative efforts.
Remember, anyone can design an "user-friendly" interface for optimal conditions - all you need is a set of guidelines and common sense - it is when we come up with a good solution under sub-optimal conditions that the mettle of the UI designer is tested.
Besides.. Your willingness to co-operate and work as a team member will gain you support from all involved parties, and make it easier to provide input and modifications to the solution based on your analysis and expertise.
After all, that IS the ultimate goal… being effective and a valued team member. Not the outsider.
_____________________________________________________
copyright 2004 ajoy muralidhar. all names or brands referenced are the copyright of their respective owners.
posted by gentlepoet @ 8/16/2004 11:43:00 AM
0 Comments:
Post a Comment
<< Home