
Ask HN: How do you write concepts? (Structure / Tools / Howto) - ladino
You have an idea and would love to get a designer + developer to get that on track! :)<p>How do you scribble your mockup?
Do you have a structure or question-list to make a detailed concept (in my case for a web project)
What are your experiences?
What are your tools?
Could you recommend books or experiences from big companies?
How to start?
======
plainOldText
* Design Mockup Tools

In the past I used Keynote for its simplicity, now I prefer Sketch. It's nice
to be able to preview your designs on your mobile devices. These apps are for
Mac only though.

* Books

One book I would recommend on design is "The Design of Everyday Things".
You'll learn a few useful things about design in general.

Another book I'm reading right now is "The Process of Creating Life". I cannot
recommend it yet as I haven't finished it, so I'm just mentioning it. This
book might seem like an odd choice at first since it's from the architecture
shelf, but it has some interesting ideas nonetheless.

One thing to mention is that the topic for both of these books is not digital
design, yet I would argue that the knowledge learned from them is transferable
to the digital realm.

~~~
tuned
About "The Design of Everyday Things", there is also a course on Udacity based
on the book: [https://www.udacity.com/course/intro-to-the-design-of-
everyd...](https://www.udacity.com/course/intro-to-the-design-of-everyday-
things--design101)

------
tmaly
I sometimes work with remote designers, so I needed something that is flexible
and fast to create.

Rather than trying to spend hours using Gimp or Photoshop ( I have been down
that road), this is what I do as its much faster to translate whats in my mind
to something a designer can use.

Get a sketch pad ( blank pages no lines ), I bought mine at a local pharmacy.

Get a good mechanical pencil, they sell good ones for drafting, also get a
good erasure that is different from the pencil.

Get yourself a good ruler, it you want to draw to scale get an architectural
ruler not an engineering ruler ( scale is for land etc so its too big ) if you
do not need to draw to scale, get a metal ruler with the cork underside to
prevent slipping on the paper.

Get yourself a plastic stencil of different shapes. Many of these are used for
flow charts or electric circuits, but find one that has the shapes you want.

Draw out your proof of concepts on paper using your rulers and stencils.

Label your drawing.

Finally just take a picture with your phone and send it to the designer.

It you have to make a change, its super simple to erase something and make an
adjustment.

------
datahipster
Take a look at the recent book Sprint:
[http://www.goodreads.com/book/show/25814544-sprint?from_sear...](http://www.goodreads.com/book/show/25814544-sprint?from_search=true&search_version=service)

It details a creative process for developing concepts and testing them. Given
that the book outlines a 5-day process that is tailored for product
development teams, you might get a lot out of it for personal projects.

------
gkya
I'll say pen and paper for sketching too, for it is the fastest tool to use,
no need to chase the object you'll draw, or search for where to modify the
font. You think and you draw, the quickest possible. But then I'd move it to a
digital platform because there it's easier to manipulate a schema that you
already have. Though up until this day I haven't done that. However for emacs
users there is the builtin artist mode and for others who don't want to use
emacs there's a program that is capable of sketches and flow charts via a
script input, but I don't recall the name, sorry.

In general I usually jot down whatever comes to my mind and try to structure
it all later, or on the way witg intervals. It's hard to think in a schematic
way. So I'll have my notebook and pen, and write whatever comes to my mind
_asynchronously_ , that is I won't wait for the next thought. If I'll present
my idea to someone else, I ll try to have at hand a schema and some notes both
as brief and as clear as possible and I'll skip details for not making
premature commitments.

------
kevindeasis
For UI/UX draw it on paper. Then get inspiration from an expert's work who's
design is similar to your drawing on a sites like behance, dribbble, etc.

I use my blog post for my go-to list for prototyping.

[Prototyping]([https://medium.com/free-stuff/the-entrepreneurs-
list-b53ff53...](https://medium.com/free-stuff/the-entrepreneurs-
list-b53ff53388c0#.aq2bst3pg))

[Look at design resources section]([https://medium.com/free-stuff/500-free-
things-on-the-interne...](https://medium.com/free-stuff/500-free-things-on-
the-internet-to-start-your-new-year-11ae72266b66#.koffgodvt))

For data structures, database schema, software dev; MOOCs are your best
friend. (MIT,Coursera, etc.)

~~~
deadowl
I've found more formal database schemas are often lost on people that don't
work with relational data. Any ideas on how to avoid that?

~~~
bobwaycott
I typically don't go past the point of jotting down the structs. If we're just
talking about getting ideas out, it only needs to include what's necessary for
selling the idea.

Edit: by which I mean a fairly simplified bullet-point list of, say, ThingFoo
with attrs fizz, buzz, bar, and baz.

~~~
kevindeasis
This is a great point. I forgot about this. People who have no background in
programming can find it easier to follow along if you just tell them you're
gonna have this multiple different black boxes that does a specific thing
(different function/methods/classes)

------
rayalez
I'm using draw.io to draw mockups, it's incredibly useful, it helps me to
figure out how the interface looks like.

Also I use emacs org-mode to write down my notes. Usually it's just some
thoughts on the project and list of features that I want.

Then I start putting it together in browser, usually almost immediately,
without much preparation. I just create a django project, add a test view, and
start writing some html/css. It really helps me to think, as I do that I get
all sorts of ideas about the design, features that I want, and how the whole
project will be structured.

Meanwhile, on my notes, I have a list of "big", "medium", and "small"
features, ranked by importance(or in order I want to build them in). Also
bugs, questions, and whatever other ideas I have.

But all that is just for personal projects, I haven't yet worked in teams on
anything big.

------
sharemywin
[http://creately.com/plans](http://creately.com/plans) only costs $50 for a
year for an individual

It allows you to create use cases. I wouldn't get too much into the details.
It's a designer and developers job to design and develop. If they are good
they will have plenty of insights on "how" to do stuff. If you give them too
much detail they will just use your design. Let them use the other tools to
create the design and flow for you. And let them justify why they made those
decisions.

I would design the initial on boarding flow first and test if you can get
users for it. don't spend a bunch of money on a project that can't get bunch
of users.

------
cweagans
I've had a lot of luck throwing something together in Bootstrap or similar,
and then when a designer gets involved with the project, they approach it as
more of a redesign: they can get familiar with the app, understand what it's
trying to do, and then go from there. Paper, in my experience, doesn't
adequately communicate some things (for instance, more complicated UI
interactions are somewhat hard to model in a reasonable way on paper).

------
aidos
Personally, for code stuff I've always found that boxes with arrows between
them are really good at relaying information (pen and paper / whiteboard).

In my experience, it's not the final result that matters though, it's the
process. As you add each bit to the puzzle and scribble paths on that helps
build the understanding. The end result usually looks like a big mess, but the
process of getting there is what matters.

~~~
deadowl
That works for most decision tree models. Venn diagrams are better for
explaining anything having to do with set models. Cartesian graphs are good at
explaining time/space complexity.

------
ChemicalWarfare
Whiteboard + draw.io for component, flow and class diagrams (if it comes to
that level). Whiteboard for UI. If I have a dedicated UI dev, they can take a
pic of my whiteboard sketch and build a static prototype faster than me
attempting to draw it in some legit fashion :)

Quick static/stubbed out prototype app in some cases with whatever tech is
appropriate (for mobile been digging ionic quite a bit lately for
prototyping).

------
mattbee
I'm a customer & fan of balsamiq.com for sketching user interfaces - it does
the job really well.

------
donjaber
webpagestickynotes.com has a diagram menu powered by js-sequence-diagrams,
mermaid.js, flowchart.js & d3.js that allows frictionless text-to-SVG diagram
rendering paired with a quick snapshot capability.

Additionally, draw.io can produce SVGs with embedded serialized draw.io state.
Those SVGs can be added in a document or a sticky note and re-imported back to
draw.io for later editing.

------
mseeber
If I _make_ a concept or design and in the process of thinking, I only use
pencil and paper, lots of paper.

Everything else is just too distracting. The available software tools just
don't cut it for me as a software developer. They are bound to a device and
have complicated user interfaces, they are distracting or at least run on a
device that has potential to distract me. Even if they are the perfect
software, the fact that they run on a PC/Laptop/tablet/Phone is just enough to
distract me. Except maybe a whiteboard, but these are quite expensive compared
to pencil and paper and a maintenance nightmare. Their use case is justified
if this is an interactive Meeting.

And the best thing about pencil and paper: It works offline, will not install
updates and display no ads.

If I am _done_ thinking/tinkering/planning/designing/modeling whatevering, I
either redraw it cleanly and scan it or use one of the tools, others will
mention in their comments to be able to archive it digitally and share it with
others.

Some notes:

No, the time you will need to redraw it when changing your concept it not
wasted time. No, the fact, that there is limited space and resolution when
working with pencil and paper is a feature, not a bug.

Now for the process:

use cases DO NOT SKIP THIS, never ever. Some may call them user stories but
hey, that's just marketing. use cases can be put in diagrams and they even
have a standard: UML They are the highest level abstraction of what you want
to build and the help you and others to keep on track. Maybe read about them
here:
[https://en.wikipedia.org/wiki/Use_case](https://en.wikipedia.org/wiki/Use_case)
TL;DR The important part is to know, _who_ will do _what_ with the _system_
you want to build, to _achieve what_? When creating diagrams, create them in a
way, so that they fit on maximum half a page each. Everything else can't be
grasped reasonably and is "just to smart™". Divide and conquer if necessary.
As a result, it should be clear on a high level abstraction what the purpose
of that thing you want to build is. A tip: You may sit for an hour on a
diagram that has four bubbles and a stick man, that may feel awkward but is
just the right thing!

If you have use cases, you can go on with how you imagine to fulfill these.
That's usually the exciting part and the part people jump to forst, not
realizing that they don't even know what they want to do because they skipped
creating usecases... Depending on the project use anything that seems
appropriate: mockups, architecture diagrams or some kind of sitemap in case of
a web site.

If you think you have a rough draft you can explain, talk to your
developer/designer, the rest will come naturally if they are professional. If
they are professional, the should be able to offer you good communication as
part of their job.

~~~
sturakov
Hey there, I've enjoyed your comment. I think we're kindred spirits when it
comes to using paper for putting thoughts down without distractions.

Mind if I ask you two questions?

I've been struggling with finding a way to reconcile using paper and the
digital realm.

On the one hand, I find sketching out ideas and writing out thoughts a lot
more enjoyable on paper. I also seem to distill what I am trying to
communicate a lot better too! And like you've mentioned, there are a lot of
negatives to using software to achieve the same end.

\- Complexity of interface

\- The software runs on a machine that is capable of distracting me way too
easy

\- Notifications

But how do you deal with having a lot of paper floating around, filled with
ideas and sketches of stuff? I guess, how do you organize them all in a way
that isn't just organized clutter?

I've been digitizing all my work with a Document Feeder Scanner, which works
alright in the sense that it gets my work onto the machine, but I feel like
I'm philosophically missing the point.

Can you comment with some thoughts perhaps? Thank you.

~~~
mseeber
Actually there are two points here:

1\. The creative process 2\. Archiving/documenting

The amount of paper used in 1. can be very high, but essentially the key point
is to let go of all your sketches when you are done distilling them. They are
material for the trashbin. This may sound hard but it makes sense when you
have a separate step for archiving, which means step 2.

Step 2. means, I distill all the lump of paper into what is required for the
project at hand or worth keeping. This depends on the circumstances. Sometimes
it means just putting a sheet of paper next to the other bureaucratic stuff,
most of the time it means writing a project documentation or "specification"
document, sometimes writing an outline for a paper or an abstract. This may be
grunt work and the tools may suck, but that's OK since it is separated from
the creative process and for the purpose of documentation, not creation.

If you have multiple projects at the same time and find yourself switching
around often, make some organized space. There are these stackable plastic
things where you can put stacks of paper in, not sure how they are called in
english but I do use them to have 3 or 4 separated stacks that I can just pull
out or put away when needed.

Maybe the key point is to be able and let go of old stuff. Taking half a hour
once a week and browsing through the notes, evaluating and rejecting
old/obsolete stuff helps too. Also, the "archiving step" acts as a filter. If
you find yourself not having time/incentive to archive a certain idea or
sketch, it is probably not worth it and can go to the trash.

Keep in mind, that Ideas (when they are just Ideas) are worthless. They need
to be realized and one can only realize so much in a finite amount of time.

~~~
sturakov
I sincerely appreciate your response and the points you've pointed out.

The process you talk about makes a lot of sense. The creative process
separated from archiving/documentation is a good distinction, thinking about
it. I can see how it moves from paper to digital better now.

I'm reflecting on the key point, of being able to let go of old stuff. That,
combined with a limited time in the day (not to mention motivation /
discipline / incentive) makes your point a very hard one to swallow.

I think that rationally, it makes sense. Limited time means we can only do so
much in a day. Emotionally, it feels like I should be able to digitize all the
ideas and do them "later".

I'm not sure where I'm getting at with this, but I wanted to say thank you for
giving me some good advice on how to approach paper and digital for projects.

