Comment by robomartin | Hacker News Reader

Comment by robomartin | Hacker News Reader

I disagree with this. Think of the basics of the UI if you'd like, but this idea of creating it first might only apply to a narrow project definition.

In my view you must think in terms of data models / data representation first. Then you move on to CRUD. At that point you might move into some of the functionality above CRUD and other app mechanics (for example: login, authorization, verification, support interaction, etc.). At this stage, if we are talking about a web project, the UI doesn't need to look any prettier than a Craig's List page.

Once that reaches flight altitude (meaning, that the basics are working) the UI can become the focus.

This becomes particularly true when you consider multi-platform applications. Say you have an app that needs to run on the web, mobile-web, as well as various phones and tablets. If the UI is first, which one? They are bound to be different. If you focus on the UI first you might do things that skew the model to suit a particular platform.

I you believe in MVC then you ought to be able to separate the three through specifications and marry them once each has reached a certain level of compliance with said specifications. Of course, there are difference that contrast a solo developer/designer vs. a multi-person team.

I want to see the engine sputter, backfire and pop before I try to optimize anything and make it pretty (UI).

I strongly disagree. Of course I understand what you mean about proof-of-concept - your analogy of testing the engine is a good one. But think about wher the engine is to be fitted: if the UI is not well-specified, then the best engine in the world will only help you crash or blow things up faster.

you can't build good data structures until you have a clear idea of the information you want to gather and manipulate for the task you propose to solve, and often that involves going to other people in a specific market and asking them how they do things. I have lost count of the number of software packages I've looked at and asked 'why is X so awkward' only to receive the reply that it 'had to be that way' because of something on the backend. This is what happens when you build data structures that are half-adequate to the task at hand and then have to have other things shoehorned into them.

Well, funny enough, I am one of those guys who is equally comfortable doing mechanical, electrical and software engineering. In all cases, the "beautification" of the product happens after the underlying principles, data structures, circuit fundamentals, loads, thermal requirements, etc. are well understood and have gone through many prototyping and testing phases. I am not talking about minimum-viable-product stuff here.

Yes, if the goal is a minimum-viable-product type web solution, by all means, make it pretty and fake the rest until you see enough traction to figure out if there's a real business.

For nearly anything else, the internals need to be well understood before it makes sense to do anything else. I can't think of one mechanical design I've done where I spent a ton of time figuring out color, size, shape and location of buttons and knobs before fully understanding what needed to go inside the box, what the electronics was going to look like, communications protocols, power supply requirements, environmental requirements, etc.

So, yes, if I was going to design a car I'd start by selecting an engine, drive train and suspension components and then designing the of the vehicle rest around it. You'd fit artists concepts and renderings to the realities of the underlying mechanics. It then becomes an iterative process where you push and pull and make adjustments to both the artistic expression and the technical realities of the design in order to converge on a product that can be released.

Let me state the obvious: These analogies are all imperfect.

A good user experience isn't 'making it pretty' or 'beautification' – this is 2012, I thought this was repeated enough.

You make good points, and I do agree that multi-platform applications require a general enough server-side interface for many different types of clients.

However, you're still going to initially design your application based on a single interface, whether that be an iphone, browser, or tablet. While the implementations will differ, the UX between all the clients should be consistent.

In the article, I put UI ahead of CRUD because I believe the UI is closer to the UX and better helps you achieve your UX. And by UI, I mean a very very simple user interface. Hold back your creative artsy mind and just make sure you have the actions on the page.

thanks for the comment.

There's a third scenario.

Leave the data model alone, and stop thinking about the UI. Do some real design.

Consider a simple example - registering a user account.

Assume the product vision statement calls for a thick client desktop application that synchronises data to other desktop clients via a server. To use the sync service you need an account. On the client, you put up a form that asks the user for a user name and password. Easy. What happens when the call to the server is made to register that account?

Does the UI just lock up until the call returns? Does the UI remain responsive? Does a responsive UI allow the user to cancel the request? Is the technology chosen to build this thing even capable of asynchronous service calls?

When the data is sent over the wire, how is it protected? When it hits the server, how and where is the password stored? Is the request logged? Will server logs be of use to anyone? What error conditions are checked on the server, what corresponding messages are sent back to the client, and how are these communicated to the client? Is there a retry button the user can hit when it bombs? Should the client use a database/temporal cache/config file to store the user name and password in case the server is unreachable?

That was a very simple use case. [Edit] My point is that those questions demonstrate that the data model as well as the UI might radically change based on other design decisions you should be making first. To answer those questions you need to do some design work.

Design work means analysis to get business, user, system, and operational requirements.

Then you need to think about availability, backup and recovery, capacity, communications, deployment, end user support, data migration, monitoring, performance, pilot program, security, system support.

It's called an architecture.

[Second edit] The agile police is probably going to jump on me for what I wrote. Let me pre-empt that by adding that even little web apps have what may appear to be very simple use cases that can bite you in the ass.

I go to MIT and have taken graduate courses in OS design, database design, and distributed systems. I am more than aware of the issues of byzantine errors, fault tolerance, and replication, etc; however, my post is not about that. My post is about how to approach "hacking" a minimal viable product together and guidelines for making that process efficient. The issues that you present are not relevant to this post and can be abstracted away for this context.

If I had to guess why your response was downvoted (wasn't me) I'd say that it's because you didn't make this clear in your post. That said though:

In my opinion(!!) hacking out a minimum viable product (MVP) should still go through an up-front design phase. Before any UI work or data modelling is done.

Anwering those questions will help determine what that MVP will look like, and whether it will annoy users or have them wanting more. Apart from the obvious technical benefits it provides direction, motivation, and (one scenario) if you're looking for funding will help you articulate not just the product vision, but the technical roadmap, risks and, above all, provide a reasonably-informed estimate that will drive your financial models.

It's awesome that you go MIT.

There is a huge difference between designing the experience (UX) and the designing the interface (UI). I don't know if you got them mixed up, but I don't think the title suggests doing the interface design first, but the experience.

This can be done in writing on a piece of paper.

I agree with you, but I believe it is different with experience. If you are new then you might think aobut the UI level because it is easier to visualize what the web program is going to do. If you have been making web programs forever, I find it easier to think at the database level and create all of the tables/fields. Then I think about how the interface visually is going to handle the data.

I would agree, if you already understand the business problem. However the UI is often the only thing you can discuss with the client; few clients are going to be able to react to a data model but most can engage in a discussion based on a proposed UI design, which can then help you, the analyst, understand what you need to capture in your data model.

Reply on news.ycombinator.com