The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Design: where to begin?

I'm pretty sure Joel or someone would say that you need functional specification first.  However, here is something that happens quite often at my shop:

Client wants to redo an application. Said client does screen captures of thier current app and puts little annotations for new functionality desired.

Let's assume that's good enough for a functional specification.  From there where do you go?  I ask this because I've always thought it best to go after the data model first BEFORE doing anything with the UI.  My rational for this was to figure out where I could pull data from whereever it was stored, and also force myself to understand some of the issues involved with the functionality of the application. 

Recently I heard one of the 37 Signals guys say that they start everything off by designing screens and UI. That's a bit of contrast to what I thought was common...

But I'm not sure here, anyone have a specific approach to this?
David Seruyange Send private email
Sunday, January 29, 2006
 
 
Implementing the UI turns out to be the best way to learn the data model.
Ben Bryant
Sunday, January 29, 2006
 
 
UI can be a fair indiciator of what you may need to store.

But, a good UI is usable by a new person, and doesn't make you remember things if you use it infrequently, but doesn't bother you much either, and has those special actions just within reach for the experianced user.

having balanced all that, does it still accuratly reflect the best way of storing the information to drive it?

probably not (from my experiance) but it should show the bsaics of what you need to deal with and progress from there.

there is also the point, if you can't express it in 'the interface' (and who is to say there is only 1) then the feature is probably over engineered (you astronaught!)

Monday, January 30, 2006
 
 
This is an interesting question. If you talk to UI guys they are absolutely about doing UI first, and if you talk to data modelling experts they are absolutely about doing the data model first.

I don't really know if there is an absolutely correct answer because I tend to start of abstract the problem space into entities anyway but I will make this observation.

Data modelling experts will often ask their clients for a set of artifacts including paper forms in order to define the data model. In essence the paper form is a type of UI - so in reality, you always start with some kind of UI.

The only time you wouldn't (because you couldn't) derive the data model with some kind of UI (paper, existing application) is when its completely new business - and how often does that happen?

I've been in the UI first camp for a while now because I think the user experience with the product is so important, but I do appreciate the need for a really solid data model which offers room for growth.

- Mitch
Mitch Denny Send private email
Monday, January 30, 2006
 
 
Give the client what he wants. If he wants to focus on the GUI now, do it.
MBJ Send private email
Monday, January 30, 2006
 
 
Hi David,

I’ve typically gone down the UI path. I recall the first time (years ago) that I showed a database’s ER schema to a client. You could literally see their eyes glaze over. Not only did they not understand it, they didn’t want to understand it. Third normal form? What’s that?

I’ve had more success starting with a UI (after discussing and fleshing out requirements). Designing the UI also forces you to put clarity around entity relationships by having to describe how the various screen fields relate to each other. As it also allows the client to visualise what data will be captured and how, it often prompts them to recall business rules or omitted fields which are often overlooked in an ER schema and a slab of documentation.

I agree with Mitch’s comment – the need for a solid data model is still a mandatory deliverable, but I believe this should be a result of a customer centric focus which places the user experience first.

Regards
Marcus from Melbourne
Monday, January 30, 2006
 
 
In the case of incremental changes to an existing system, and especially where these are specified as changes to the interface, I'd be inclined to work from the UI back.

Monday, January 30, 2006
 
 
Thanks everyone, very educational.
David Seruyange Send private email
Monday, January 30, 2006
 
 
Here's why UI-first makes sense: USERS. I don't give a crap what my data model looks like, as long as its dang close to third normal form. Other than that, the whole challenge is to figure out how we can store data to do what the user wants to do. And what drives the user's experience is not how our tables are split, whether or not we use lookups based on text values or identity values, or any of that. What drives the user experience is what they see on the screen, and the degree to which the application affords efficient, understandable work flow.

Figure out which portion of the users job will be done with your application.

Figure out how to make that work happen as efficiently and understandably as possible.

Figure out what needs to support that--code, data structure, documentation, etc.

Sit back and wait for the letters of appreciation from your users.

Jeremy
Jeremy Wallace Send private email
Monday, January 30, 2006
 
 
Another way to re-state what others have already said:

As creators of software, we build from the inside out: data models, with UI layered on top, and some vague notion that there's a user experience beyond the realm of our software, out there somewhere. As such, it's vital that at least SOME of the technical design focuses on data first, since programmers will find it easiest to deal with.

However, as designers we must also remember that the end-users experience our software from the outside in: their direct interaction with our software is all they generally notice, and maybe if they're technically inclined and get proficient at our software they'll start to grok the UI, and maybe someday they'll even build some vague mental picture of the data model. As such, it's also vital that SOME of the design focuses on user experience first, since that's what ultimately determine if your software gets used.

It's probably best to start design from the user's point of view, but document from the programmer's point of view. Understand both ways of looking at the software and make sure they are consistent with one another.
Ian Schreiber Send private email
Monday, January 30, 2006
 
 
While this topic may be confusing the design process (in particular the software design process) with the act of design I would like to add my two pence. Before we had a GUI we still had a design process. We based the design on the required outputs - a key analysis or 20 pallets of product shipped or 100 tonnes of feedstock ordered. We then added in the contsraints - perhaps lead times, availability of key data etc. and then based the core design around the outputs and constraints. I still think that this is crucial - yes the UI is important but it is only one of the outputs.
Mike Griffiths Send private email
Tuesday, January 31, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz