Why most mobile development projects fail
clean-swift.com
clean-swift.com
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.
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.
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.
I believe both design, interaction and logic could be done agile.
Simplified: The use must login. So we need a screen with a login method. What fields are needed? What should happen on interaction with the form elements? How should the form elements look?
The whole team of graphic, interaction and logic designers work together with the client to make this happen.
Occasionally we do pixel perfect prototypes with clickable simulated logic and all but we can't maintain it all, and we try to use it only when something is logically complex to reason about without pictures...
It's about as fast to do in the real code with mocked services when you have the application already there.
It requires more collaboration but that can only be a good thing.
Hmm so, it looks to me precise prototypes are good for precise requirements, while vague requirements are better when engineering is also customer development, and customer requirements are not known precisely yet.
In our company we have 1.5 designers and 5 in engineering and we're good with maintaining the prototypes. The designers have to do other non-digital stuff like print media too...Maybe our web applications are mostly CRUD's with permissions so it's easy to maintain?
We have 6 teams with full stack developers and testers, sharing a (too) small group of UX experts. Each group have a product owner focusing on a specific area, but there is a lot of overlap.
But the general idea is to avoid big upfront design and instead try and retry the design.
As stated in the article, their is a lot of task that no one want to do; like determining goals, slicing png, animations, transitions between views...
When you get a PSD with no hover, no "view when no data", no sense of navigation, no specifications whatsoever.... You know your project will be tough and made of thousand of meetings.
Communication helps, good software helps, being agile does help too. But company does not value well how costly it is to be that much "agile".
I think it's actually a big societal problem, not just a contractor-client-relations problem. Our lives are full of crappy software, and the economy probably literally could not bear the cost to fill them with high quality software instead. Software cost savings are a lie formed out of crappy software.
Some people tend to want cheap. They don't see what software developers, testers, UX guys and so on bring to the party. Unfortunately they don't really have a choice - they pay now or pay later.
So companies keep doing this, because whoever does the "cheap" decision gets his/her bonus for reaching the target and moves on.
You pay now or you pay later for a worse result.
That's why I thinking bringing everyone as close together produces the best results. Yes, the designer wants X, but is Y acceptable if it's doable in a tenth of the time?
Start focusing on "What's best for the team / product?" rather than only on {whatever hat the asker is wearing}.
I think the solution is going to lie somewhere inbetween, with designers needing to expand their knowledge and working within tools that are based on how CSS and HTML actually function instead of a program that allows you to just place boxes wherever you want and hope its easy to code.
I've been following what these guys are doing over at BoxBox, they are onto something big I think. https://keminglabs.com/boxbox/
I don't know, I'm not sure what the solution is. But I'm pretty sure it's not PSD-driven development.
https://keminglabs.com/boxbox/dynamic-layout-engine/
Check out this demonstration. I really think this is going to be the next big step forwards for designers. I don't think they need to fully understand CSS, the box model, flexbox, the dom, inheritance, etc to deliver effective designs. They just need to be forced to follow these limitations of these things within the design tool itself.
I think the idea is to make every change the designer makes reflect a nearly identical change that the frontend devs are going to have to also make. For example, text color inheritance is a notoriously hard thing for a designer to grasp. If that was handled automatically for them, they are going to out of necessity, create a more code friendly color inheritance hierachy in their designs.
A sculptor needs to know about clay and ovens, a clothes designer needs to know how to sew, the strengths and weaknesses of different fabrics and so on (even if Gaultier or Lagerfeld didn't do any sewing and stitching when they made it big, you bet they learned to when they were apprentice designers). Knowing your medium makes you aware of the limitations and possibilities and a better designer.
Why do we insist on coddling designers with tools like Photoshop? What's wrong with making them learn CSS and HTML?
Maybe the web's finally catching up with that?
The parent is refering to the fact that it's much easier to make a design work on more resolutions with vectors.
But yeah, it is easier to make it work and it can be non-flat as well.
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.
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"?
For large changes, it can be unmanageable. But large changes are hard to code review anyway, so we try to avoid those.
At work we had two teams who had very different opinions of IB's usefulness. In our case, it was based on the nature of each application. IB does not provide much value when the majority of the screen is dynamically determined: different elements based on user preferences, locale, document contents, etc. The team that disliked IB, their app was almost all dynamic (and lists/tables, whose cells were also fairly dynamic).
Our team, on the other hand, had a very static UI. It had very little runtime customization (other than the contents of labels, images, etc). We loved IB.
And then child ViewControllers came along, and made it easier to mix static/dynamic content on the same screen.
I haven't used UIStackView yet, but I suspect it also will help with screens that contain dynamic content.
While I absolutely hated AL at first (and the IB just plain sucks) I do find it very time-saving once it clicked.
Whether it was written down or not, it seems like a good idea in theory. The old, stand-alone IB wasn't all that hard to figure out (though struts and springs might bring the death of your sanity). Get the UI all prettied up, and hook up an implementation behind it. Not that I've ever seen that in practice, however.
Truth be told, something palatable and pleasant that works can be a very, very high bar from a UX perspective. When software collides with the real world, you get a lot of complexity. Even organizations the size of Google and Apple can't produce a Maps app that doesn't do wacky stuff that seems designed to frustrate the user while trying to get someone killed. By comparison, how something looks is dirt cheap. (As usual, it's far cheaper to signal quality than it is to build it.)
When it has to deal with the "real world," mobile QA and UX is hard, and doing it to a high level is probably greatly underestimated in cost while being quite expensive. They say a picture is a thousand words, and seeing it yourself is a few more orders of magnitude. If your only feedback is logging/callbacks/snippets of text from users, you're only getting a small sliver of the true picture.
If your bar is too high on the UX side, as a lone contract programmer who is NOT the designer, you probably will have the same problems shipping as the person described in the article. Real artists ship. Lone consultants cannot do Apple/Google/Microsoft/well funded startup level UIs where there's a guy who's only job on the project is the interaction between code and design.
Citation, please. I deal with clients on a regular basis who think that software with 20+ years of time invested can be duplicated by 1-2 engineers working for 3-6 months.
Earlier today, I had to give a rough estimate on writing a custom app that can read, write, share and sync arbitrary CAD files, and explain why building all of that might not be the best approach.
Not at all a straw man. Maps might be much, much larger than a small MVP, but Google and Apple have a lot more resources than a lone contract developer. You are the one getting caught up with scale. I'm talking about the increased complexity of apps when they have to bump up against the real world. I've been greatly offended and materially affected by seemingly arbitrary choices made by a developer on a username field. Namely, that starting to edit the username field would blank out the password field, instead of doing this on start-edit of the password field. In a time critical situation on low-bandwidth, this can leave a user with a password vault cursing, high and dry, while the app starts this kafkaesque cycle of doing the most annoying thing.
Lone consultants cannot do Apple/Google/Microsoft/well funded startup level UIs where there's a guy who's only job on the project is the interaction between code and design.
If the aim is to make a substantive tool that stands up to real-world complexity in UX, someone, somewhere is going to have to spend a lot of time testing the heck out of it and make careful observations. Otherwise, the lone consultant is just going to check off the requirements, call it a day, and bill. The only alternative is to be really good about feedback, and implement in such a way that corrections can be distributed in a matter of a few hours or less.
I tried to put together a workable MVP as quickly as possible. The designs that I thought were aspirational designs for a finished product that would be completed eventually, but no, the CEO really wanted all of the fancy transparency, the exact button spacing, the exact imagery and fonts (despite the fact that they used fonts that weren't licensed for app usage...sigh...).
So we spent tons of time that was supposed to be MVP instead making a polished final product.
And then the CEO threw a new set of art to us and asked for a third redesign (ours was apparently the second, after the initial developer resisted making major design changes). And then a FOURTH redesign.
It amazes me that this guy (continues!) to get funding. But he's managed it. :|
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
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!
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.
- 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.
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.
The parallel to learning photoshop would be asking you to learn vim/emacs/<insert IDE>, source control, etc.
You literally get access to the very parameters and their values you might have to use.
It's not about learning how to use photoshop. It's learning how photoshop works, just like I learn code to understand how most code work. That doesn't mean I would call myself a developer who can code like a pro.
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.
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.
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.
> 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.
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.
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.
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.
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.
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 :)
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.
When Photoshop is too expensive, we get Powerpoint-driven development instead.
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.
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
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.
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?
- 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
To assume otherwise is a bit of a generalization.
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.
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.
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.
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/
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.
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
Front to back end. Involved throughout the project process. Gets the job done. Everyone happy. Fully managed (and often exceeded) expectations.
Riiiiiiiiight.
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.
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...
http://useyourloaf.com/blog/creating-scaled-images-with-pdf-...
-- A designer
Also the designer should slice up the PSDs, that solves this problem.
Same issues exist on the other more popular platform but this article is only about the iPhone so the title is wrong.