The members of a systems development project team have gone out for lunch together, and as often happens, the conversation has turned to work. The team has been working on the development of the user interface design, and so far, work has been progressing smoothly. The team should be completing work on the interface prototypes early next week. A combination of storyboards and language prototypes has been used in this project. The storyboards depict the overall structure and flow of the system, but the team developed language prototypes of the actual screens because they felt that seeing the actual screens would be valuable for the users.
Chris (the youngest member of the project team): I read an article last night about a really cool way to evaluate a user interface design. It's called usability testing, and it's done by all the major software vendors. I think we should use it to evaluate our interface design.
Heather (system analyst): I've heard of that, too, but isn't it really expensive?
Mark (project manager): I'm afraid it is expensive, and I'm not sure we can justify the expense for this project.
Chris: But we really need to know that the interface works. I thought this usability testing technique would help us prove we have a good design.
Amy (systems analyst): It would, Chris, but there are other ways, too. I assumed we'd do a thorough walkthrough with our users and present the interface to them at a meeting. We can project each interface screen so that the users can see it and give us their reaction. This is probably the most efficient way to get the users' response to our work.
Heather: That's true, but I'd sure like to see the users sit down and work with the system. I've always learned a lot by watching what they do, seeing where they get confused, and hearing their comments and feedback.
Ryan (systems analyst): It seems to me that we've put so much work into this interface design that all we really need to do is review it ourselves. Let's just make a list of the design principles we're most concerned about and check it ourselves to make sure we've followed them consistently. If we have, we should be fine. We want to get moving on the implementation, you know.
Mark: These are all good ideas. It seems like we've all got a different view of how to evaluate the interface design. Let's try and sort out the technique that is best for our project.
Develop a set of guidelines that can help a project team like the one discussed here select the most appropriate interface evaluation technique for their project.
Trending nowThis is a popular solution!
Step by stepSolved in 2 steps
- Design ideas for the system's user interface. Support your suggestion with the right prototype. Any language you know may be used.arrow_forwardAssume the development environment is Unix workstations, and the documentation team uses the Macintosh platform for writing documentation. The client requires the documents to be available on Windows platforms. Developers produce the design documentation using Frame Maker. The documentation team uses Microsoft Word for the user-level documentation. The client submits corrections on handcopies and does not need to modify the delivered documents. How could the information flow between the developers, the technical writers, and the client be set up (e.g., format, tools, etc.) such that duplication of files is minimized while everybody's tool preferences and platform requirements are still satisfied?arrow_forwarddocumentation as a primary focus Is this not the case in the conversion phase of the development life cycle? explain?arrow_forward
- documentation as a primary focus Is this not the case in the conversion phase of the development life cycle? explain?arrow_forwardDesign ideas for the system's user interface. Support your suggestion with the right prototype. Any language you know may be used.arrow_forwardThe application being created determines the importance of each model used in software development. Could you categorise these models by your preferences?arrow_forward
- Apply the following methods with an appropriate illustration (project where they can be used) vast amounts of made-up information and viewpointsarrow_forwardThe point system used for user stories can represent days or even hours of work. It's really up to the development team to decide. Care should be taken to choose a point system such that you can easily agree on the number of points for a story. True/Falsearrow_forwardThe project's map will be easier to understand if it is drawn with and without the central architecture. Thinking about how things will turn out in the end.arrow_forward
- Determine what documentation a developer should have at the conclusion of a project.arrow_forwardWriting a programme with methods allows various programmers to write independent methods, dividing the job. Answer these questions using this idea: Would you rather build a large programme alone or in a team where each programmer writes one or more modules? Why? How would you handle a large development team? How can you overcome these obstacles?arrow_forward
- Computer Networking: A Top-Down Approach (7th Edi...Computer EngineeringISBN:9780133594140Author:James Kurose, Keith RossPublisher:PEARSONComputer Organization and Design MIPS Edition, Fi...Computer EngineeringISBN:9780124077263Author:David A. Patterson, John L. HennessyPublisher:Elsevier ScienceNetwork+ Guide to Networks (MindTap Course List)Computer EngineeringISBN:9781337569330Author:Jill West, Tamara Dean, Jean AndrewsPublisher:Cengage Learning
- Concepts of Database ManagementComputer EngineeringISBN:9781337093422Author:Joy L. Starks, Philip J. Pratt, Mary Z. LastPublisher:Cengage LearningPrelude to ProgrammingComputer EngineeringISBN:9780133750423Author:VENIT, StewartPublisher:Pearson EducationSc Business Data Communications and Networking, T...Computer EngineeringISBN:9781119368830Author:FITZGERALDPublisher:WILEY