Often I see UX boiled down to this quote from the article:
"To build a great UX, one has to step back and think about what’s most important, try to come up with the most simple and shortest path to get there, build, analyze what works and why(not), measure, test, rinse, and repeat."
This is the "left-brained" part of UX, while there is the forgotten "right-brained" portion, which is typically based on the psychological impact of copy, typography, and visual polish.
For example, I worked for a company that wanted to remove all "distracting copy" from the form page so that the submit button was above the fold (and fewer distractions, etc.). We ran multivariate tests swapping copy, removing copy, rephrasing copy, you name it, to figure out what our visitors were actually responding to.
Our original "assurance copy" (letting the user know what the information is for, what's going to happen next, etc.) more than doubled our average time-on-page metric. However, our conversion took a ~27% drop when we removed it entirely, and incrementally better the more copy we had.
The users that did convert spent half the amount of time on the page (they were already committed to purchase by that point), but the rest of the users obviously needed assurance in the process, not necessarily the cheapest process.
This is the "left-brained" part of UX, while there is the forgotten "right-brained" portion, which is typically based on the psychological impact of copy, typography, and visual polish.
What you're referring to is the UI, the aesthetic design, layout and features that lends itself to an effective UX. They work hand-in-hand; like the OP had stated (paraphrasing), coming up with the simplest and shortest path to your goals that works, is important for the UX, and knowing your goals and how you want to reach them will help guide the UI.
It's tough to find someone who can focus on UX or to find someone who can translate the UX to a great UI. But it's the toughest to find someone who can do both. It's even harder to become that person.
> I think the greatest companies of the next few years will be build by teams that consist of people that can program AND can do UX.
I couldn't disagree more. I have never met anybody who can program AND do UX well. Maybe there are very very rare exceptions, but these two skills are pretty much mutually exclusive.
First of all, you need completely different modes of thinking while coding and while doing UX. Left/right brain, and all that. But more importantly, to be a good UX person, you need tons of training - design, marketing and psychology being three main areas. To be a great programmer, you need completely different set of training. Both UX and programming require single-minded attention, dedication and years to master.
To expect someone to do both of those things well is not only unrealistic, but plain WRONG.
It's hard to meet people like this because of attitudes like this. I have three designers on my team who are also world-class engineers, yet they often don't advertise themselves as such because they run into the "well if they do both they can't be good at either" attitude.
No-one bats an eye when an engineer also turns out to be a fantastic musician, or when an engineer drives great product decisions, yet somehow being able to code and understand design is an impossibility?
We're here to build great things - code and design are mutually-beneficial skills in your toolbox; your brain is not zero-sum.
I think you are going a bit over the top with regards to the complexity of what it is we do. There are plenty of other careers (http://en.wikipedia.org/wiki/Fallingwater) that require both creative and technical thought.
Does our position really require years to master? Is a java or ruby programmer with 10 years experience that much better than a java or ruby programmer with 3 years experience?
What about design? Is building a website, interactive component or application so complex that only those with decades of experience can really 'get it'? Is someone who has twenty years of UX experience, dating back to the days of VB and Access applications, that much better than someone with five years?
I believe combining technical with creative is something that must be taken as a given with our industry.
As a UX guy, I'm trying to learn how to program. It's very difficult, and requires a different mental model of learning. However, I recognize the immediate value that understanding programming concepts will provide in evaluating how feasible a UI schema is. It will help balance priorities – do we first deliver a feature then refine, or do we take the extra engineering time to provide an enhanced user experience from the get go? Of course, all of these priorities also need to be weighed against your business needs, and the immediate needs of your users.
I think your point actually reinforces the quote you disagree with. You say people with high levels of both skill sets are "very very rare," which is probably true, but that's exactly why the companies who have those people will become the greatest companies of the next few years.
Ever played an early PC game where the programmer also created the graphics? That analogy has stuck with me my entire life.
I think in the educational system, as children and young adults we are taught that we must excel at as much as we possibly can. When, the reality is, doing really well in one area means your skills in another will weaken -- especially when you are trying to do them at the same time.
Ever met an accountant novel writer who base jumps on the weekends? I haven't.
Time might be scarce and you cannot specialise in both. However the separations between different subjects do not exist because of differences in the brain. We categorise subjects in order to aid in efficient dissemination of information. There are social reasons for the soft boundaries which formed in the past, but these are now reinforced by education and the workplace.
Likewise, skills are generally not mutually exclusive: the more mental models you have, the smarter you think. For example, there are some areas of UX which are relevant to API design. In fact, there are similarities between almost everything in life.
Seeing Google try different shades of blue automatically, just goes to show that they don't know what they are doing
"To build a great UX, one has to step back and think about what’s most important, try to come up with the most simple and shortest path to get there, build, analyze what works and why(not), measure, test, rinse, and repeat."
This is very important. But get this: measuring and refining won't fix big errors.
So work with a designer and don't BS him trying to do "live genetic programming" your site with your A/B tool.
"To build a great UX, one has to step back and think about what’s most important, try to come up with the most simple and shortest path to get there, build, analyze what works and why(not), measure, test, rinse, and repeat."
This is true, but in my experience, the best UX people are even more excellent at figuring out what is NOT important and getting rid of it (or not investing any time in those things at all).
Also, just as the "learn to program" meme does not, and can not, apply to everyone, "be a UX person" does not apply to everyone. A significant part of what makes great UX comes from the right-brain and some of us simply are physiologically weaker there.
When I shifted my customer focus from developers to consumers in 1999, after 10+ years of building products, I made a conscious decision to become a "UX guy". I spent YEARS working on that skillset. I even had some pretty strong successes.
But I still suck, compared to my UX idols. I like to think I know good UX when I see it, and I can guide others to do it, but when I'm on my own I struggle.
This is true, but in my experience, the best UX people are even more excellent at figuring out what is NOT important and getting rid of it (or not investing any time in those things at all).
I believe that's what the OP implied when he stated most simple and shortest path to get there, simplifying the UX/UI is based on deduction, archetype development and enough experience/knowledge to start off with a barebones wireframe instead of a bloated mess. Loosely basing the method of delivering an effective UX on Occam's Razor, a philosophy that states if you base your decision on the path with the fewest assumptions and thereby offers the simplest explanation of the effect, that's usually the best route to take.
The most simple path is one that only relies on what's important to your goals and skips all the bloated "data" and "ideas" that would hurt the UX.
To me it is the sad state of "design" in the valley that means "ux people are figuring out what is not important." To label them and give them a role implies that others in the org should not be thinking about this at all times.
everyone should be aligned, everyone should be focused on the audience they are building for and the needs of those users. that is what differentiates a stripe from a google checkout and, to be cliche, an iphone from a treo.
even the concept of having a "ux guy" means there are others in the org who are "not ux guys"
there is nobody at most of the companies who model "good ux" responsible for that "good ux"
I think there's another factor. Even if you have talent for both programming and UX, it's hard for the same person to do both those things well on the same project. To program well you have to know the implementation inside-out. But to do UX well you need to see the places where implementation complexity is leaking through and confusing users. For that, it's helpful not to know too much about how the sausage is made (not sausage in general, but this particular sausage). Once you are habituated to the internals, many details will feel natural and obvious to you that are anything but natural and obvious to users.
The best thing, of course, is to have the program's internal model and the user's mental model be the same. Eliminate contradictions rather than hiding them with complex mappings. ("Design is how it works".) But even then, there will always be much complexity that the user should not have to know about.
"to step back and think about what’s most important, try to come up with the most simple and shortest path to get there, build, analyze what works and why(not), measure, test, rinse, and repeat"
This is more than just UX - you're talking about product design, usability testing, reviewing quantitative data, then reworking features & design (UX/UI + dev) - the whole thing.
Sounds like you're saying that the UX principle of, "being really persistent in iterating and discovering what works" is essential to product - yea, agreed - that's called working towards product market fit. That kind of analysis and iteration is definitely good but not a novel idea.
Also, a suggested revision to title: "Don't look for a UX person, be a UX person." There are women on here too, thanks.
I find it slightly odd when developers resist caring about UX stuff, because in lots of ways we're already doing it whenever we code. When coding we worry about how to communicate the code's behaviour well, and whether it will work intuitive for other devs. In UX's and in code we strive to build a shared, useful and elegant mental model of the world. An API is just a UX for devs.
Apart from that, the ultimate purpose of our code is to serve the people in the world. Well, kind of, often it's just for fun. But generally the aim is to have a user using something; to exist as an entity in their lives and minds. Surely this means studying the user doing their using is just inherently fascinating? (If a dev codes in a forest, and no-one is around to use it ...)
I'm all for specialist UX folk, if resources can accommodate, they've put the time into their discipline, and will obviously do a better job than those who haven't. But when resources don't stretch, developers' brains won't explode if they start thinking about UIs and UXs. There's enough transferable skills there (methodical approach based on evidence, iterations, model building, communication), that I think it's something a lot of devs could get passably good at and enjoy without diverting too much energy away from their principle specialisation. In fact I've found that my experiences with UX stuff has improved my dev work.
After seeing yesterday's Show HN post on Habit List, http://news.ycombinator.com/item?id=3998894, this post really hits home. I have a similar app in the store and their UI/UX is just at a higher level than mine. It's so much easier to focus on the implementation details and not give the UI/UX the attention it deserves. Especially when you're much more confident in your programming knowledge than your design knowledge.
"To build a great A, one has to step back and think about what’s most important, try to come up with the most simple and shortest path to get there, build, analyze what works and why(not), measure, test, rinse, and repeat. Sounds a lot like B doesn’t it?"
Sounds a lot like anything you can iteratively improve. Could also be applied to marketing, cold-call-sales, making a great coffee, ...
Just as importantly, if you're a UX guy, you'll have a much harder time honing your skills and convincing others that your solution is right without some basic graphic design and coding skills, at least enough for prototyping.
So, let me quote a bit of this submission, add some facts, and then take this to its logical conclusion.
>The current meme going around Silicon Valley and startup land is that any founder needs to be a technical founder and be able to program. Don’t look for a technical co-founder, be a technical co-founder. Even more, every employee at an internet startup needs to be able to program...For those who are all-in on these ideas, I would like to raise the bar and say: don’t look for a UX co-founder, be a UX co-founder. Don’t look for a UX guy, be a UX guy.
So much for the quote, and the amount the author wants to raise the bar by. Fair enough.
So, why not raise the bar to the top: single founder, no employees.
Let's say there is no aspect of founding your business that you can't get down to 30 hours per week by that role. If you are ready to commit up to 120 hours in an exceptional week (7 hours of sleep every day, but otherwise get up and work), in what way should you not be ready to fill up to four cofounders' roles?
Raise the bar? Why not do it all?
Here is one recipe.
Role 1: (30 hours) Tuesday, Thursday, Friday, 8-6. This is business development, including networking, scoping out employees, liaising, negotiating terms, finding a scalable business model, doing market and product research, finding competitors and seeing what features they have, talking to users. While the company is very small, you also do customer service. You don't necessarily have to have business experience, but you should have been involved in a small company that expanded greatly or closed a round while you were on board.
Role 2: (30 hours) This is pure uninterrupted coding, Monday, Saturday, and Sunday, 8-6. You should be a full-stack developer well-versed in databases, cloud services (e.g. amazon), front-end and back-end languages, version control, etc. Role out the features that you yourself scope out above and below (role 1 and role 3), or from actual mockups in photoshop that you design Wednesdays or occasionally (see role 3) tweaked betwen 7-11PM the night before. Liaise with talent that business development (you on Tuesdays, Thursays, and Fridays) throws your way. Work from mockups you yourself create (Wednesdays and some late evenings). Of course, you have 10 years worth of coding experience and are an expert in Git, Python, PHP, Javascript, databases, etc, and hopefully a couple of fully coded Android and iOS apps that you have done by yourself.
Role 3: UX and UI. Wednesday, all-day. (Meaning 7-7, though this is creative work and does not have constrained output, can include showing work to others, etc). This includes a break, thinking deeply about what you're really doing, looking at other web sites, and then laying out in photoshop the UX and UI that you will be coding up during the rest of the week. You are, of course, an expert in photoshop and all aspects of UX and UI design and should have a professional-quality portfolio that extends from logos currently being seen by hundreds of millions of people to animations and Cannes-festival shorts, though this can be a relatively short stint in your career due to the low amount of money that you were making. However, you should be confident in your portfolio, and be very quick and competent in Photoshop so that you can execute your vision as a visual 'spec' to code from later. Besides the 12-15 hours (loose, it does involve creative work) that Wednesday comprises, every day between 7 PM and 11 PM you should be prepared to add to this creative output, which adds another up to 18 hours. Your entertainment in these evenings should also be creative and related to your output. Whether that means watching documentories on art, or reading such books, the point is that this is 'fun' for you and your lifestyle in the evenings is somehow related to UI/UX and the types of questions that come with it.
Role 4: This is the most flexible role: it consists of counting money. The accounting role should be able to performed quickly from 11 PM to midnight every day when you don't have much money coming in (7 hours in a week), and extend up to 2:30 AM or 3-3:15 AM every day - another 17.5 to 23 hours - when you do. This extends into the hardest and most awake and alert "all-nighter" period that a coder may think is best reserved for coding. Not so. To truly grow on sales, you should devote your greatest attention with the most quiet and fewest distractions to the bedrock of your business, which is counting money. You should be very at ease with numbers, have a deep understanding of accounting, to the point of nearly having a degree in the matter, and should definitely have handled all aspects of a business's books in the past (short of being an in-house accountant). This is where having run your own business, any business, by yourself, including being a freelancer who had to invoice themselves, will truly help you. However, when there aren't many accounts and there isn't much money coming in nor accounts payable, nor a current round underway or end of the month or quarter there may not be much to do here. Get some rest.
Role 5: (And you thought I could only fit 4 roles in here!) In the morning before 7 or 8, other than Wednesdays, when you're focusing on design from first thing in the mroning, you can answer various quick emails, including non-actionable customer emails, review any news or feeds - like hackernews, have breakfast and generally start your day. Ideally, on normal days you sleep from midnight to seven, and do various quick things like this from 7 to 8, when you start your role of the day. You should be sociable and love getting a bit of time every morning to do this stuff! It hardly feels like a role, just something to break up the chore of boring stuff that you do all day every day.
Why not. Anyone who meets the criteria of the roles above should be able to get a business off the ground as a sole founder and get a very far way along as a sole employee.
As the business expands, you can get help with the accounting (to get more sleep), then help with the programming - especially after all the initial architecutre is set up and major features have been planned and begun to be roled out - a very professional designer just as you yourself are, and finally you will be left to meet with VC's all day to sell the company that you built up all by yourself.
It is, after all, the logical conclusion to the present submission :) Note: I have only proved the above possible, not tried it myself...
Ummm... No, no thanks. We're not all UI designers. We just hired a UX guys because I, as a systems engineer, am more valuable creating hardware interfaces than user interfaces. You still need guys like me making things work behind the scenes and that's where my time is best spent.
[+] [-] ericclemmons|14 years ago|reply
"To build a great UX, one has to step back and think about what’s most important, try to come up with the most simple and shortest path to get there, build, analyze what works and why(not), measure, test, rinse, and repeat."
This is the "left-brained" part of UX, while there is the forgotten "right-brained" portion, which is typically based on the psychological impact of copy, typography, and visual polish.
For example, I worked for a company that wanted to remove all "distracting copy" from the form page so that the submit button was above the fold (and fewer distractions, etc.). We ran multivariate tests swapping copy, removing copy, rephrasing copy, you name it, to figure out what our visitors were actually responding to.
Our original "assurance copy" (letting the user know what the information is for, what's going to happen next, etc.) more than doubled our average time-on-page metric. However, our conversion took a ~27% drop when we removed it entirely, and incrementally better the more copy we had.
The users that did convert spent half the amount of time on the page (they were already committed to purchase by that point), but the rest of the users obviously needed assurance in the process, not necessarily the cheapest process.
[+] [-] peetahb|14 years ago|reply
What you're referring to is the UI, the aesthetic design, layout and features that lends itself to an effective UX. They work hand-in-hand; like the OP had stated (paraphrasing), coming up with the simplest and shortest path to your goals that works, is important for the UX, and knowing your goals and how you want to reach them will help guide the UI.
It's tough to find someone who can focus on UX or to find someone who can translate the UX to a great UI. But it's the toughest to find someone who can do both. It's even harder to become that person.
[+] [-] zavulon|14 years ago|reply
I couldn't disagree more. I have never met anybody who can program AND do UX well. Maybe there are very very rare exceptions, but these two skills are pretty much mutually exclusive.
First of all, you need completely different modes of thinking while coding and while doing UX. Left/right brain, and all that. But more importantly, to be a good UX person, you need tons of training - design, marketing and psychology being three main areas. To be a great programmer, you need completely different set of training. Both UX and programming require single-minded attention, dedication and years to master.
To expect someone to do both of those things well is not only unrealistic, but plain WRONG.
[+] [-] gmurphy|14 years ago|reply
No-one bats an eye when an engineer also turns out to be a fantastic musician, or when an engineer drives great product decisions, yet somehow being able to code and understand design is an impossibility?
We're here to build great things - code and design are mutually-beneficial skills in your toolbox; your brain is not zero-sum.
[+] [-] x1|14 years ago|reply
Does our position really require years to master? Is a java or ruby programmer with 10 years experience that much better than a java or ruby programmer with 3 years experience?
What about design? Is building a website, interactive component or application so complex that only those with decades of experience can really 'get it'? Is someone who has twenty years of UX experience, dating back to the days of VB and Access applications, that much better than someone with five years?
I believe combining technical with creative is something that must be taken as a given with our industry.
[+] [-] feverishaaron|14 years ago|reply
[+] [-] atacrawl|14 years ago|reply
[+] [-] AJ007|14 years ago|reply
I think in the educational system, as children and young adults we are taught that we must excel at as much as we possibly can. When, the reality is, doing really well in one area means your skills in another will weaken -- especially when you are trying to do them at the same time.
Ever met an accountant novel writer who base jumps on the weekends? I haven't.
[+] [-] lhnz|14 years ago|reply
Likewise, skills are generally not mutually exclusive: the more mental models you have, the smarter you think. For example, there are some areas of UX which are relevant to API design. In fact, there are similarities between almost everything in life.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] raverbashing|14 years ago|reply
Seeing Google try different shades of blue automatically, just goes to show that they don't know what they are doing
"To build a great UX, one has to step back and think about what’s most important, try to come up with the most simple and shortest path to get there, build, analyze what works and why(not), measure, test, rinse, and repeat."
This is very important. But get this: measuring and refining won't fix big errors.
So work with a designer and don't BS him trying to do "live genetic programming" your site with your A/B tool.
[+] [-] badclient|14 years ago|reply
Why does that show that "they don't know what they are doing"?
[+] [-] cek|14 years ago|reply
This is true, but in my experience, the best UX people are even more excellent at figuring out what is NOT important and getting rid of it (or not investing any time in those things at all).
Also, just as the "learn to program" meme does not, and can not, apply to everyone, "be a UX person" does not apply to everyone. A significant part of what makes great UX comes from the right-brain and some of us simply are physiologically weaker there.
When I shifted my customer focus from developers to consumers in 1999, after 10+ years of building products, I made a conscious decision to become a "UX guy". I spent YEARS working on that skillset. I even had some pretty strong successes.
But I still suck, compared to my UX idols. I like to think I know good UX when I see it, and I can guide others to do it, but when I'm on my own I struggle.
[+] [-] peetahb|14 years ago|reply
I believe that's what the OP implied when he stated most simple and shortest path to get there, simplifying the UX/UI is based on deduction, archetype development and enough experience/knowledge to start off with a barebones wireframe instead of a bloated mess. Loosely basing the method of delivering an effective UX on Occam's Razor, a philosophy that states if you base your decision on the path with the fewest assumptions and thereby offers the simplest explanation of the effect, that's usually the best route to take.
The most simple path is one that only relies on what's important to your goals and skips all the bloated "data" and "ideas" that would hurt the UX.
[+] [-] octavecat|14 years ago|reply
everyone should be aligned, everyone should be focused on the audience they are building for and the needs of those users. that is what differentiates a stripe from a google checkout and, to be cliche, an iphone from a treo.
even the concept of having a "ux guy" means there are others in the org who are "not ux guys"
there is nobody at most of the companies who model "good ux" responsible for that "good ux"
[+] [-] gruseom|14 years ago|reply
The best thing, of course, is to have the program's internal model and the user's mental model be the same. Eliminate contradictions rather than hiding them with complex mappings. ("Design is how it works".) But even then, there will always be much complexity that the user should not have to know about.
[+] [-] ravejk|14 years ago|reply
This is more than just UX - you're talking about product design, usability testing, reviewing quantitative data, then reworking features & design (UX/UI + dev) - the whole thing.
Sounds like you're saying that the UX principle of, "being really persistent in iterating and discovering what works" is essential to product - yea, agreed - that's called working towards product market fit. That kind of analysis and iteration is definitely good but not a novel idea.
Also, a suggested revision to title: "Don't look for a UX person, be a UX person." There are women on here too, thanks.
[+] [-] emgreen|14 years ago|reply
Apart from that, the ultimate purpose of our code is to serve the people in the world. Well, kind of, often it's just for fun. But generally the aim is to have a user using something; to exist as an entity in their lives and minds. Surely this means studying the user doing their using is just inherently fascinating? (If a dev codes in a forest, and no-one is around to use it ...)
I'm all for specialist UX folk, if resources can accommodate, they've put the time into their discipline, and will obviously do a better job than those who haven't. But when resources don't stretch, developers' brains won't explode if they start thinking about UIs and UXs. There's enough transferable skills there (methodical approach based on evidence, iterations, model building, communication), that I think it's something a lot of devs could get passably good at and enjoy without diverting too much energy away from their principle specialisation. In fact I've found that my experiences with UX stuff has improved my dev work.
[+] [-] rmb177|14 years ago|reply
[+] [-] maigret|14 years ago|reply
[+] [-] CookWithMe|14 years ago|reply
Sounds a lot like anything you can iteratively improve. Could also be applied to marketing, cold-call-sales, making a great coffee, ...
[+] [-] WiseWeasel|14 years ago|reply
[+] [-] its_so_on|14 years ago|reply
>The current meme going around Silicon Valley and startup land is that any founder needs to be a technical founder and be able to program. Don’t look for a technical co-founder, be a technical co-founder. Even more, every employee at an internet startup needs to be able to program...For those who are all-in on these ideas, I would like to raise the bar and say: don’t look for a UX co-founder, be a UX co-founder. Don’t look for a UX guy, be a UX guy.
So much for the quote, and the amount the author wants to raise the bar by. Fair enough.
But why not raise the bar to the top?
Instagram had 13 employees when it sold for a cool billion. (Thanks, Gabriel Weinberg. http://www.gabrielweinberg.om/blog/2012/04/how-many-employee...)
So, why not raise the bar to the top: single founder, no employees.
Let's say there is no aspect of founding your business that you can't get down to 30 hours per week by that role. If you are ready to commit up to 120 hours in an exceptional week (7 hours of sleep every day, but otherwise get up and work), in what way should you not be ready to fill up to four cofounders' roles?
Raise the bar? Why not do it all?
Here is one recipe.
Role 1: (30 hours) Tuesday, Thursday, Friday, 8-6. This is business development, including networking, scoping out employees, liaising, negotiating terms, finding a scalable business model, doing market and product research, finding competitors and seeing what features they have, talking to users. While the company is very small, you also do customer service. You don't necessarily have to have business experience, but you should have been involved in a small company that expanded greatly or closed a round while you were on board.
Role 2: (30 hours) This is pure uninterrupted coding, Monday, Saturday, and Sunday, 8-6. You should be a full-stack developer well-versed in databases, cloud services (e.g. amazon), front-end and back-end languages, version control, etc. Role out the features that you yourself scope out above and below (role 1 and role 3), or from actual mockups in photoshop that you design Wednesdays or occasionally (see role 3) tweaked betwen 7-11PM the night before. Liaise with talent that business development (you on Tuesdays, Thursays, and Fridays) throws your way. Work from mockups you yourself create (Wednesdays and some late evenings). Of course, you have 10 years worth of coding experience and are an expert in Git, Python, PHP, Javascript, databases, etc, and hopefully a couple of fully coded Android and iOS apps that you have done by yourself.
Role 3: UX and UI. Wednesday, all-day. (Meaning 7-7, though this is creative work and does not have constrained output, can include showing work to others, etc). This includes a break, thinking deeply about what you're really doing, looking at other web sites, and then laying out in photoshop the UX and UI that you will be coding up during the rest of the week. You are, of course, an expert in photoshop and all aspects of UX and UI design and should have a professional-quality portfolio that extends from logos currently being seen by hundreds of millions of people to animations and Cannes-festival shorts, though this can be a relatively short stint in your career due to the low amount of money that you were making. However, you should be confident in your portfolio, and be very quick and competent in Photoshop so that you can execute your vision as a visual 'spec' to code from later. Besides the 12-15 hours (loose, it does involve creative work) that Wednesday comprises, every day between 7 PM and 11 PM you should be prepared to add to this creative output, which adds another up to 18 hours. Your entertainment in these evenings should also be creative and related to your output. Whether that means watching documentories on art, or reading such books, the point is that this is 'fun' for you and your lifestyle in the evenings is somehow related to UI/UX and the types of questions that come with it.
Role 4: This is the most flexible role: it consists of counting money. The accounting role should be able to performed quickly from 11 PM to midnight every day when you don't have much money coming in (7 hours in a week), and extend up to 2:30 AM or 3-3:15 AM every day - another 17.5 to 23 hours - when you do. This extends into the hardest and most awake and alert "all-nighter" period that a coder may think is best reserved for coding. Not so. To truly grow on sales, you should devote your greatest attention with the most quiet and fewest distractions to the bedrock of your business, which is counting money. You should be very at ease with numbers, have a deep understanding of accounting, to the point of nearly having a degree in the matter, and should definitely have handled all aspects of a business's books in the past (short of being an in-house accountant). This is where having run your own business, any business, by yourself, including being a freelancer who had to invoice themselves, will truly help you. However, when there aren't many accounts and there isn't much money coming in nor accounts payable, nor a current round underway or end of the month or quarter there may not be much to do here. Get some rest.
Role 5: (And you thought I could only fit 4 roles in here!) In the morning before 7 or 8, other than Wednesdays, when you're focusing on design from first thing in the mroning, you can answer various quick emails, including non-actionable customer emails, review any news or feeds - like hackernews, have breakfast and generally start your day. Ideally, on normal days you sleep from midnight to seven, and do various quick things like this from 7 to 8, when you start your role of the day. You should be sociable and love getting a bit of time every morning to do this stuff! It hardly feels like a role, just something to break up the chore of boring stuff that you do all day every day.
Why not. Anyone who meets the criteria of the roles above should be able to get a business off the ground as a sole founder and get a very far way along as a sole employee.
As the business expands, you can get help with the accounting (to get more sleep), then help with the programming - especially after all the initial architecutre is set up and major features have been planned and begun to be roled out - a very professional designer just as you yourself are, and finally you will be left to meet with VC's all day to sell the company that you built up all by yourself.
It is, after all, the logical conclusion to the present submission :) Note: I have only proved the above possible, not tried it myself...
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] _feda_|14 years ago|reply
[+] [-] eswangren|14 years ago|reply