6 ms·

Hacking: Always Design the UX First

68 points by systemizer 14y ago

jdludlow 14y ago
Speaking of UX, this is what that page looks like when JavaScript is disabled. https://img.skitch.com/20120604-e4x8dgp8u82akj7ngmyhywbtdb.png https://img.skitch.com/20120604-e4x8dgp8u82akj7ngmyhywbtdb.p...
- sp332 14y ago
  So... don't do that then. My browser is set to deny requests to other domains by default, so the whole page is blank for me. But I'm not complaining about it because that's my choice. Edit: oddly, Readability works fine.
- speg 14y ago
  When I tried to view it from Instapaper on my phone I also got a blank page.
- systemizer 14y ago
  Sorry about that guys. I just started using Blogger's new blog theme. I assumed they would account for javascript-disabled clients, but I was wrong. I'll fix that asap. thanks!
- kenrikm 14y ago
  Try it on the iPad.. The UX completely breaks.
jorgeleo 14y ago
For me the UI should be just one example of how the API of the model can be used, the model is the engine, the UI is the tool that the user manipulates to move the engine. I guess there are different schools.
- iMark 14y ago
  Importantly, it's also likely to be the first example, and failing at the outset will make it difficult to gain any sort of traction.
amishforkfight 14y ago
I need to learn from this. I'm usually too excited to start turning out some code, and I almost always end up at a dead end a few weeks later (talking about personal side projects).
brlewis 14y ago
Always be cautious of advice that starts with the word "always". The UX you design first might preclude an innovative approach that you would have discovered if you had just started coding first without a plan.
- skbohra123 14y ago
  Fittingly, your advice is also starting with always.
  - dllthomas 14y ago
    I assume that was the joke.
AznHisoka 14y ago
Designing the UI first also boosts morale b/c it gives you a tangible sense of progress, and you get to see what the end product looks like.
- kylebrown 14y ago
  Yes, but be wary of showing a prototype UI which works as if the functionality/back-end is also working. Even if you stress that its not, the client will understand that the functionality is already working if they can see it, and won't understand what you're doing afterwards or why the back-end is taking so long. Be especially careful with making assumptions about complicated functionality and back-ends, as they are difficult to estimate and clients grow very frustrated after they've already seen everything "working".
  - ilkandi 14y ago
    I'm not afraid of a temper tantrum, it shows the client cares. Showing a basic UI that was generated by the use cases will confirm that you understand the client needs, reduces miscommunication and clearly highlights the feature creep you should be charging for. It helps the client sell the project to whoever she reports to. It's easier to change a UI and it's a stronger emotional lock-in for the client (so she doesn't cancel). Win all around!
robomartin 14y ago
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).
- lovskogen 14y ago
  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.
- systemizer 14y ago
  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.
kappaknight 14y ago
I concur. It's much easier to plug in functionality and DB objects into a finished UI/UX than the other way around. Also, it allows the hacker to just work on the core functionalities instead of worrying about how their code is supposed to output to fit into an unpainted canvas. Obviously if you're working on an API, this doesn't apply - but you'd be surprised at how fast the hacking sprint can get when you know exactly where to plug your code into.
- scottschulthess 14y ago
  I'd probably recommend having an example app that uses the API anyways :)
  - dllthomas 14y ago
    And the API itself is UX for developers...
jsavimbi 14y ago
Within the constraints of a hackathon-type scenario, in general I would hypothesize about the expected user interactive results (the experience) model my data, establish the basic CRUD and wrap the UI around that, tailoring the experience to what the actual user outcome will be. If you do it in the order listed in the post you'll end up spending too much time with a UI and later having to model the data around it. That's backwards. tl;dr: hypothetical use case, data model, CRUD, UI, test for results.
Goladus 14y ago
If the main problem you are solving is a usability problem, a domain-specific language syntax, for example, or maybe a new photo-sharing app that's better than all the other photo-sharing apps, then the top-down UX-first approach is better. If you are mainly trying to solve anything else, it's probably better to focus on that first and make sure the data models, APIs, algorithms, or other key features are solid. An exception to this could be when you just need to get something up and running for morale reasons, so you can begin iteration. (Although in that case I would still argue that focusing on the UX isn't critical)
anon-for-now 14y ago
I immediately dismiss any posts claiming to know the superlative of anything -- best/worst, always/never, dead/alive. Yet, somehow, I've manage to consistently hack successful things. My advice: Avoid linkbait articles like this, and instead spend the time actually building something. Really, it truly is that simple: Build something. In any order. With any technology.
ighost 14y ago
The authors makes it sound like after designing the UX, the implementation will become trivial. I think this is a bit naive because most serious applications go through many iterations of UX. Some of these changes will be small and not require significant re-plumbing, but others will necessitate a lot of behind-the-scenes churn. My point is that it's better to design the plumbing of an application with some longer-term considerations than just "what do we need to implement that UI wireframe." Minimal viable products are cool and all, but let's not use that as an excuse to write something that will need to be thrown out wholesale to add that big traction-building feature.
eswangren 14y ago
If you're designing the UI first, you're not "hacking" anything.
sktrdie 14y ago
The site doesn't seem to load.
loudin 14y ago
Wanted to jump in on this. Like any problem, the answer is "it depends". If you are building an application that relies on having an extremely slick UX, you should probably start there. If you're creating an app that you want to be a workhorse or relies on a highly experimental feature, start at the implementation level. With that said, I do feel like teams of pure programmers have a tendency to overlook the UX in favor of diving right into the code. The article is a great reminder that it takes more than wonderful code to solve a problem. In fact, the less code the better.

68 points by systemizer 14y ago

Speaking of UX, this is what that page looks like when JavaScript is disabled. https://img.skitch.com/20120604-e4x8dgp8u82akj7ngmyhywbtdb.png https://img.skitch.com/20120604-e4x8dgp8u82akj7ngmyhywbtdb.p...

sp332 14y ago
So... don't do that then. My browser is set to deny requests to other domains by default, so the whole page is blank for me. But I'm not complaining about it because that's my choice. Edit: oddly, Readability works fine.
speg 14y ago
When I tried to view it from Instapaper on my phone I also got a blank page.
systemizer 14y ago
Sorry about that guys. I just started using Blogger's new blog theme. I assumed they would account for javascript-disabled clients, but I was wrong. I'll fix that asap. thanks!
kenrikm 14y ago
Try it on the iPad.. The UX completely breaks.

jorgeleo 14y ago

For me the UI should be just one example of how the API of the model can be used, the model is the engine, the UI is the tool that the user manipulates to move the engine. I guess there are different schools.

iMark 14y ago
Importantly, it's also likely to be the first example, and failing at the outset will make it difficult to gain any sort of traction.

amishforkfight 14y ago

I need to learn from this. I'm usually too excited to start turning out some code, and I almost always end up at a dead end a few weeks later (talking about personal side projects).

brlewis 14y ago

Always be cautious of advice that starts with the word "always". The UX you design first might preclude an innovative approach that you would have discovered if you had just started coding first without a plan.

skbohra123 14y ago
Fittingly, your advice is also starting with always.
- dllthomas 14y ago
  I assume that was the joke.

AznHisoka 14y ago

Designing the UI first also boosts morale b/c it gives you a tangible sense of progress, and you get to see what the end product looks like.

kylebrown 14y ago
Yes, but be wary of showing a prototype UI which works as if the functionality/back-end is also working. Even if you stress that its not, the client will understand that the functionality is already working if they can see it, and won't understand what you're doing afterwards or why the back-end is taking so long. Be especially careful with making assumptions about complicated functionality and back-ends, as they are difficult to estimate and clients grow very frustrated after they've already seen everything "working".
- ilkandi 14y ago
  I'm not afraid of a temper tantrum, it shows the client cares. Showing a basic UI that was generated by the use cases will confirm that you understand the client needs, reduces miscommunication and clearly highlights the feature creep you should be charging for. It helps the client sell the project to whoever she reports to. It's easier to change a UI and it's a stronger emotional lock-in for the client (so she doesn't cancel). Win all around!

robomartin 14y ago

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).

lovskogen 14y ago
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.
systemizer 14y ago
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.

kappaknight 14y ago

I concur. It's much easier to plug in functionality and DB objects into a finished UI/UX than the other way around. Also, it allows the hacker to just work on the core functionalities instead of worrying about how their code is supposed to output to fit into an unpainted canvas. Obviously if you're working on an API, this doesn't apply - but you'd be surprised at how fast the hacking sprint can get when you know exactly where to plug your code into.

scottschulthess 14y ago
I'd probably recommend having an example app that uses the API anyways :)
- dllthomas 14y ago
  And the API itself is UX for developers...

jsavimbi 14y ago

Within the constraints of a hackathon-type scenario, in general I would hypothesize about the expected user interactive results (the experience) model my data, establish the basic CRUD and wrap the UI around that, tailoring the experience to what the actual user outcome will be. If you do it in the order listed in the post you'll end up spending too much time with a UI and later having to model the data around it. That's backwards. tl;dr: hypothetical use case, data model, CRUD, UI, test for results.

Goladus 14y ago

If the main problem you are solving is a usability problem, a domain-specific language syntax, for example, or maybe a new photo-sharing app that's better than all the other photo-sharing apps, then the top-down UX-first approach is better. If you are mainly trying to solve anything else, it's probably better to focus on that first and make sure the data models, APIs, algorithms, or other key features are solid. An exception to this could be when you just need to get something up and running for morale reasons, so you can begin iteration. (Although in that case I would still argue that focusing on the UX isn't critical)

anon-for-now 14y ago

I immediately dismiss any posts claiming to know the superlative of anything -- best/worst, always/never, dead/alive. Yet, somehow, I've manage to consistently hack successful things. My advice: Avoid linkbait articles like this, and instead spend the time actually building something. Really, it truly is that simple: Build something. In any order. With any technology.

ighost 14y ago

The authors makes it sound like after designing the UX, the implementation will become trivial. I think this is a bit naive because most serious applications go through many iterations of UX. Some of these changes will be small and not require significant re-plumbing, but others will necessitate a lot of behind-the-scenes churn. My point is that it's better to design the plumbing of an application with some longer-term considerations than just "what do we need to implement that UI wireframe." Minimal viable products are cool and all, but let's not use that as an excuse to write something that will need to be thrown out wholesale to add that big traction-building feature.

eswangren 14y ago

If you're designing the UI first, you're not "hacking" anything.

sktrdie 14y ago

The site doesn't seem to load.

loudin 14y ago

Wanted to jump in on this. Like any problem, the answer is "it depends". If you are building an application that relies on having an extremely slick UX, you should probably start there. If you're creating an app that you want to be a workhorse or relies on a highly experimental feature, start at the implementation level. With that said, I do feel like teams of pure programmers have a tendency to overlook the UX in favor of diving right into the code. The article is a great reminder that it takes more than wonderful code to solve a problem. In fact, the less code the better.