11 ms·

Why most mobile development projects fail

154 points by bontoJR 10y ago

mooreds 10y ago
Really great explication of the collapsing of responsibilities of mobile development. Remedies, as always, involve educating the client. Makes sense to me.
throwanem 10y ago
Photoshop-driven development is still a common practice in the mobile space? That's horrifying.
- bontoJR 10y ago
  Well, to be honest, in the last year a lot of designers have moved to Sketch or similar alternatives, but it's still very common to work with plain screens as start point when working as contractor.
  - dejv 10y ago
    Sketch-driven development is not that much better. It is easier to get from design to app, but then edge cases and real data start to interfere with vision and you are doomed anyway.
- pjmlp 10y ago
  It is a common practice almost everywhere I work. When Photoshop is too expensive, we get Powerpoint-driven development instead.
  - sokoloff 10y ago
    While Photoshop is a terrible starting point, if it gets avoided primarily for cost reasons, run away anyway.
    - 1_player 10y ago
      It's not a cost reason, most likely it's management doing the mockups. Powerpoint it's all they know.
      - sokoloff 10y ago
        That might not be so terrible. GP was suggesting it was due to cost, which is a "run away like the building was on fire" signal, IMO. If all management knows is powerpoint, that's what they should use to communicate their ideas. It's no different than if all they knew was a napkin and pencil sketch.
        pjmlp 10y ago
        I is due to cost. I am aware of a few projects that were done with trial versions of the software stack, almost all the way up to a few months before delivery date.
pavel_lishin 10y ago
> In a web app, you’re either the frontend or backend developer. In a mobile app, you’re the app developer. Maybe if you're part of a bigger team. But if you're working on an app of the same scale as this hypothetical mobile app - where you have a single client who has a designer - you're pretty likely to be doing all of the front-end stuff as well.
- wvenable 10y ago
  Yeah, this article reminded me exactly of what it was like to do smaller scale web development. When I got to that exact line in the article, I had the same thought as you. There really isn't much of a distinction. I think if you're on any project that has a 3rd party photoshop designer it's going to go just like this whether it's mobile, web, or even desktop.
WoodenChair 10y ago
Mobile MVPs done by lone developers on a contract basis should be about getting something palatable and pleasant that works, not drop shadows and exacting transparency effects. Save that for a second version or when you have enough of a budget to get a designer that knows her way around interface builder. Getting too caught up in making a MVP pixel perfect is a cause of failure for both client and developer.
- 20years 10y ago
  This was my thought too. A lot of the times I suggest doing a hybrid app for the MVP. It is an easier and more affordable way of getting a functional and decent looking app to market. Allows the client to test and fine tune more easily. Oftentimes after launch they stick with the hybrid app because it gives them enough of what they need. Other times they decide to proceed to native but now have a much better idea on what they really need/want and saved tons of money in the process.
- jbish 10y ago
  Are there many designers that know their way around Interface Builder?
  - CookieCats 10y ago
    I always felt that Interface Builder is _for_ designers who want to visualize and use something (only somewhat) closer to photoshop. A developer might more likely come at it from the other direction, not even touching IB and doing it all in code, then maybe adding modular IB elements when the layouts start to make the code unmanageable.
    - jbish 10y ago
      Interesting. I've worked with a few designers who had Xcode _installed_, but they were mostly using it for the Simulator. Using IB wasn't something they were comfortable with. I'd be really impressed with somebody who's a Sketch/Photoshop wiz coming over to IB and being productive. On the flip side why would a non-developer bother to install Xcode and learn IB when they can export their ideas directly from Sketch/Photoshop into clickable "prototypes"?
deleted 10y ago
[deleted]
rdoherty 10y ago
The first half of the post applies to web development too. Most designers design for the 'best case' scenario and leave out all the tiny details like error conditions, interactions, too much/little content, various screen sizes and touch vs mouse interactions (hover especially). Let's face it, nowadays unless you are designing a content site there is an immense amount of work needed to handle all the complexities of designing a web or mobile app. This is why things like Bootstrap or other frameworks are so popular, they allow a designer or developer to cover 90% of those scenarios and focus on the important things.
- bontoJR 10y ago
  > This is why things like Bootstrap or other frameworks are so popular, they allow a designer or developer to cover 90% of those scenarios and focus on the important things. You're definitely right, but this IMO this is a broken model. Most of the times superior web apps and mobile apps are the ones with extremely well curated UX, maybe even featuring a slim UI. OFC is the product is very revolutionary, you can be still successful with trade-offs in UI/UX, but the second one is far more important than the first one, if you have a shining, super cool bootstrap template, but a horrifying UX, people will definitely walk away and never return. If you have a decent UI, but an outstanding UX, they will stay and give you suggestions (implicit and explicits) in how to improve the UI as well.
  - throwanem 10y ago
    That doesn't impugn the model. Using Bootstrap to cover the 90% case, rather than building from scratch, lets you spend more time and effort on solid UX, rather than having to reinvent basic UI from the ground up.
pavlov 10y ago
The problem is the waterfall approach of client->designer->developer. If the first line of code is written after there's a supposedly "finished" Photoshop or Sketch document, the project is doomed to run into all the fundamental design issues explained in this post. Yet often that seems like the only way to the client, who thinks that they can't afford a programmer in the "planning" or "design" phase... Even though it leads to an unpredictable budget explosion in the latter stages. One solution is to have better tools for app design. Instead of PSDs and handwaving static Invision clickthroughs, there should be a tool that allows an app prototype to be modelled using real code and native mobile concepts like navigation controllers and list views. I've worked on such a tool, Neonto: http://neonto.com http://neonto.com It's not perfect (the code generation can never match a veteran programmer's style), but for prototypes often good enough - and much more powerful than clickthroughs. Btw, Neonto is considering switching to React Native for the generated projects. If someone's interested in that, give a shout to hello@neonto.com and voice your opinion!
- polishninja 10y ago
  I thought that Neonto looked like a good prototype tool. Downloaded it and unfortunately, it's Mac only.
- kpil 10y ago
  I came here to say that. I read this as an advertisment for agile development... It's a false savings to involve developers late, even if you have 'the competence' in the project already. I would suggest using a story mapping technique. (Jeff Patton) But if the stakeholders are clueless, you get into the game too late as a developer.
jbob2000 10y ago
Part of me wants to grab these clients and shake them while yelling "You are a software company, why are you farming out your core competency!?!?" These problems arise because the client thinks that the software portion of their business is just a tiny part of the picture. If the only thing your clients use to do business with you is your mobile app, then you are a software company. Full stop. Why the hell did they hire a designer? They need a product manager. And why are they building the entire solution in one shot? Build it in small pieces and iterate.
jrochkind1 10y ago
I think PSD-driven development is inherently broken, and this post explains some of the reasons why. It's not really unique to mobile, I've experienced similar on web apps that attempt to be "drop a PSD, now implement this", although maybe the problems are worse in mobile. I don't really know what the better alternative is, that will meet the social/business/workflow needs that are the reason PSD-driven development happens. Except that it will involve some attempt to find a way to be more 'agile', as compared to the implied waterfall model in "we give you a PSD and you implement it." Ideally, I don't think they'd be giving you "it should look just like this" PSD's at all. They should be giving you wireframes and appropriate assets as assets. But this will end up being 'more expensive' probably, with more hours spent on back-and-forth and iterations, compared to the waterfall ideal of "here, just do this." Good software is very 'expensive' (in terms of professional developer hours). It's why we live in a world of really crappy software.
- pwthornton 10y ago
  As someone who heads up a user experience team at a decent sized organization, I concur that PSD-driven development and design is dead. If a design isn't in code for people to use and feel, it's not done. It's just a start. A design can start in Photoshop (or Sketch, more likely), but the iterative process of doing high-fidelity prototypes and getting feedback is how good design is done. We are also talking about interaction design here. It's not how it looks, but how it works and feels. That cannot be accurately modeled with a PSD file. Our design process starts with hand-drawn sketches or paper prototyping and goes up from there in fidelity. You cannot work in an Agile environment with PSD-drive development. My team has designers, developers, usability experts and people with a combo of these skills. No one is allowed to work in a silo.
  - meric 10y ago
    We've been moving to high-fidelity prototypes from PSD-design, it's good. The days before we moved to PSD-driven development, it was "We need a page with a list of X's, so the user can Y each. It should look sort of like the list of Z's on ABC.com. Build a prototype for next week"... one week of back and forth and a bunch of hacks later..."Ok, the prototype looks good, let's put this in production by Friday." Bringing in a full time designer and bringing in PSD-driven development was very welcome relief. We still had a week and a Friday, and didn't need to allocate time for prototyping.
joeld42 10y ago
As a mobile dev, this article kind of irritates me. It seems like the author is trying to shift his responsibilities to the client or designer. Here some tips: - wireframe first. At least on a whiteboard. Build the interface with stock or ugly controls from that, iterate the interaction. Only once that is done, send ugly screenshots to the designer to beautify. - I believe that every dev should have photoshop, and know the basics. You shouldn't need a 24 hour turnaround to cut an asset or fix a small issue. - actually talk to the designer. Don't make the client be a middleman. When you feel a screen is done, review it with design first. Try for pixel-perfect accuracy, but don't get too hung up on it, often a five minute chat can suggest alternatives that save hours of work. - always decide what screens will work in landscape, or portrait, or both, up front. This is easy to forget and sometimes difficult to retrofit. - not the only approach but one that works for me, pick one device (screen size) to be the "hero" device for a project, and build for that first, then go back and and adapt for the rest. This works better if its a more constrained device, as adapting to a larger/faster device is easier. I often use a 5c as the target.
- ajeet_dhaliwal 10y ago
  I disagree about every dev needing to have photoshop and knowing the basics - even though I personally have done this in the past i have found it to ultimately be a waste of time - something looks simple enough to change, sometimes you get lucky, it is, other times, 20 minutes later you're looking through photoshop menus/dropdowns. The designer know these tools the best, I'd rather take your third point and talk to the designer and communicate that you need him/her to be available to work through these points. There's so much for a developer to know and be focused on without having to learn to use the designer's tools as well.
  - ThomPete 10y ago
    I think you are looking at this all wrong. Just like the designer would benefit from knowing how code works, don't you think the developer would benefit from knowing how photoshop works? I find it kind of interesting that a developer would even feel a reluctance to understand one of the basic methods used to deliver to them what they need to develop. You are missing out on great opportunity to have an informed opinion, think about alternatives, find potential business ideas from something thats not optimal and in general just have a better and more productive relationship with designers. I at least realized that learning to code as a designer, even just a little bit, both taught me a great deal of how to build things for developers, help them solves problems that might require a different way to think about the technical issue of something and not do stuff that are completely retarded and impossible to do.
sickbeard 10y ago
no.. that's not why they fail. They fail because the client wants the sky but his budget barely touches the ceiling. Eventually the money runs out and the thing falls flat on its face.
deleted 10y ago
[deleted]
fsloth 10y ago
PSD driven development is still a thing? Ugh. What tools are out there to build the UI scenegraph directly from production assets? (there is Rightware for automotive displays)
feverishaaron 10y ago
Or just ask your designer to work @1x in a vector app like Sketch, and export PDF vector images for import into the asset catalog (Scale Factor - Vector Asset). http://useyourloaf.com/blog/creating-scaled-images-with-pdf-vectors/ http://useyourloaf.com/blog/creating-scaled-images-with-pdf-... -- A designer
beyti 10y ago
Replacing "Photoshop" with "Design Resources", really slim and useful article I think. Especially agreed to the "design + dev + dev-ops" responsibilities are mostly neglected by the client and should be described within handshake process as described.
mwcampbell 10y ago
The difficulty of converting a Photoshop design to an actual UI reminds me of this passage from Paul Graham's essay "The Power of the Marginal" [1]: > For example, it recently emerged that the famous glass artist Dale Chihuly hasn't actually blown glass for 27 years. He has assistants do the work for him. But one of the most valuable sources of ideas in the visual arts is the resistance of the medium. That's why oil paintings look so different from watercolors. In principle you could make any mark in any medium; in practice the medium steers you. And if you're no longer doing the work yourself, you stop learning from this. In the case of mobile app development, it's probably best to let the constraints and idioms of the platform, which the developer knows best, steer the design. So maybe part of the solution, contrary to what the article suggests, is to further collapse roles; maybe the developer should do the design, too. [1]: http://paulgraham.com/marginal.html http://paulgraham.com/marginal.html
- ageektrapped 10y ago
  Amen. I couldn't agree more with this. A lot of comments in the thread are commenting that the developer should be able to slice up PSDs, but why not go further and be responsible for the design and interaction. It requires empathy for the user and, let's say 100 hours spent on understanding fonts, colour and layout. The constraints of the platform should absolutely guide the design. Fight those constraints and the app will feel weird on the platform. Most designers won't know the constraints of the platform, or won't care; they want to make a design that's unique and beautiful and all that. The client (or any human being) will look at the pretty pictures and love it. The eventual user of the software _won't care at all_. Designers make pretty stuff that demos well. Those designs are usually a lot more work to pull off in code, though. In the middle of implementing those designs, all I'm thinking is, "What a waste of money. No user is going to care about this [animation|screen transition|custom look|beautiful settings screen]." This applies to web and mobile and desktop apps. Look at the apps you use everyday. They're probably boring to look at. At the least, if you're in the client position, get a designer and developer together at the same time to hash out the app. You can probably get something that looks decent, works well and costs less.
nbevans 10y ago
Who designs mobile apps by slicing PSD files? Fire the developer who went along with that idea!
halis 10y ago
I don't understand the notion that as a mobile developer you have to do the front end and the backend... I just wrote the back-end for an iOS app, I had nothing to do with the front-end and the sole front-end developer had nothing to do with the back-end. We used a simple Rest API. Where is the problem?
- jasey 10y ago
  I think the author was meaning it more in terms of MVC in the iOS project - Web dev - Backend dev scope: Model, Controler Front end dev scope: views - Mobile dev - Where as with an mobile dev, their scope is model, view and controller code (full stack) Your thinking of it in terms of the whole mobile app being the front end and the rest API being the backend. But the app its self has both "front end" and "backend" code segregation its self
  - rayvinly 10y ago
    Thanks jasey. That's exactly what I meant. But you laid it out for me.
    - robmcm 10y ago
      It is a grey area, all web applications I work on have syncing, caching, local storage and offline support. I can also think of many mobile apps that do not. To assume otherwise is a bit of a generalization.
- megablast 10y ago
  There is more than one backend. The backend might be the server, or it might be the database/models on the device.
Zyst 10y ago
I think it's a bit naive if you think that Web Developers are cleanly split into Frontend and Backend. Most of the developers I know, like myself, are Fullstack. According to the Stack Overflow developer survey[1] there's more Fullstack developers than any other kind of developer. It just bothers me that the implication I got from your article was: "This is why mobile is tougher than Web." You might think: "Alright but web doesn't deal with some stuff mobile does, like offline data sync", but web does deal with stuff that mobile doesn't have to consider, like making sure your application is secure from XSS attacks, making sure all your backend endpoints prevent Overposting attacks, and other security considerations. And if you are freelance, usually web also has to handle devops. Although sometimes the client does have their own setup. Web also deals with considerations you don't in Mobile in general. Web is also very prone to failure if you don't plan carefully. On the other hand the part that mentions that you should break your development into tasks is absolutely spot on. When I take a job I plan how I'm going to do the entire application in my head, writing it down in the process, then and only should do I give an estimate. It might be the single most important practice in my job as a consultant. [1]: http://stackoverflow.com/research/developer-survey-2016 http://stackoverflow.com/research/developer-survey-2016
askyourmother 10y ago
Most fail because clients are lied to. They are shown the high-res print ready Photoshop glossies, and told "yes, you can have this, it will use all these assets. And lots of browser control overriding interactions". Then they try to actually build it, it is slow, uses the whole months bandwidth allowance for the mobile user "my whole 10GB gone? But I only browsed the web..", and will crumble under load. The real problem is letting designers near the web. They were OK on print, well, a lot of printers had problems with the designers as well. Hmm. Maybe it is just the designers.
- TheCoelacanth 10y ago
  The problem is designers only being responsible for the design and not for the end product.
- rayvinly 10y ago
  Thanks for pointing that out. Pretty PSDs are easy sells to the clients by design agencies who are then off the hook.
ThomPete 10y ago
Just like the designer would benefit from knowing how code works, so would a designer benefit from know how a developer works. The biggest issue isn't lack of communication but lack of understanding each other. I find it kind of interesting that a developer would even feel a reluctance to understand one of the basic methods used to deliver to them what they need to develop. You are missing out on great opportunity to have an informed opinion, think about alternatives, find potential business ideas from something thats not optimal and in general just have a better and more productive relationship with designers. I at least realized that learning to code as a designer, even just a little bit, both taught me a great deal of how to build things for developers, help them solves problems that might require a different way to think about the technical issue of something and not do stuff that are completely retarded and impossible to do. And so now none of my projects fail unless I want them to.
overcast 10y ago
In a web app, you’re either the frontend or backend developer. Riiiiiiiiight.
rampage101 10y ago
The client is unable to understand the technical challenges, while the developer cannot read the client's mind. Not a mystery why the project in story failed. I am more familiar with AndroidStudio than iOS programming, and it just feels like a hackish piece of software. It looks like Eclipse, and the code is Java, but it's really a stripped down version of Java with a lot of hacks and work arounds. It seems like so much time is spent negiotating with the operating system.
jordanlev 10y ago
Oh how the grass is always greener on the other side of the fence! As a web developer, I'm used to hearing about how mobile app development is so much better because there's a sane layout system and you don't need to deal with crufty old CSS. And how it's so easy to get native functionality, and the UI is easy to make run at the coveted 60FPS, etc. Nice to be reminded that as lucky as us developers are in the grand scheme of things, we still have hard jobs and changing your tools or platform won't solve all your problems but rather just gives you different problems :)
bshimmin 10y ago
There's a lot that's slightly off about this (though there is also some good material in here too, and clearly it's coming from a place of frustration based on real projects - perhaps, I suspect, without a huge amount of experience of the grass on the other side...), but one bit that particularly struck me was: When a client wants to build a web app, they understand they need to have a good design, build the pretty HTML and CSS, with a server in the backend, and some dev-op to keep the app running. Really? Because I'd be glad to introduce you to many of my clients who absolutely do not understand any of that; in fact I had a conversation with a client just two days ago where I explained, patiently and not for the first time, what it was one of my backend developers actually did on a day-to-day basis, and why that sometimes didn't translate into something visible he could actually click on in his browser. Most of my clients really just want a complete solution (often involving design) and they don't know or care at all about HTML, CSS, AWS, or Postgres.
guelo 10y ago
s/mobile/iphone/ Same issues exist on the other more popular platform but this article is only about the iPhone so the title is wrong.
ex3ndr 10y ago
In our project (actor.im) we successfully separated logic (cross-platform!) and make it work closely with backend team and we cover together all corner cases. Making UI on top of this is very-very easy.
jernfrost 10y ago
Oh man this felt awfully familiar. I am so happy I left iOS consulting work and instead built in house apps so I don't have to deal with stupid customers and designer detached from reality. In retrospect I think they should leave a bit more design decision to developers and let them throw up a minimum design first. A design which works well within the constraints and technologies of the platform. Then designer can come with input on how to change that. It is astonishing how much faster you can build an app if you don't have to care about getting the UI pixel perfect according to some designers pipe dream of what it should look like. Customers should know this, because I don't think they have any idea of how expensive it is to insist on very particular details of how the UI looks. If you give more freedom and choices in how the design should be to the developer you can get an app for a fraction of the price which is easier to maintain.
dasil003 10y ago
> Mobile development = frontend development + backend development + dev-op. Sorry no, being a mobile developer does not mean doing backend and devops any more than being a web developer does. In some cases you might have to do it, and in some cases you might not. But there's nothing inherently easier about the web. Furthermore I find the whining about different iPhone vs iPad layout differences to be quite ignorant of everything except iOS development. There is no more controlled environment than iOS. Try developing for Android some time. And don't get me started on cross-browser, cross-platform responsive web design. The bottom line is no development is easy, it's all a mess everywhere you look. It looks pretty bad when you try to extrapolate the warts from your particular corner of the dev world into an assertion that other developers have it easier. Doing good development work is just plain hard, even when working with equal share stakeholders and with none of the trust and workflow issues associated with clients.
adamconroy 10y ago
Interesting article for me as I just rolled out an app for a client and a lot of this feels familiar. Firstly I was lucky I didn't have a PSD driven design, but my client demanded a fixed price quote, so I insisted they pay me to do fairly comprehensive spec, including a clickable wireframe prototype, bdd behaviour spec, architecture design, background, requirements, objectives.... I went with lo-fi hand drawn pages which I scanned and wired up as a clickable prototype via https://marvelapp.com/ https://marvelapp.com/ In the end it was fairly successful for me, as the comprehensive spec allowed me to estimate fairly accurately. However I don't think it was the most cost effective outcome for the client. Because of their rigid nature, instead of collaborating through the process (aside from the specification phase of course), I built them exactly what we agree and invoiced them and was paid. However, within a week of the first pilot they had come up with about 100 hours worth of changes they wanted. In the end I spent about 100 hours in the spec / design phase (which I was paid by the hour), 300 hours building the app (which was a fixed price) and now I have about 100 hours of changes to make. If we had worked to a budget rather than a fixed price, then by my estimate I would have spent about 400 hours collaborating and iterating (basically removing about 90% of the time creating and writing a spec) and they would have had an app which they were involved in crafting the whole way through. Basically I think they have blown about 100hours and they have to live with lots of little nuances that they would have otherwise been able to decide upon.
fleitz 10y ago
Stop slicing PSDs and start writing code. Coding shit from PSDs is like making a car from a drawing a 3 year old made. It's so fucking stupid that only a 3 year old wouldn't realize it's probably the most retarded way to design an app. If your designer knew how to design apps they wouldn't be making PSDs, just like no car designer would substitute photoshop for clay. The only thing Photoshop is appropriate for designing is static images / webpages.
deleted 10y ago
[deleted]
wiradikusuma 10y ago
I dont understand why you need to slice PSD like it's Web dev in 1999. Does iOS/Android not have something like "Bootstrap"?
megablast 10y ago
Pfft, if his biggest problem is the design, he is sitting pretty. Also the designer should slice up the PSDs, that solves this problem.
kinj28 10y ago
For enterprise mobile apps - we are working to address this problem with our docker like container platform with ready pre-built mobile app with a runtime to run your cross platform hybrid web. feel free to ping and I will be happy to share more details.
madetech 10y ago
If designers could use an interface design tool instead of some photo editing software, then most of the problems go away. Spending time upfront perfecting a piece of art isn't a sensible way to approach design as its all make belief until you've written some code
- bloaf 10y ago
  I feel like I must be on crazy pills for suggesting that the designer's deliverable should be something like UWP XAML documents. I wouldn't necessarily expect them to do any fancy data binding, but they should be able to at least lay things out and maybe manually fill in some dummy data.
phatbyte 10y ago
Most of those design issues could be solved if they used (designer and dev) Sketch or Paintcode
k__ 10y ago
Im so happy that I never ever in my front-end career had to implement some designers PSDs. The only images I got where mocks with stuff I already implemented but needed some changes... On the other hand, I consider myself a software and usability engineer, maybe giving greater focus to nontechnical aspects of software has safed me from having to do what a designer tells me to...
ourcat 10y ago
This is why I'm a "createc". Front to back end. Involved throughout the project process. Gets the job done. Everyone happy. Fully managed (and often exceeded) expectations.
stevetrewick 10y ago
>As you are about to slice the PNGs... You realise that you have failed to communicate your requirements to the client, failed to do due diligence on the requirements and assets before you signed the contract and badly mis-scoped the project based on your imagination of what non domain experts should know about your field of professional endeavour. You are likely to be eaten by a grue.

154 points by bontoJR 10y ago

Really great explication of the collapsing of responsibilities of mobile development. Remedies, as always, involve educating the client. Makes sense to me.

throwanem 10y ago

Photoshop-driven development is still a common practice in the mobile space? That's horrifying.

bontoJR 10y ago
Well, to be honest, in the last year a lot of designers have moved to Sketch or similar alternatives, but it's still very common to work with plain screens as start point when working as contractor.
- dejv 10y ago
  Sketch-driven development is not that much better. It is easier to get from design to app, but then edge cases and real data start to interfere with vision and you are doomed anyway.
pjmlp 10y ago
It is a common practice almost everywhere I work. When Photoshop is too expensive, we get Powerpoint-driven development instead.
- sokoloff 10y ago
  While Photoshop is a terrible starting point, if it gets avoided primarily for cost reasons, run away anyway.
  - 1_player 10y ago
    It's not a cost reason, most likely it's management doing the mockups. Powerpoint it's all they know.
    - sokoloff 10y ago
      That might not be so terrible. GP was suggesting it was due to cost, which is a "run away like the building was on fire" signal, IMO. If all management knows is powerpoint, that's what they should use to communicate their ideas. It's no different than if all they knew was a napkin and pencil sketch.
      - pjmlp 10y ago
        I is due to cost. I am aware of a few projects that were done with trial versions of the software stack, almost all the way up to a few months before delivery date.

pavel_lishin 10y ago

> In a web app, you’re either the frontend or backend developer. In a mobile app, you’re the app developer. Maybe if you're part of a bigger team. But if you're working on an app of the same scale as this hypothetical mobile app - where you have a single client who has a designer - you're pretty likely to be doing all of the front-end stuff as well.

wvenable 10y ago
Yeah, this article reminded me exactly of what it was like to do smaller scale web development. When I got to that exact line in the article, I had the same thought as you. There really isn't much of a distinction. I think if you're on any project that has a 3rd party photoshop designer it's going to go just like this whether it's mobile, web, or even desktop.

WoodenChair 10y ago

Mobile MVPs done by lone developers on a contract basis should be about getting something palatable and pleasant that works, not drop shadows and exacting transparency effects. Save that for a second version or when you have enough of a budget to get a designer that knows her way around interface builder. Getting too caught up in making a MVP pixel perfect is a cause of failure for both client and developer.

20years 10y ago
This was my thought too. A lot of the times I suggest doing a hybrid app for the MVP. It is an easier and more affordable way of getting a functional and decent looking app to market. Allows the client to test and fine tune more easily. Oftentimes after launch they stick with the hybrid app because it gives them enough of what they need. Other times they decide to proceed to native but now have a much better idea on what they really need/want and saved tons of money in the process.
jbish 10y ago
Are there many designers that know their way around Interface Builder?
- CookieCats 10y ago
  I always felt that Interface Builder is _for_ designers who want to visualize and use something (only somewhat) closer to photoshop. A developer might more likely come at it from the other direction, not even touching IB and doing it all in code, then maybe adding modular IB elements when the layouts start to make the code unmanageable.
  - jbish 10y ago
    Interesting. I've worked with a few designers who had Xcode _installed_, but they were mostly using it for the Simulator. Using IB wasn't something they were comfortable with. I'd be really impressed with somebody who's a Sketch/Photoshop wiz coming over to IB and being productive. On the flip side why would a non-developer bother to install Xcode and learn IB when they can export their ideas directly from Sketch/Photoshop into clickable "prototypes"?

deleted 10y ago

[deleted]

rdoherty 10y ago

The first half of the post applies to web development too. Most designers design for the 'best case' scenario and leave out all the tiny details like error conditions, interactions, too much/little content, various screen sizes and touch vs mouse interactions (hover especially). Let's face it, nowadays unless you are designing a content site there is an immense amount of work needed to handle all the complexities of designing a web or mobile app. This is why things like Bootstrap or other frameworks are so popular, they allow a designer or developer to cover 90% of those scenarios and focus on the important things.

bontoJR 10y ago
> This is why things like Bootstrap or other frameworks are so popular, they allow a designer or developer to cover 90% of those scenarios and focus on the important things. You're definitely right, but this IMO this is a broken model. Most of the times superior web apps and mobile apps are the ones with extremely well curated UX, maybe even featuring a slim UI. OFC is the product is very revolutionary, you can be still successful with trade-offs in UI/UX, but the second one is far more important than the first one, if you have a shining, super cool bootstrap template, but a horrifying UX, people will definitely walk away and never return. If you have a decent UI, but an outstanding UX, they will stay and give you suggestions (implicit and explicits) in how to improve the UI as well.
- throwanem 10y ago
  That doesn't impugn the model. Using Bootstrap to cover the 90% case, rather than building from scratch, lets you spend more time and effort on solid UX, rather than having to reinvent basic UI from the ground up.

pavlov 10y ago

The problem is the waterfall approach of client->designer->developer. If the first line of code is written after there's a supposedly "finished" Photoshop or Sketch document, the project is doomed to run into all the fundamental design issues explained in this post. Yet often that seems like the only way to the client, who thinks that they can't afford a programmer in the "planning" or "design" phase... Even though it leads to an unpredictable budget explosion in the latter stages. One solution is to have better tools for app design. Instead of PSDs and handwaving static Invision clickthroughs, there should be a tool that allows an app prototype to be modelled using real code and native mobile concepts like navigation controllers and list views. I've worked on such a tool, Neonto: http://neonto.com http://neonto.com It's not perfect (the code generation can never match a veteran programmer's style), but for prototypes often good enough - and much more powerful than clickthroughs. Btw, Neonto is considering switching to React Native for the generated projects. If someone's interested in that, give a shout to hello@neonto.com and voice your opinion!

polishninja 10y ago
I thought that Neonto looked like a good prototype tool. Downloaded it and unfortunately, it's Mac only.
kpil 10y ago
I came here to say that. I read this as an advertisment for agile development... It's a false savings to involve developers late, even if you have 'the competence' in the project already. I would suggest using a story mapping technique. (Jeff Patton) But if the stakeholders are clueless, you get into the game too late as a developer.

jbob2000 10y ago

Part of me wants to grab these clients and shake them while yelling "You are a software company, why are you farming out your core competency!?!?" These problems arise because the client thinks that the software portion of their business is just a tiny part of the picture. If the only thing your clients use to do business with you is your mobile app, then you are a software company. Full stop. Why the hell did they hire a designer? They need a product manager. And why are they building the entire solution in one shot? Build it in small pieces and iterate.

jrochkind1 10y ago

I think PSD-driven development is inherently broken, and this post explains some of the reasons why. It's not really unique to mobile, I've experienced similar on web apps that attempt to be "drop a PSD, now implement this", although maybe the problems are worse in mobile. I don't really know what the better alternative is, that will meet the social/business/workflow needs that are the reason PSD-driven development happens. Except that it will involve some attempt to find a way to be more 'agile', as compared to the implied waterfall model in "we give you a PSD and you implement it." Ideally, I don't think they'd be giving you "it should look just like this" PSD's at all. They should be giving you wireframes and appropriate assets as assets. But this will end up being 'more expensive' probably, with more hours spent on back-and-forth and iterations, compared to the waterfall ideal of "here, just do this." Good software is very 'expensive' (in terms of professional developer hours). It's why we live in a world of really crappy software.

pwthornton 10y ago
As someone who heads up a user experience team at a decent sized organization, I concur that PSD-driven development and design is dead. If a design isn't in code for people to use and feel, it's not done. It's just a start. A design can start in Photoshop (or Sketch, more likely), but the iterative process of doing high-fidelity prototypes and getting feedback is how good design is done. We are also talking about interaction design here. It's not how it looks, but how it works and feels. That cannot be accurately modeled with a PSD file. Our design process starts with hand-drawn sketches or paper prototyping and goes up from there in fidelity. You cannot work in an Agile environment with PSD-drive development. My team has designers, developers, usability experts and people with a combo of these skills. No one is allowed to work in a silo.
- meric 10y ago
  We've been moving to high-fidelity prototypes from PSD-design, it's good. The days before we moved to PSD-driven development, it was "We need a page with a list of X's, so the user can Y each. It should look sort of like the list of Z's on ABC.com. Build a prototype for next week"... one week of back and forth and a bunch of hacks later..."Ok, the prototype looks good, let's put this in production by Friday." Bringing in a full time designer and bringing in PSD-driven development was very welcome relief. We still had a week and a Friday, and didn't need to allocate time for prototyping.

joeld42 10y ago

As a mobile dev, this article kind of irritates me. It seems like the author is trying to shift his responsibilities to the client or designer. Here some tips: - wireframe first. At least on a whiteboard. Build the interface with stock or ugly controls from that, iterate the interaction. Only once that is done, send ugly screenshots to the designer to beautify. - I believe that every dev should have photoshop, and know the basics. You shouldn't need a 24 hour turnaround to cut an asset or fix a small issue. - actually talk to the designer. Don't make the client be a middleman. When you feel a screen is done, review it with design first. Try for pixel-perfect accuracy, but don't get too hung up on it, often a five minute chat can suggest alternatives that save hours of work. - always decide what screens will work in landscape, or portrait, or both, up front. This is easy to forget and sometimes difficult to retrofit. - not the only approach but one that works for me, pick one device (screen size) to be the "hero" device for a project, and build for that first, then go back and and adapt for the rest. This works better if its a more constrained device, as adapting to a larger/faster device is easier. I often use a 5c as the target.

ajeet_dhaliwal 10y ago
I disagree about every dev needing to have photoshop and knowing the basics - even though I personally have done this in the past i have found it to ultimately be a waste of time - something looks simple enough to change, sometimes you get lucky, it is, other times, 20 minutes later you're looking through photoshop menus/dropdowns. The designer know these tools the best, I'd rather take your third point and talk to the designer and communicate that you need him/her to be available to work through these points. There's so much for a developer to know and be focused on without having to learn to use the designer's tools as well.
- ThomPete 10y ago
  I think you are looking at this all wrong. Just like the designer would benefit from knowing how code works, don't you think the developer would benefit from knowing how photoshop works? I find it kind of interesting that a developer would even feel a reluctance to understand one of the basic methods used to deliver to them what they need to develop. You are missing out on great opportunity to have an informed opinion, think about alternatives, find potential business ideas from something thats not optimal and in general just have a better and more productive relationship with designers. I at least realized that learning to code as a designer, even just a little bit, both taught me a great deal of how to build things for developers, help them solves problems that might require a different way to think about the technical issue of something and not do stuff that are completely retarded and impossible to do.

sickbeard 10y ago

no.. that's not why they fail. They fail because the client wants the sky but his budget barely touches the ceiling. Eventually the money runs out and the thing falls flat on its face.

deleted 10y ago

[deleted]

fsloth 10y ago

PSD driven development is still a thing? Ugh. What tools are out there to build the UI scenegraph directly from production assets? (there is Rightware for automotive displays)

feverishaaron 10y ago

Or just ask your designer to work @1x in a vector app like Sketch, and export PDF vector images for import into the asset catalog (Scale Factor - Vector Asset). http://useyourloaf.com/blog/creating-scaled-images-with-pdf-vectors/ http://useyourloaf.com/blog/creating-scaled-images-with-pdf-... -- A designer

beyti 10y ago

Replacing "Photoshop" with "Design Resources", really slim and useful article I think. Especially agreed to the "design + dev + dev-ops" responsibilities are mostly neglected by the client and should be described within handshake process as described.

mwcampbell 10y ago

The difficulty of converting a Photoshop design to an actual UI reminds me of this passage from Paul Graham's essay "The Power of the Marginal" [1]: > For example, it recently emerged that the famous glass artist Dale Chihuly hasn't actually blown glass for 27 years. He has assistants do the work for him. But one of the most valuable sources of ideas in the visual arts is the resistance of the medium. That's why oil paintings look so different from watercolors. In principle you could make any mark in any medium; in practice the medium steers you. And if you're no longer doing the work yourself, you stop learning from this. In the case of mobile app development, it's probably best to let the constraints and idioms of the platform, which the developer knows best, steer the design. So maybe part of the solution, contrary to what the article suggests, is to further collapse roles; maybe the developer should do the design, too. [1]: http://paulgraham.com/marginal.html http://paulgraham.com/marginal.html

ageektrapped 10y ago
Amen. I couldn't agree more with this. A lot of comments in the thread are commenting that the developer should be able to slice up PSDs, but why not go further and be responsible for the design and interaction. It requires empathy for the user and, let's say 100 hours spent on understanding fonts, colour and layout. The constraints of the platform should absolutely guide the design. Fight those constraints and the app will feel weird on the platform. Most designers won't know the constraints of the platform, or won't care; they want to make a design that's unique and beautiful and all that. The client (or any human being) will look at the pretty pictures and love it. The eventual user of the software _won't care at all_. Designers make pretty stuff that demos well. Those designs are usually a lot more work to pull off in code, though. In the middle of implementing those designs, all I'm thinking is, "What a waste of money. No user is going to care about this [animation|screen transition|custom look|beautiful settings screen]." This applies to web and mobile and desktop apps. Look at the apps you use everyday. They're probably boring to look at. At the least, if you're in the client position, get a designer and developer together at the same time to hash out the app. You can probably get something that looks decent, works well and costs less.

nbevans 10y ago

Who designs mobile apps by slicing PSD files? Fire the developer who went along with that idea!

halis 10y ago

I don't understand the notion that as a mobile developer you have to do the front end and the backend... I just wrote the back-end for an iOS app, I had nothing to do with the front-end and the sole front-end developer had nothing to do with the back-end. We used a simple Rest API. Where is the problem?

jasey 10y ago
I think the author was meaning it more in terms of MVC in the iOS project - Web dev - Backend dev scope: Model, Controler Front end dev scope: views - Mobile dev - Where as with an mobile dev, their scope is model, view and controller code (full stack) Your thinking of it in terms of the whole mobile app being the front end and the rest API being the backend. But the app its self has both "front end" and "backend" code segregation its self
- rayvinly 10y ago
  Thanks jasey. That's exactly what I meant. But you laid it out for me.
  - robmcm 10y ago
    It is a grey area, all web applications I work on have syncing, caching, local storage and offline support. I can also think of many mobile apps that do not. To assume otherwise is a bit of a generalization.
megablast 10y ago
There is more than one backend. The backend might be the server, or it might be the database/models on the device.

Zyst 10y ago

I think it's a bit naive if you think that Web Developers are cleanly split into Frontend and Backend. Most of the developers I know, like myself, are Fullstack. According to the Stack Overflow developer survey[1] there's more Fullstack developers than any other kind of developer. It just bothers me that the implication I got from your article was: "This is why mobile is tougher than Web." You might think: "Alright but web doesn't deal with some stuff mobile does, like offline data sync", but web does deal with stuff that mobile doesn't have to consider, like making sure your application is secure from XSS attacks, making sure all your backend endpoints prevent Overposting attacks, and other security considerations. And if you are freelance, usually web also has to handle devops. Although sometimes the client does have their own setup. Web also deals with considerations you don't in Mobile in general. Web is also very prone to failure if you don't plan carefully. On the other hand the part that mentions that you should break your development into tasks is absolutely spot on. When I take a job I plan how I'm going to do the entire application in my head, writing it down in the process, then and only should do I give an estimate. It might be the single most important practice in my job as a consultant. [1]: http://stackoverflow.com/research/developer-survey-2016 http://stackoverflow.com/research/developer-survey-2016

askyourmother 10y ago

Most fail because clients are lied to. They are shown the high-res print ready Photoshop glossies, and told "yes, you can have this, it will use all these assets. And lots of browser control overriding interactions". Then they try to actually build it, it is slow, uses the whole months bandwidth allowance for the mobile user "my whole 10GB gone? But I only browsed the web..", and will crumble under load. The real problem is letting designers near the web. They were OK on print, well, a lot of printers had problems with the designers as well. Hmm. Maybe it is just the designers.

TheCoelacanth 10y ago
The problem is designers only being responsible for the design and not for the end product.
rayvinly 10y ago
Thanks for pointing that out. Pretty PSDs are easy sells to the clients by design agencies who are then off the hook.

ThomPete 10y ago

Just like the designer would benefit from knowing how code works, so would a designer benefit from know how a developer works. The biggest issue isn't lack of communication but lack of understanding each other. I find it kind of interesting that a developer would even feel a reluctance to understand one of the basic methods used to deliver to them what they need to develop. You are missing out on great opportunity to have an informed opinion, think about alternatives, find potential business ideas from something thats not optimal and in general just have a better and more productive relationship with designers. I at least realized that learning to code as a designer, even just a little bit, both taught me a great deal of how to build things for developers, help them solves problems that might require a different way to think about the technical issue of something and not do stuff that are completely retarded and impossible to do. And so now none of my projects fail unless I want them to.

overcast 10y ago

In a web app, you’re either the frontend or backend developer. Riiiiiiiiight.

rampage101 10y ago

The client is unable to understand the technical challenges, while the developer cannot read the client's mind. Not a mystery why the project in story failed. I am more familiar with AndroidStudio than iOS programming, and it just feels like a hackish piece of software. It looks like Eclipse, and the code is Java, but it's really a stripped down version of Java with a lot of hacks and work arounds. It seems like so much time is spent negiotating with the operating system.

jordanlev 10y ago

Oh how the grass is always greener on the other side of the fence! As a web developer, I'm used to hearing about how mobile app development is so much better because there's a sane layout system and you don't need to deal with crufty old CSS. And how it's so easy to get native functionality, and the UI is easy to make run at the coveted 60FPS, etc. Nice to be reminded that as lucky as us developers are in the grand scheme of things, we still have hard jobs and changing your tools or platform won't solve all your problems but rather just gives you different problems :)

bshimmin 10y ago

There's a lot that's slightly off about this (though there is also some good material in here too, and clearly it's coming from a place of frustration based on real projects - perhaps, I suspect, without a huge amount of experience of the grass on the other side...), but one bit that particularly struck me was: When a client wants to build a web app, they understand they need to have a good design, build the pretty HTML and CSS, with a server in the backend, and some dev-op to keep the app running. Really? Because I'd be glad to introduce you to many of my clients who absolutely do not understand any of that; in fact I had a conversation with a client just two days ago where I explained, patiently and not for the first time, what it was one of my backend developers actually did on a day-to-day basis, and why that sometimes didn't translate into something visible he could actually click on in his browser. Most of my clients really just want a complete solution (often involving design) and they don't know or care at all about HTML, CSS, AWS, or Postgres.

guelo 10y ago

s/mobile/iphone/ Same issues exist on the other more popular platform but this article is only about the iPhone so the title is wrong.

ex3ndr 10y ago

In our project (actor.im) we successfully separated logic (cross-platform!) and make it work closely with backend team and we cover together all corner cases. Making UI on top of this is very-very easy.

jernfrost 10y ago

Oh man this felt awfully familiar. I am so happy I left iOS consulting work and instead built in house apps so I don't have to deal with stupid customers and designer detached from reality. In retrospect I think they should leave a bit more design decision to developers and let them throw up a minimum design first. A design which works well within the constraints and technologies of the platform. Then designer can come with input on how to change that. It is astonishing how much faster you can build an app if you don't have to care about getting the UI pixel perfect according to some designers pipe dream of what it should look like. Customers should know this, because I don't think they have any idea of how expensive it is to insist on very particular details of how the UI looks. If you give more freedom and choices in how the design should be to the developer you can get an app for a fraction of the price which is easier to maintain.

dasil003 10y ago

> Mobile development = frontend development + backend development + dev-op. Sorry no, being a mobile developer does not mean doing backend and devops any more than being a web developer does. In some cases you might have to do it, and in some cases you might not. But there's nothing inherently easier about the web. Furthermore I find the whining about different iPhone vs iPad layout differences to be quite ignorant of everything except iOS development. There is no more controlled environment than iOS. Try developing for Android some time. And don't get me started on cross-browser, cross-platform responsive web design. The bottom line is no development is easy, it's all a mess everywhere you look. It looks pretty bad when you try to extrapolate the warts from your particular corner of the dev world into an assertion that other developers have it easier. Doing good development work is just plain hard, even when working with equal share stakeholders and with none of the trust and workflow issues associated with clients.

adamconroy 10y ago

Interesting article for me as I just rolled out an app for a client and a lot of this feels familiar. Firstly I was lucky I didn't have a PSD driven design, but my client demanded a fixed price quote, so I insisted they pay me to do fairly comprehensive spec, including a clickable wireframe prototype, bdd behaviour spec, architecture design, background, requirements, objectives.... I went with lo-fi hand drawn pages which I scanned and wired up as a clickable prototype via https://marvelapp.com/ https://marvelapp.com/ In the end it was fairly successful for me, as the comprehensive spec allowed me to estimate fairly accurately. However I don't think it was the most cost effective outcome for the client. Because of their rigid nature, instead of collaborating through the process (aside from the specification phase of course), I built them exactly what we agree and invoiced them and was paid. However, within a week of the first pilot they had come up with about 100 hours worth of changes they wanted. In the end I spent about 100 hours in the spec / design phase (which I was paid by the hour), 300 hours building the app (which was a fixed price) and now I have about 100 hours of changes to make. If we had worked to a budget rather than a fixed price, then by my estimate I would have spent about 400 hours collaborating and iterating (basically removing about 90% of the time creating and writing a spec) and they would have had an app which they were involved in crafting the whole way through. Basically I think they have blown about 100hours and they have to live with lots of little nuances that they would have otherwise been able to decide upon.

fleitz 10y ago

Stop slicing PSDs and start writing code. Coding shit from PSDs is like making a car from a drawing a 3 year old made. It's so fucking stupid that only a 3 year old wouldn't realize it's probably the most retarded way to design an app. If your designer knew how to design apps they wouldn't be making PSDs, just like no car designer would substitute photoshop for clay. The only thing Photoshop is appropriate for designing is static images / webpages.

deleted 10y ago

[deleted]

wiradikusuma 10y ago

I dont understand why you need to slice PSD like it's Web dev in 1999. Does iOS/Android not have something like "Bootstrap"?

megablast 10y ago

Pfft, if his biggest problem is the design, he is sitting pretty. Also the designer should slice up the PSDs, that solves this problem.

kinj28 10y ago

For enterprise mobile apps - we are working to address this problem with our docker like container platform with ready pre-built mobile app with a runtime to run your cross platform hybrid web. feel free to ping and I will be happy to share more details.

madetech 10y ago

If designers could use an interface design tool instead of some photo editing software, then most of the problems go away. Spending time upfront perfecting a piece of art isn't a sensible way to approach design as its all make belief until you've written some code

bloaf 10y ago
I feel like I must be on crazy pills for suggesting that the designer's deliverable should be something like UWP XAML documents. I wouldn't necessarily expect them to do any fancy data binding, but they should be able to at least lay things out and maybe manually fill in some dummy data.

phatbyte 10y ago

Most of those design issues could be solved if they used (designer and dev) Sketch or Paintcode

k__ 10y ago

Im so happy that I never ever in my front-end career had to implement some designers PSDs. The only images I got where mocks with stuff I already implemented but needed some changes... On the other hand, I consider myself a software and usability engineer, maybe giving greater focus to nontechnical aspects of software has safed me from having to do what a designer tells me to...

ourcat 10y ago

This is why I'm a "createc". Front to back end. Involved throughout the project process. Gets the job done. Everyone happy. Fully managed (and often exceeded) expectations.

stevetrewick 10y ago

>As you are about to slice the PNGs... You realise that you have failed to communicate your requirements to the client, failed to do due diligence on the requirements and assets before you signed the contract and badly mis-scoped the project based on your imagination of what non domain experts should know about your field of professional endeavour. You are likely to be eaten by a grue.