At what stage should the (G)UI be designed?

Question

I'll take out the ellipsis to make this easier/quicker to read:

Large group project in school, stakeholders gave a fuzzy explanation as to what they want. I suggested that we:

1. sketch the GUIs so we all understand what is requested, find problems, ask eachother questions, to clarify in general so we all think of the same thing
2. make use cases
3. present it all to the stakeholders for feedback
4. derive requirements from that
5. get feedback on the list
6. make a backlog
7. and then we discuss & pick tools, languages, frameworks, standards etc.

1-2 members agree with me, vast majority votes against it. Majority wants to:

1. discuss capabilities of several kinds of tools
2. then make use cases
3. then derive requirements
4. then backlog
5. then GUI design

Pretty much the same thing except that I want design first and tools last, but they want tools first and design last. Also I want more feedback than they want(though I think I can make a case for this to them, the main issue is GUI vs. choice of tools).

They weren't convinced by my rationale(you find problems first, then pick/make solutions), I wasn't convinced by their rationale(you can't find problems without choosing how to work and you can't know how to design without first defining overall back-end functionality/API). I think we will waste time preparing to use some tool and then find that we didn't need it at all, but that we need something else which we haven't spent time reading about or preparing for, but I don't know if I'm missing something out of inexperience.

What is the right way of doing this, and why?

Answer 1

From a real-life business standpoint, tools come in the back of the to-do list. I agree with your suggested list, though I'd move some things around a bit:

1. Functional requirements. I'm not talking about the amount of RAM the software is going to require but the stuff it is expected to perform. Getting requirements wrong can single-handedly throw your hard work out of the window because... well, you might build stuff no one wanted. And no one in the real world is going to pay money for that. Get the requirements straight. You should also ask your stakeholders to give examples of what they actually want to do, this will then be a good starting points for making "use cases".

2. Based on what you learned on task #1, make use cases - break down the stuff the customer wants into separate scenarios. They don't have to be long, it can be just a simple list (or a list of lists of) things the customer wants to do, for example: log in, upload an avatar, save a shopping cart, leave a comment...

3. Now, based on #2, you can make rough GUI sketches.

4. Meet with the stakeholders and get their feedback on the use cases and the GUI sketches. Make changes and meet again if needed.

5. When you agree on the initial functionality, start picking the tools that could deliver that. Someone might really really want to use some cool AI framework but if the project is a simple shopping-website, you probably aint going to need that.

This list is just a suggestion. Having an argument-based discussions with your fellow students is a very important part of the process, be it in the classroom or office.

Answer 2

The most important thing is to not decide on anything for as long as you can afford.

It does not matter that much what you do first as long as you are willing and capable to change it a couple of times in the course of development. It is supposed to be an iterative process. The more important the decision, the longer you will want to wait before making it final. Because you ultimately want it to be the right one.

So you can pick a tool based on a hunch and start prototyping. You can start writing a design document. You can create a database schema. None of which should limit the choice of any other part until you have a firm understanding of the problems you are to solve.

Gradually some pieces should fall into place.

Pouring an arbitrary part into concrete before understanding what you are up to is a recipe for failure.

Answer 3

When you say this is a large group project for school, I assume you mean an assignment that ten or more students are supposed to work on together. In which case:

Learning how to work collaboratively is the whole point.

Successful commercial software hasn't been the result of individual effort since the days of Atari video games and early Apple II office tools. Software projects today are collaborative efforts. (Read the credits on a modern video game if you don't believe me.) Academic assignments where the students are asked to do large(er) scale collaboration for the first time often result in one person doing all the work and everyone else grumbling. You should consider that a failure outcome.

A successful outcome for this project is one where everyone on the team is engaged and productive, and the resulting work product is better that any one of you could accomplish by yourself.

You aren't going to get there by trying to convince a "vast majority" that their work plan is wrong and yours is right. Rather, the whole team needs to realize that there are a bunch of things to figure out, some of which are interdependent, and your instructors are deliberately not giving you complete information up front.

Specifically regarding the GUI question in the title: It can be helpful to have sketches of possible GUIs early, because many people (including business stakeholders) are more comfortable discussing requirements and features in the context of a visual reference (as opposed to in the abstract). But in those discussions you may learn that the underlying GUI metaphor is wrong, or that the users would be better served by a phone app rather than a desktop webapp (or vice versa), or that some other initial working assumption is off base. Don't confuse early sketches with a finished design.

No matter what you start with (GUIs, tools, functional requirements, etc) the initial steps are provisional. They're ideas the team members are pitching to each other, and then to the stakeholders. The eventual solution will probably be a combination of some of them plus other stuff you haven't thought of yet.